![]() |
![]() |
|
|
|
|
Mining v2.1
This thread was spawned (pun intended) from an initial response I was going to make to GG's thread on static versus dynamic roid/arti spawns.
I don't have an issue with "static" aspect of mining and roid placement being such that specific sectors are more likely to spawn roids of a distinct and certain nature. Unreg/distant locations being more likely to spawn a higher concentration of pures or radioactives etc. These sectors can spawn junk roids too, but certain sectors simply have a higher percentage chance of spawning good stuff. The thing that has always bugged me about pures and arti's is the obvious and opaque ruleset for spawn placement. Having a rule such that "an arti must spawn within a radius of 90k from the 0,0,0 gate is the height of unbelievable. The only ruleset that any sector should ever really have is that no object can spawn within 10k of the vector of any ship in flight in that sector. Other than that, if no one is in sector, plop a fat juicy light absorbing dark as hell roid right between two gates if you wish. The alternative (and in my opinion ideal concept) is always spawn stuff at the 400k (stay with me here) range in a pure sphere from the midpoint of the sector and set it's cross sector vector to cause it to pass a random distance of within say 50k of the midpoint of the sector traveling at a very slow rate of say 20v. On the first day (or week, I didn't do the math) each sector would seem barren, but after a week, you would have a constant stream of very slowly moving arti's, pures and normal roids ever so slowly working their way across the sector itself in literally all directions (left/right/up/down/forwards/backwards). If an object makes it to the opposite side of the sphere, it is despawned and a replacement object spawned randomly somewhere at the 400k range. The spawn formula could be designed such that instead of a perfect distribution of objects at the sphere spawn perimeter, it would spawn a "stream" of objects, emulating in essence a roid belt that was slowly passing through the sector at 20v. One day you might barely be able to see it coming , then 2 days later the edge of the belt was passing 20k from one of the gates. 2 more days later and it's within site but you can tell it's going to be out of range in another day or so from an efficient mining perspective. 2 days after that a new stream totally off vector from the last one may appear within site. Tear it up...I love the respectful disagreements and counter points that are presented here. I would just hate to be ND and have to choose from a dozen excellent ideas (not implying mine is mind you LOL). |
||
|
||
| Sponsored Links |
|
|
|
|
|
|
Re: Mining v2.1
This concept of course would force the introduction of code to handle object collision with non-ship objects (stations, other spawned objects etc). End result being that the resultant post collision speed would never drop below nor exceed 20v (to prevent and object coming to rest...or would that be a bad thing..hmm)
|
||
|
||
|
|
|
Re: Mining v2.1
We wouldn't need to worry about collisions if people stopped building space stations inside asteroid belts.
Some assumptions - Jumpgates and their petals are indestructible. We could suppose that the petals draw power directly from the wormhole itself, allowing them to maintain shields that are impenetrable. Or, anything touching the event horizon of a jump point is immediately destroyed if it does not possess the background field put out by a jump drive. Either way there should probably be an animation for rogue asteroids splashing against the jump horizon. Beacons we would probably guess that these are small enough that they'd never get hit by an asteroid. To keep the math simple, we could just put beacons at 0,0,0 of all sectors (instead of one of the jumpgates), and program spawn vectors to never travel within some minimum distance of 0,0,0. A collision boundary for a spawned asteriod should be turned off for the first 5 minutes that it exists. That should be plenty of time for anyone who just happens to be near it to make any necessary course corrections. That would go for static spawns or moving ones. Depending on how 'advanced' the story line for Jumpgate Evolution is, we might assume that all stationed sectors have already used up all the local asteroids, and we'd have to go into the unpopulated asteroid belt sectors for mining. |
||
|
||
|
|
|
Member
Pilot Name: Wild_Bill
Faction: Octavius
Joystick: MS Sidewinder Precision Plus
Join Date: Jul 2004
Location: Abilene Texas
Posts: 794
![]() ![]() |
Re: Mining v2.1
Darn it! I like both of those ideas. Takes care of spawning pures and artis. Also makes sense that some sectors/areas would be better for certain kind of ores. Never made much sense to me that pures and artys would spawn equally, either in distance or quality.
|
|
|
||
|
|
|
Member
Pilot Name: TexMurphy
Joystick: X45
Join Date: Mar 2005
Location: Gothenburg Sweden
Posts: 122
![]() |
Re: Mining v2.1
IF I understand you correctly youd like to move the roid fields outside the "main lanes" of the sector.
Id really miss PvP near roid fields. Having roids to cloak on just near the main lanes is great from strategic aspect. Tex |
|
|
||
|
|
|
Cadet
Joystick: Saitek Cyborg Gold
Join Date: May 2007
Location: Kennedy Space Center
Posts: 73
![]() |
Re: Mining v2.1
Personally, I'm a HUGE fan of moving roid fields. However, I'm also a fan of roid cloaking. Sooooo, here's an explanation that covers both.
Technically, everything in space is in motion. Stations, Jumpgates, beacons, etc. are all moving in orbit around a planet, sun, galaxy, whatever. Some just move at different rates. Have the un-mineable roids as the 'stationary' roids (those moving at the same speed at the stations and beacons) so you can still roid cloak, but since all the stationary mineable roids will have theoretically already been mined, the only mineable roids are those that are passing through the sector. It could be like a large comet with a bunch of smaller roids in tow, with certain mining sectors being part of a roid belt in continuous motion through that sector. |
|
|
||
|
|
|
Re: Mining v2.1
Oh wow man, these are some great ideas.
If I understand you right, each sector would have some sort of gravity well, be it a star, black hole, planet, etc. and everything would revolve around it. The further away an object from the well, the slower its orbit. This would cause stations, roids, heck anything really to be constantly changing. Is this correct? Wow! Thats pretty darn cool. As far as the stations and such, if a roid comes into contact, it would be really cool if it bounced off the object and then the orbit formula was recalculated. This would further the randomability(sp?) of how roids orbit. It would be really interesting (my computer science major coming out now) to see how an environment would behave over time. If all the roids would mass together or if they would spread out evenly, or if some other unknown result would happen. Interesting ideas, everyone! ![]() |
||
|
||
|
|
|
Cadet
Joystick: Saitek Cyborg Gold
Join Date: May 2007
Location: Kennedy Space Center
Posts: 73
![]() |
Re: Mining v2.1
Something like that, alph. For all we know, each faction could be in their own solar system circling their own stars, and all of them circle the same blackhole at the center of some galaxy (in Pulsar). Or, each station could be in separate galaxies circling different blackholes. Hell, there are actually free floating planetoids (not linked to a star) that still circle something, be it a galaxy or black hole, or whatever.
I'm going under the implementation of ike's idea that there is a 400k sphere of objects that exist. So, you would randomly generate a set of roids entering that sphere, they would move through the sector, and exit on the other side. All the while other roids are entering and exiting. Removes the massive amount of objects that need to be rendered in a sector. Remember, we're not trying to prove core accretion theory here, just provide a more realistic approach to mining. |
|
|
||
|
|
|
Re: Mining v2.1
Quote:
Enterprising souls could search further out (100k etc) looking for the derelict ship that was actually spawned 2 weeks ago and has been slowly working it's way towards the center of the sector. 3 weeks later and it would totally be on it's way "out" (in essence heading for despawning) if no one noticed it passing say 30k away from the sector midpoint. The relative velocity should be low enough that one can barely sense motion and have no issues matching relative velocity in terms of mining, artifacting etc. I really like this idea in regards to derelicts and pures. I would have the derelicts replace the artifacts themselves and combine artifacting and salvaging into one model. Ancient advanced technology may end up in your hold after 15 minutes of using your "salvage" gun or you may simply end up with a cargo bay of iron, titanium and phosphorus. When I refer to the cross sector vector intersecting the mid point of the sector, that's actually far too precise. It's more of a "aim in that general direction" with a chance to pass say...50-75k of sector midpoint...just making up numbers that could be tweaked. The one thing I did mess up through lack of forethought is the concept that on day one of server startup that the sectors would be barren. In reality, before the devs open the server gates, they simply have to speed time up such that about 5 weeks pass to allow the sector to hit it's max object spawn cap and populate the sectors with their objects. It won't look like a solid wall of crap when you jump into sector. In fact it shouldn't be any more populated than most sectors are today. To handle the client "object loading" aspect, it would seem that when you are in any one particular sector, the server could "pre-load" you with the object placement and type of all objects in connecting sectors (any adjacent sector that you could jump into). Given that most sectors only have at most say 4 connecting jumpgates, there should be sufficient time as you travel from gate to gate to pre-load that. Heck, you could actually "guess" which gate (dependent upon the last 10 seconds of travel prior to hitting a gate) to use that to pre-load the client. As with any intelligent game design, it would really only have to pre-load you with objects that are within 54k sphere of your jump in point. Anything beyond that is irrelevant at that moment anyhow. It has time (even in an arti'd out scout) to load you up with the rest of the objects once you are in sector at it's leisure. |
||
|
||
|
|
|
Cadet
Joystick: Saitek Cyborg Gold
Join Date: May 2007
Location: Kennedy Space Center
Posts: 73
![]() |
Re: Mining v2.1
Just for some simple math...
Objects moving at 1V will move through the 400k sphere (at the widest point) in 4.6 days. Talk about a slow moving living environment. |
|
|
||
![]() |
| Bookmarks |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |