Return to “Suggestions”

Post

Re: Jumpdrives, Jumpgates and Wormholes

#286
JoshParnell wrote: Sorry, I meant that it will remain a feature in that the code will exist to support it. The probabilities governing it, as you suggested, could essentially turn the mechanism off. I didn't mean to suggest that I will force it on you as a part of the game, rather just that it will be implemented and supported :) If changing the constants that govern a feature can be completely disabled (as in this case), I see no reason to be too worried about it :)
The amount of user control over the various factors of your own universe is one of the biggest selling points of LT for myself.

Can't wait.
My Signature
Post

Re: Jumpdrives, Jumpgates and Wormholes

#287
Well Thymine's had another one of his "great ideas" ( :roll: ) and he's pestering the shit out of me and refuses to let me sleep until I've shared it.

Basically, the idea is that instead of there just being isolated wormholes appearing at different points in space, there are so-called "wormhole hotspots", which are regions in space with super-high vacuum acc- you don't care about the lore. Wormholes always appear within these hotspots, and hotspots can host multiple wormholes simultaneously, with endpoints that are physically located within the same region of space.

Wormhole modules (aka jump-bridge generators) still operate point-to-point, but now these "points" are wormhole hotspots. So when you want to establish a connection to somewhere, you actually select a hotspot and then a brand new wormhole forms connecting the two hotspots.

The WHMs that ships and stations use artificially elevate the vacuum accessibility of sur create artificial wormhole hotspots, which wormholes can then be spawned within for vessels to use or fleets to fly through or stations to use or whatever.

And the consequence of all this? You get to keep virtually all the same gameplay that Thymine proposed before, but all wormholes are now two-way. None of this unidirectional bullshit that Thymine's been prattling on about; one wormhole = two endpoints, you fly in one end and you come out the other every single time, you're welcome. And both endpoints can share the same charge if we really want that too.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#288
ThymineC wrote:Well Thymine's had another one of his "great ideas" ( :roll: ) and he's pestering the shit out of me and refuses to let me sleep until I've shared it.

Basically, the idea is that instead of there just being isolated wormholes appearing at different points in space, there are so-called "wormhole hotspots", which are regions in space with super-high vacuum acc- you don't care about the lore. Wormholes always appear within these hotspots, and hotspots can host multiple wormholes simultaneously, with endpoints that are physically located within the same region of space.

Wormhole modules (aka jump-bridge generators) still operate point-to-point, but now these "points" are wormhole hotspots. So when you want to establish a connection to somewhere, you actually select a hotspot and then a brand new wormhole forms connecting the two hotspots.

The WHMs that ships and stations use artificially elevate the vacuum accessibility of sur create artificial wormhole hotspots, which wormholes can then be spawned within for vessels to use or fleets to fly through or stations to use or whatever.

And the consequence of all this? You get to keep virtually all the same gameplay that Thymine proposed before, but all wormholes are now two-way. None of this unidirectional bullshit that Thymine's been prattling on about; one wormhole = two endpoints, you fly in one end and you come out the other every single time, you're welcome. And both endpoints can share the same charge if we really want that too.
Had an very similar idea :lol:
But with the small addition/change that all natural wormholes (besides maybe the unstable ones) create/ are inside such an zone.

So you get something like the unidirectional point-to-wormhole jumpdrive, without the fubars of unidirectional connections
Post

Re: Jumpdrives, Jumpgates and Wormholes

#289
Cornflakes_91 wrote:
ThymineC wrote:Well Thymine's had another one of his "great ideas" ( :roll: ) and he's pestering the shit out of me and refuses to let me sleep until I've shared it.

Basically, the idea is that instead of there just being isolated wormholes appearing at different points in space, there are so-called "wormhole hotspots", which are regions in space with super-high vacuum acc- you don't care about the lore. Wormholes always appear within these hotspots, and hotspots can host multiple wormholes simultaneously, with endpoints that are physically located within the same region of space.

Wormhole modules (aka jump-bridge generators) still operate point-to-point, but now these "points" are wormhole hotspots. So when you want to establish a connection to somewhere, you actually select a hotspot and then a brand new wormhole forms connecting the two hotspots.

The WHMs that ships and stations use artificially elevate the vacuum accessibility of sur create artificial wormhole hotspots, which wormholes can then be spawned within for vessels to use or fleets to fly through or stations to use or whatever.

And the consequence of all this? You get to keep virtually all the same gameplay that Thymine proposed before, but all wormholes are now two-way. None of this unidirectional bullshit that Thymine's been prattling on about; one wormhole = two endpoints, you fly in one end and you come out the other every single time, you're welcome. And both endpoints can share the same charge if we really want that too.
Had an very similar idea :lol:
But with the small addition/change that all natural wormholes (besides maybe the unstable ones) create/ are inside such an zone.

So you get something like the unidirectional point-to-wormhole jumpdrive, without the fubars of unidirectional connections
All natural wormholes form inside wormhole hotspots too, since hotspots can form naturally. Even U-types form inside hotspots, it's just much harder to detect the hotspots they form within.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#291
Cornflakes_91 wrote:We could say that the hotspot is providing the charging capability, and not the wormhole itself.
This way unstable wormholes would be those which do not form inside of hotspots.
Not sure which way to go down:
  • Unify all wormhole types by saying they all have to be established within hotspots
  • Say that hotspots provide charge, U-types cannot charge, and therefore U-types don't form in hotspots
