Hyperlane Infrastructure, Endgame Travel

Burnside

Master endo
Joined
Aug 23, 2019
Messages
308
#1
Working from the premise of warp travel working by way of creating "highways" in which speed is unrestricted until an impedding object triggers the anticollision dewarp feature, I presume Hyperlanes are generated from a large, energy-intense, station-based system composed of several installations that each play a part in setting up Hyperlane Infrastructure.

Natural Hyperlane Nodes: hyperlane nodes occur naturally at lagrange points between any two celestial bodies, there are always five langrange points where gravitational flux creates hyper stable zones in the L1, L2, and L3 points and "gravity hills" at the L4 and L5 points, but we don't really care about all that, all we need to know is that the five Langrange Points are large areas in space relative to the gas giant and any moon orbiting it where warp travel is easy to do, which is why we're going to call them Natural Hyperlane Nodes, anywhere else and a station wishing to install Hyperlane infrastructure will also need to support a Hyperlane Node Generator.

Hyperlane Node Generator: this expensive and power-hungry installation is more or less black box technology, nobody really understands how it works, but when you follow the instruction manual and turn it on, the massive device generates an Artificial Hyperlane Node. Where a Natural Hyperlane Node comprises a large and often remote area of space, several tens of kilometers in diameter, an artificial node is only about five to thirty kilometers across depending on the size of the generator. The most unique feature of a Hyperlane Node is not the fact that it allows Hyperlane Gates to function inside of it, but that any object traveling at warp speed will drop out of the imaginary phase state that allows mass-bearing objects to break conventional physics when it enters a Hyperlane Node. While any vessel can use simple electromagnetic phenomina in thruster systems to disturb their phase state and manually drop out of warp, entering a Hyperlane Node will always shunt the vessel back into a conventional state.

Hyperlane Detector: a large and powerful scanning array that can detect Hyperlane Nodes at long range and translate the angular coordinates to a YOLOL data network, larger detectors can detect nodes at longer rannges but require geometric increases in power. The odd physics involved in Hyperlane Nodes also make it difficult to detect larger nodes against the background cosmic radiation, making Natural Hyperlane Nodes the least accessible with the development of modern technologies.

Hyperlane Gate Armature: a massive two-axis turntable built to handle the weight and power requirements of a Hyperlane Gate. While gates can be used without an armature, and indeed anything but the smallest gate aperture cannot fit into an armature, small facilities that can only afford one gate and need to access multiple hyperlanes or project ships in multiple directions may find it optimal to use an armature.

Hyperlane Gate Pylon: hyperlane gates require a minimum of three pylons to open a hyperlane, however this produces a slow and unstable corridor that is prone to dropping vessels out of their warp phase without warning, leaving a vessel potentially stranded in a wilderness zone. With additional pylons the hyperlane speed is increased by 5% and the instability reduced from 1%/min dephase proc rate by -0.199% per additional pylon above the initial three to a maximum of eight pylons (0.005%/min or 1:20000 chance per minute, +25% hyperlane speed). While a Hyperlane Gate is active, anything can benefit by traveling through it and will automatically align with the gate's point-of-aim as it transitions into warp phase; a vessel receives a speed factor multiplier to its thrusters and a proportionate durability increase to its hull, which is removed if the thrusters shut off (the buff is lost per thruster, the hull buff remains as long as at least one thruster is buffed, maneuver thrusters also remain buffed so long as at least one normal thruster holds a buff) or the ship deviates beyond a 5-degree angle from parallel with an imaginary ray drawn from the originating hyperlane gate. The buff is also dropped if any object is rendered within a 1-degree cone of the ship's front/direction of travel for a minimum of safety. While Hyperlane Gate Pylons can be mounted into an Armature, they can also be installed as a larger fixed gate installation so long as every pylon in the gate is within 50m of two other pylons so that a functioning gate polygon can drawn to create the hyperlane aperture. With a maximum of eight pylons in a gate, this allows a maximum aperture of roughly 100m dia.
 

Attachments

CalenLoki

Master endo
Joined
Aug 9, 2019
Messages
741
#2
There is so many things I disagree with, that I'll start with what I like:

Idea of certain corridors between stations that allow for faster travel is good. It helps concentrating playerbase, thus increase chances of interaction on the road. I.e. piracy would be easier, as you know which route caravans will take.


Now things I don't agree with:

1. Warp in general is bad thing. It removes all "on the road" interactions, as you just disappear at one safe location and appear on another. The line is not much different, as you travel so fast that interception is almost impossible.
2. Too fast travel reduce importance of localised economy. Basically makes the game world smaller long range trading less important.
3. It favours large groups more, as they usually operate over bigger territories.
4. Restricting warp gates by making them extremely expensive excludes all but the largest factions. And they don't need any more help.
5. Bigger gates shouldn't be more efficient tan smaller ones. Quite the opposite. Just to make it worth building smaller ones too. Trade-off>upgrade.
6. IMO scanning shouldn't be simplified to "throw more resources into scanner to increase range". Much more fun if you instead force players to fly around with short range scanners. Coordination skill > grind.
7. There is no such thing as official front of the ship AFAIK. Ships are just blobs of frames, plates and modules. Unless you add dedicated module that dictates the front.
8. Anything with random chance to fail is just bad design. Let it be game of skill, not luck.


Here's alternative idea for high-speed corridors, if we have to have fast travel:

You can equip station with warp field generator.
The bigger, the higher range. Sum of power of generators on the opposite ends determine the range.
It can be one of three types: A, B or C. Only one type can be mounted per station.
If two generators are in range, hyperlane get created between them. Lanes need at least 45 degree angle between each other. If there are two conflicting lanes, the stronger connection takes over.
It's quite narrow corridor (diameter based on sum of generator powers) in a straight line.
Each hyperlane is directional! It only helps travelling from A to B, B to C and C to A. So you can never go back to the same station you just came from without visiting another one. It's mostly to prevent ships going opposite directions from crashing into each other. But also creates need to create complex, non-linear network and interesting trade routes.

Any ship inside corridor is a lot less affected by drag. For every km travelled without leaving corridor, turning back or stopping, drag is reduced by 5% of current value, and max speed is proportionally affected. So it helps with longer trips a lot more than shorter ones.
I.e. after 10km you could travel up to 250m/s, after 20km 415 m/s, ect. Numbers probably need tweaking.
[drag = base drag * (0.95^distance travelled)] [max speed = 150m/s / (0.95^distance travelled)]
It's also double edged sword, as your enemies can use the lane too.
Any object on the lane in front of the ship, within 10s of travel cause rapid increase of drag and reduction of speed limit. So you'll never collide faster than 150 m/s. Objects attached via cargo lock/frame or magboots don't count.
 

Burnside

Master endo
Joined
Aug 23, 2019
Messages
308
#3
You can make a static gate with three pylons and the only other piece you need is a node generator, the lower end cost should be high enough that we don't have hyperlanes running everywhere and causing navigation hazards, which is where the Node Generator comes in. And when i say warp, i just mean "above speed limit travel" not a subspace dimension. The chance to fail just sets a fuzzy maximum range on travel and prevents a player from accidentally or intentionally traveling out into deep space where nothing exists, better to have a long ride home in the belt than lose a ship permanently- hyperlane travel isn't really a skill, placing effective infrastructure is.

ED: covering the remainder
Bigger gates should have a compromise: okay, so... how about extra pylons grant more stability to the hyperlane but lower a ship's boosted speed, that way we have an absolute ceiling on the speed and it's the most easily accessible.

Scanning should... : it's not scanning, nodes and detectors are supposed to function as lighthouses to build warp highway networks, i suppose we could add something like multiple "Node Array Generators" spread across several nearby stations that work in sync to create a Hyperlane Node on the same level of nondetectability as a natural node as well as a Short-Range Anabaryonic Detector that can fit on large ships and has a tier-based timer value, modified by Node quality and range between max value and one-quarter (about 5-20km), on the detection. So, low-tier Nodes are the most detectable (most players can set up and link together cheap hyperlanes), and Node Array Gens and Lagrange Points are the least detectable and the hardest to use to create hyperlane networks, and the best detection occurs within 5km, and minimum detection occurs around 20km.

Random events: very low chance occurrences rarely significantly hamper gameplay but enhance the human habit of casual enjoyable anxiety, if you think a proc rate is too high or low move the decimal place accordingly. Known rates are gameable, RNGs create a fluffy zone of excitement, look at wormholes in EVE, a randomized hyperlane failure rate that exists between 5%-and 0.01% (1:20-1:10000) occurs frequently enough to drive interest and dynamic behavior, the 1:20 rates drive robust construction of hyperlane stations within five "proc units" of each other and gives the player population ample "roadside rescue" gameplay along a fast highway. Big factions will be the drivers of the long, slow, and reliable high-tier routes to avoid their fleet convoys running into high traffic unless speed is absolutely necessary.