I think I want to be able to say, "all wormholes form within hotspots" just for the sake of unification. Because the thing is, even if U-type endpoints don't form on top of hotspots, what stops someone artificially generating hotspots on top of them? They still should not charge. As I write here, I think I agree with you that's its elegant to be able to pump charge into U-type endpoints just like any other type, but that this is pointless because the endpoint's decay rate always rises to match the charge rate, and then some.

So U-type's can form in hotspots, maybe, but they will decay faster than they gain charge from the hotspot.

A few questions:
  • Can we charge hotspots directly?
  • Do wormholes still have their own charge?
  • If both hotspots and wormholes have charge, what is the relation between them?
  • If a hotspot has multiple wormholes, how does that change the matter?
  • Can we charge wormholes directly?
  • Do both endpoints of a wormhole necessarily have the same charge?
Post

Re: Jumpdrives, Jumpgates and Wormholes

#295
2 ideas that floated around my head for a few days now regarding "making jumpdrives less OP"

1. interdiction fields
the classic "you no jump here" technology, but not on tactical scales (long range ship combat) but for strategic ranges.
big module for stations that prevents opening of new wormholes in a few lightyears around the generating station('s system)
this also prevents wormholes going "through" its sphere of influence
A--(-B-)--C
so no jumping from A to C through B's interdiction field

mitigates "suddenly, battlefleet" problems and makes it possible for them to still be used (maybe even for P2P jumps :ghost:)


2. interdiction fields another variant
a variation on the interdiction field, feld generators cannot create no-warp zones by themself, they need other stations for that.

interdiction modules become the vertices in the corners of an interstellar polygon that prevents jumping through its border.
you can join multiple of those polygons together to encase a volume in a no-warp bubble (maybe even prevent warping in the bubble altogether and not just through its border?)

power needs rise with the area of the interdiction polygons, but should have a balancing factor that using more stations has an energy need bonus.
to create a trade off: more stations that stretch your resources more, but the stations themself are relatively cheap
or big, relatively easy to defend stations that get disproportionally expensive


interdiction fields (both variants) prevent any wormhole from being created, also allied ones.
so if you want to jump through your own interdiction field, you have to turn it of beforehand

activating and deactivating of the interdiction fields should also take time, so when you see that the enemies interdiction field is reducing power, you probably do better to prepare for a jumping fleet



just a few blurbs, and i wanted to get them out in case someone could deem them worthy :)
Post

Re: Jumpdrives, Jumpgates and Wormholes

#296
Do we know that the structure of the wormhole network corresponds at all to the structure of regular space? I was under the impression that A->B Might be a billion light years apart, while B->C might be 6 light years apart, and B->G is 76 million light years... but on the map, they are all right next to each other.
If thats the case, your idea of a plug in the pipes doesn't make that much sense.

I have been against Point to point jump drives from the beginning, and feel that all travel really should happen in that network of tubes (even if some tubes are unstable and their existence at any moment is uncertain), and that fast travel between multiple systems should really be done daisychain style, with jumpdrives merely being those devices which allow one to daisychain jump.

If all travel is happening along the tubes then a plug makes sense, in that it doesn't close off any existing wormholes, it just prevents any unstable ones from connecting to that system while powered.
Image The traditional view of robotics, the metal servant who doesn't ask questions, is merely nostalgia for slavery.
User: JoshParnell is accountable for this user's actions.
Post

Re: Jumpdrives, Jumpgates and Wormholes

#297
Hyperion wrote:Do we know that the structure of the wormhole network corresponds at all to the structure of regular space? I was under the impression that A->B Might be a billion light years apart, while B->C might be 6 light years apart, and B->G is 76 million light years... but on the map, they are all right next to each other.
If thats the case, your idea of a plug in the pipes doesn't make that much sense.
from what i know the position on the map corresponds to the position in the universe.
so when two systems appear close they actually are close

edit:
linky link
Post

Re: Jumpdrives, Jumpgates and Wormholes

#298
JoshParnell wrote:Speaking of new code, despite all this penguin-laden cross-platform hogwash, I did manage to stuff some new 1s and 0s into the old engine today. In particular, I worked on generating the connectivity information for regions (i.e., how systems are connected to one another). Star system connectivity is probably one of the only textbook algorithmic problems that I've seen so far in gamedev (besides pathfinding), and it's nice to know that the things they teach in school actually do come up at least once or twice in a blue moon :roll: Specifically, I think star systems should be connected via a minimal spanning tree, or some slight permutation or extension thereof. The explanation is simple enough: you might imagine that, in reality, the cost of a jump gate would be proportional to the distance of the jump (insert subspace stabilization technobabble). Hence, the optimal cost solution for connecting a region is via a...surprise surprise, minimal spanning tree. Throw in a few extra edges and some variance in the weights just for fun. Kruskal's is a very simple and intuitive solution to mst, and also the thing they teach you on day 1 (more or less) of algorithms class. So I took a bit of time to implement it today, and worked as hard as I could to do it with as few lines as possible. Ended up with about 25 lines, of which I'm fairly proud. Next step is to actually generate the jump gates and draw them on the system map, now that the connectivity information is present!
Quoted Cornflakes' link, with most relevant text emphasized. Can we confirm that this hasn't changed? It's a little old.
"omg such tech many efficiency WOW" ~ Josh Parnell

Online Now

Users browsing this forum: Google [Bot], Graf and 1 guest

cron