FCUs/MCUs create a "front". The alignment bit was merely to help off-angle entries, then again, we're just as fine without that feature and rely on gate entry as a skill-applicable field of interaction.
 
Last edited:

Vexus

Master endo
Joined
Aug 9, 2019
Messages
280
#7
Fast travel is extremely dangerous, as it mostly devalues local travel/movement, shrinks the game world and eliminates the value of going out of the way to get somewhere, since doing so outside fast-travel is just so inefficient. This concentrates players, yes, but only because it would be more efficient, not because it is better gameplay.

I think any ability to fast-travel ships - which are just resources - so any ability to fast-travel any resources is a bad idea. If you see a ship, you should know it took valuable time to arrive to that location, and didn't just make the journey to your location instantly. This time-cost brings value to the game world, where fast travel of materials removes value from the game world.

I do think a fast travel system should exist, but I think it should be player-only where you can be uploaded to another station at some distance, and is a whole different topic I think.
 

CalenLoki

Master endo
Joined
Aug 9, 2019
Messages
741
#8
Fast travel is extremely dangerous, as it mostly devalues local travel/movement, shrinks the game world and eliminates the value of going out of the way to get somewhere, since doing so outside fast-travel is just so inefficient. This concentrates players, yes, but only because it would be more efficient, not because it is better gameplay.

I think any ability to fast-travel ships - which are just resources - so any ability to fast-travel any resources is a bad idea. If you see a ship, you should know it took valuable time to arrive to that location, and didn't just make the journey to your location instantly. This time-cost brings value to the game world, where fast travel of materials removes value from the game world.

I do think a fast travel system should exist, but I think it should be player-only where you can be uploaded to another station at some distance, and is a whole different topic I think.
While I mostly agree, I think that making specific paths significantly faster (maybe up to twice?) Would provide player concentration without noticeable devaluation of distance.

Think of space as vast forest. If there are no roads between two castles, merchants will take semi-random paths through the woods, making bandits unable to ever intercept them.
But if there is an single road, it's just matter of setting up an ambush and waiting. Merchants can still go off the road, for safety. But at cost of speed. Or send scout ahead for early warning. Or create armed caravans.

Ed. Also, to keep it simple hyperlanes could just reduce space jelly drag, while keeping 150m/s speed limit. That would make them extremely simple to implement, as you don't need to worry about high speed collisions. It would mostly help slow ships, so large ones.
It could also have cost for travel: high concentration of space dust that keep corroding/destroying front shield of your ship. That would help large ships too, i.e. carriers, due to square cube law.
 
Last edited:

Vexus

Master endo
Joined
Aug 9, 2019
Messages
280
#9
Think of space as vast forest. If there are no roads between two castles, merchants will take semi-random paths through the woods, making bandits unable to ever intercept them.
But if there is an single road, it's just matter of setting up an ambush and waiting. Merchants can still go off the road, for safety. But at cost of speed. Or send scout ahead for early warning. Or create armed caravans.
This is kind of my point; making arbitrary roads instead of letting the players decide those roads devalues gameplay. Paths through forests weren't created by divine intervention - they were made by people who found a way through the forest. Forcing this is dangerous.

while keeping 150m/s speed limit
There's balance with fighter ships carrying ammo/weapons which slow them down, and transport ships carrying materials slowing them down. If you simply give transport ships more speed "just because" you devalue the balancing mechanic of speed and weight. A pirate, slowed by weapons and ammo, and a transport ship, slowed by carrying materials, might go the same speed. If the pirates cannot even think of reaching the target, then it devalues that gameplay. However without these speed lanes, a transport ship might dump it's cargo when pursued by a pirate to gain speed and then get away. Likewise a pirate ship encountering a faster opponent might shed ammo or detach weapons to get extra speed to get away. If the speed lanes are always faster, it removes a lot of gameplay for not much benefit.

Anyway that's all I have to say on this matter.
 

Burnside

Master endo
Joined
Aug 23, 2019
Messages
308
#10
Part of the reason I use mechanics like random instability, is to allow conventional travel to retain value, especially if one has to plan for falling out of a hyperlane accidentally. Further on the issue, as a modular system, instability softcaps the range on each lane and makes setting a linking station 1) a necessary task for long routes, 2) a matter of tradeoff between how many station links you want to build and maintain as well as how much you trust the instability mechanic's variable. Civil Engineers who want or are tasked with providing assured hi-speed infrastructure are going to either use very stable lanes or use closely spaced hi-speed gates, players comfortable with more risk or at least in the position that they have to deal with it are going to cut costs. A high cost to build or operate, while taking access out of the hands of more casual players (as owner/operators), this too makes hyperlanes less common. Furthermore if a hyperlane gate just works for anyone flying through the aperature, an owner needs to micronanage its operation or levy some sort of station tax to cover some of the costs of public operations, a high station tax (or often any tax at all) will drive players away and work as a natural population management system. While some mechanics might harm gameplay, we're always talking about building in compromises for balance, this is one of those things.

@CalenLoki One thing I noticed about your ABC lane generator method and directional networks, Gates/Nodes already provide this functionality and don't have the drawback and expense of requiring a paired unit of the correct type on the other end, you don't even need a Node Generator unless you're a pirate station trying to pull traffic off a commercial lane or need the bubble effect to catch incoming traffic (or hyperlane ramming attacks) before it gets in too close and becomes its own navigational hazard. Hyperlanes in the Gate/Node method really only need a set of three pylons to function, everything after that provides enhanced functionality.
 
Last edited:

CalenLoki

Master endo
Joined
Aug 9, 2019
Messages
741
#11
This is kind of my point; making arbitrary roads instead of letting the players decide those roads devalues gameplay. Paths through forests weren't created by divine intervention - they were made by people who found a way through the forest. Forcing this is dangerous.



There's balance with fighter ships carrying ammo/weapons which slow them down, and transport ships carrying materials slowing them down. If you simply give transport ships more speed "just because" you devalue the balancing mechanic of speed and weight. A pirate, slowed by weapons and ammo, and a transport ship, slowed by carrying materials, might go the same speed. If the pirates cannot even think of reaching the target, then it devalues that gameplay. However without these speed lanes, a transport ship might dump it's cargo when pursued by a pirate to gain speed and then get away. Likewise a pirate ship encountering a faster opponent might shed ammo or detach weapons to get extra speed to get away. If the speed lanes are always faster, it removes a lot of gameplay for not much benefit.

Anyway that's all I have to say on this matter.
Here, the roads are also built by players: by creating road generators on both ends.

There would be no artificial advantage to any kind of ship, cargo or combat. Just those which can reach over 75m/s would hit the game engine limit of 150.

Catching up with target would be rather easy. While you can't just travel faster than your prey, you can just be in their way. After all they're limited to narrow corridor, and you can see them from 5km away (35s).

Dumping cargo and fleeing out of the lane is always an option.

Part of the reason I use mechanics like random instability, is to allow conventional travel to retain value, especially if one has to plan for falling out of a hyperlane accidentally. Further on the issue, as a modular system, instability softcaps the range on each lane and makes setting a linking station 1) a necessary task for long routes, 2) a matter of tradeoff between how many station links you want to build and maintain as well as how much you trust the instability mechanic's variable. Civil Engineers who want or are tasked with providing assured hi-speed infrastructure are going to either use very stable lanes or use closely spaced hi-speed gates, players comfortable with more risk or at least in the position that they have to deal with it are going to cut costs. A high cost to build or operate, while taking access out of the hands of more casual players (as owner/operators), this too makes hyperlanes less common. Furthermore if a hyperlane gate just works for anyone flying through the aperature, an owner needs to micronanage its operation or levy some sort of station tax to cover some of the costs of public operations, a high station tax (or often any tax at all) will drive players away and work as a natural population management system. While some mechanics might harm gameplay, we're always talking about building in compromises for balance, this is one of those things.

@CalenLoki One thing I noticed about your ABC lane generator method and directional networks, Gates/Nodes already provide this functionality and don't have the drawback and expense of requiring a paired unit of the correct type on the other end, you don't even need a Node Generator unless you're a pirate station trying to pull traffic off a commercial lane or need the bubble effect to catch incoming traffic (or hyperlane ramming attacks) before it gets in too close and becomes its own navigational hazard. Hyperlanes in the Gate/Node method really only need a set of three pylons to function, everything after that provides enhanced functionality.
I already changed my preference from directional ABC lanes to much simpler non directional lanes. I'll try to put it together here:

You can build lane generators. The bigger, the more range.

Two generators in range create a fast traveling road as a straight line between them. All the power not used for range makes the lane wider.
There is minimum 45 angle between lanes. In case of conflict, the wider lane stays.

Any ship or object within the road is affected by space jelly drag 4 times less. So it's possible to achieve 2x higher speed with the same amount of thrusters. Or just travel 4 times more fuel efficient.

Anyone can ente/exit lane at any point. Or place something on the road.

But there is plenty of space jelly dust on the road, so front side of the ship is slowly grinded down as you fly. Even more if you go fast or have huge front surface.

150m/s limit is still there, so collisions won't make game engine choke.
 

Burnside

Master endo
Joined
Aug 23, 2019
Messages
308
#12
Hyperlinking every lane generator within range would get messy fast. At the very least add in the "unwarp wall" from my system and have it scale with the generator's power. That way your tangle of hyperlanes run into large "warp-in" points at the edge of station space and the increasing distance "station space" covers between the hyperlane exit and station actual incentivizes not always building the biggest generator possible.
 

CalenLoki

Master endo
Joined
Aug 9, 2019
Messages
741
#13
True, we don't want hyperlane mess everywhere.
But there are ways to limit it, by playing with numbers.

If the max range is short (i.e. 100km) then there will be way less possible connections. And need to build stations on the way.
Angle limitation would work even better. 90 degree? 120? Hard to tell what would limit the mess without being annoying too much.

The idea of keeping the station itself hyperlane proof is good too. Something like 2% of max range (2km for the biggest, 100km generator).

Btw there is another use for very short hyperlanes. You can build race track out of them, to reward those who can stay precisely on track.
 

Burnside

Master endo
Joined
Aug 23, 2019
Messages
308
#14
Dunno, I dislike the hard-limit ranges and omni-directional lane generators, way too far on the gamey end of the spectrum. The idea behind having a fuzzy definition of where the hyperlane ends is to give players: 1) an exploratory task in setting up the infrastructure, dial in the power just right and install the next station near where the breakpoint in the lane's stability/range tradeoff occurs; 2) create emergent gameplay and tension from the stability mechanic, did you just have a run of bad luck and fall off the hyperlane early or did a pirate group just activate a node generator?

The core idea isn't that a hyperlane will let you fly farther than you normally would between stations, just faster and most in-between stations are small affairs that exist mostly to reinforce the hyperlane network and provide fuel and repairs for people passing through, big shipyards and trading hubs ought to, IMO, wind up becoming the central fixtures of an evolving network. Rather than having skirmishes with your local neighbors, you're more apt to work with them to create hyperlanes between each other as resources slowly dry up in your shared space, with small mining outposts growing off each of your nodes and themselves growing up into the next segments of new hyperlanes in an organic way.

However, I could totally see something like your idea for an omni-directional all-in-one hyperlane/node generator coming in as a Tier-4 system, saved for the biggest pieces of the network. The fact that it needs a generator on each side of the lane to create the connection already implies it's close to endgame tech for bigger factions. On top of that, the one-way nature of how your method connects larger "omni-nodes" to smaller ones means we need something like my gate idea to create a connection back to the 'A-point' from any 'B-points' or 'C-points' which could quite easily be the remains of older, low-tier gate-chains that've been slowly upgraded and obsoleted into a smaller series of slow, long-range gates with a bunch of derelict or barely used "ghost stations" scattered along the way.

As far as how big the "cone" around a hyperlane should be, I'd say 5, maybe 10 degrees max, once you get any distance away from the orginating station it becomes a lot of room and as far as creating a racetrack out of them, even 5deg is a trivial amount of wiggle room if you didn't mess up your initial embarkation, might even want to have the arc of the hyperlane's stability cone be a function of how much power it takes to maintain in addition to the range function. Actually, that's a better way of envisioning the method I'm more for, for every [range]km and degree from the "zero-line" created by a generator or gate, increases instability, omni-node gennies would only have the off-arc instability and a fixed range.

As to how Instability even functions as a mechanic, you could have a time-based proc to check against an RNG (my original suggestion), or the instability could cut your hyperlane speed/inertia boost until you hit 100% and have "dropped out"/"warped out" of the hyperlane, so using a gate, which has range and ...degree? dispersion-based? instability, a gate's range is actually a hard-limit, but as you go outwards your boosted speed begins to slowly drop, actively telling you instability is increasing and you will hit an endpoint eventually. So, longer hyperlanes in gate or "omni-node" format could have a tradeoff of simply having a narrower cone of stability where off-angle travelers gain "instability points" faster the further they are off the "zero-line" rather than always having a lower speed boost, which, again, could be another power-based function. So, you have three power-consuming variables: range, speed, and "stability vector" (the cone effect), it could even be one of those cost-triangles, where a perfectly balanced system divides the power equally three ways and the only way to get more overall power is to increase the size of the hyperlane system whether that's via more gate-pylons or a larger node generator. The main difference between Gates and Omni-nodes being in how they handle the range element, ONs having a fixed, stabilised range that increases with the scale of the device and Gates suffering instability over range and 'dispersion from the lane's vector' by traveling off-angle to the hyperlane's "zero-line".

So, new items list.

Hyperlanes: shunts objects into a special hyperphased-state that reduces inertia and increase maximum speed, objects must remain under acceleration to remain hyperphased and will dephase due to quantum entanglement interactions if a normal-phase object exists within [XXX]m, all hyperlanes have a range, inertia and speed modifier, and stability vector.
Stability Vector: Each Hyperlane is an imaginary quantum macrostructure, a one-dimensional ray, a "zero-line", extending from its origin point out until it becomes unstable and ceases to interact with normal matter, hyperphased matter traveling along a hyperlane encounters increasing instability as it travels off the zero-line, this phenomenon is best explained in layman's terms as a three-dimensional cone, or "vector", more stable hyperlanes have a wider vector while less stable hyperlanes will have a much narrower one. The longer or faster a hyperlane is, the narrower its stability vector tends to be. Objects in a hyperphased-state that accumulate too much Instability will dephase the same way as if they entered a Node or became entangled with normal-phase matter.
Natural Hyperlane Nodes: occur at Lagrange Points, large and difficult to detect with scanning equipment, automatically dephase hyperphased matter that enters into them, Hyperlanes negate a Node's dephasing effect for the first 1km for the purpose of letting vessels exit the dephase area, Natural or Man-Made

Hyperlane Gate Scaffold: a simple scaffolding structure used to frame a Hyperlane Gate, minimum aperture is roughly 10m;
each scaffold section has three add-on points for upgrade parts (i.e. a mix of three different types of hyperlane upgrades and necessary cooling, a minimum-size gate shares heat across all pylons via the scaffolding, larger gates share upgrades because they affect the hyperlane but not cooling)
Hyperlane Gate Pylon: min 3 pylons to create a working gate, max 8, cheapest hyperlane solution, suffers instability over range, very narrow-angle for stability vector, max range between any two working pylons is 50m and all pylons must be aligned along a 2d plane to form a gate, multiple Pylons do not enhance any aspect of the hyperlane it creates while active, but allows more power to be used to create or reinforce it
Hyperlane Gate Armature: a large turntable that can hold, aim, power, and fuel a fully-constructed Hyperlane Gate Scaffold of the smallest size, larger gate apertures require more creative alignment solutions
Hyperlane Detector: a modular device set that can detect a Hyperlane Node within its arc-of-sight, given enough time depending on range and strength of the signal, and output the position as YOLOL code, larger detector arrays have an easier time detecting the fainter signatures of larger Hyperlane Nodes as well as those at longer ranges but take longer to sort the data properly if not given enough processing power (opportunity for a YOLOL-based algorithmic puzzle that coders can write solution-code for?)

Hyperlane Node Generator: a modular device set that creates an Artificial Hyperlane Node, the bigger the generator, the bigger the node, has a 7-axis connection scheme for extra generators or upgrade parts
Hyperlane Node Entangler: part of the Node Generator device set, creates "range-stable" Hyperlanes between any other 'Entangled' Node Generator within range, the hyperlane entry/exit is created at the edge of the Artificial Nodes' surfaces as a visible spatial phenomenon, much like an aurora, the Hyperlane is one-way and always travels from the bigger Node to the smaller in a pair. Entangled Hyperlane Node Generators will not pass through another Hyperlane Node to make a connection. The strength of the Entangler, or the strongest, if a Node Generator has multiple redundancies, determines the range at which connections can be made.

Hyperlane Enhancer: part of the Node Generator and Gate Pylon device set, when connected to a Hyperlane Node Generator or Hyperlane Gate Pylon it increases the size of the Node or the base stability range of the Gate, the effects of multiple Gate Pylons stack with each other.
Hyperlane Stabilizer: part of the Node Generator and Gate Pylon device set, when connected to a Hyperlane Node Entangler or Hyperlane Gate Pylon it increases the stability vector of the Hyperlane created by that device, the effects of multiple Gate Pylons stack with each other.
Hyperlane Projector: part of the Node Generator and Gate Pylon device set, when connected to a Hyperlane Node Entangler or Hyperlane Gate Pylon it increases the speed and inertia factors of the Hyperlane created by that device, the effects of multiple Gate Pylons stack with each other.

Additional modular upgrade parts include coolant boards and radiators to manage the heat produced by these high-power systems.
 
Last edited:
Top