- Joined
- Jul 5, 2015
- Messages
- 252
- Reaction score
- 51
Last night I got thinking, and came up with a suggestion that would add much-needed functionality to Jump gate computers. My suggestion is detailed below. It is very similar to how transporters function at the moment, and the approach could simplify setting up gate travel networks, because the player wouldn't have to travel to a gate destination unless they actually want to set up a new node in the gate travel network.
Updated Jump Gate Logistics
1. Jump gate computer needs to have an UI.
This would be similar to the transporter computer UI and allow the gate to connect to of any other jump gates within jump gate range(as specified in configs, so the range would be variable). Like the Transporter interface, this would show a list of available gates(searchable and indexed) with sector coordinates and the name of the entity they are on, and possibly, like with transporters allow the actual gate computer to be named, in case there are multiple gates on the same entity. It would also allow the user to enable and disable gate travel at will (in order to prevent enemies from using the gate as an entry point or as a feature to cut power consumption on the station), and either set the gate for public use or Faction only.
This would also restrict gate travel to sectors with established gates in them, and eliminate the current trend of setting temporary one-way gate destination, so they could jump to a random enemy sector to set up a staging point for an attack. It would also mean that using a marker beam to set gate destination would be obsolete, because the gate computers themselves would be used to set the destination, instead of relying on external meta-items.
2. Jump gates need to be gate-to-gate, instead of gate-to-sector.
Instead of having the gate jump go from the source gate to the destination sector, the jump needs to go from gate-to-gate, preserving the momentum and course of the entering ship or player (a ship entering the source gate would exit on the opposite side of the destination gate, depending on gate module orientation). This would allow building jump gates as interior structures, an builders could plan where the traveling entity will appear upon exiting the gate.
Updated Jump Gate Logistics
1. Jump gate computer needs to have an UI.
This would be similar to the transporter computer UI and allow the gate to connect to of any other jump gates within jump gate range(as specified in configs, so the range would be variable). Like the Transporter interface, this would show a list of available gates(searchable and indexed) with sector coordinates and the name of the entity they are on, and possibly, like with transporters allow the actual gate computer to be named, in case there are multiple gates on the same entity. It would also allow the user to enable and disable gate travel at will (in order to prevent enemies from using the gate as an entry point or as a feature to cut power consumption on the station), and either set the gate for public use or Faction only.
This would also restrict gate travel to sectors with established gates in them, and eliminate the current trend of setting temporary one-way gate destination, so they could jump to a random enemy sector to set up a staging point for an attack. It would also mean that using a marker beam to set gate destination would be obsolete, because the gate computers themselves would be used to set the destination, instead of relying on external meta-items.
2. Jump gates need to be gate-to-gate, instead of gate-to-sector.
Instead of having the gate jump go from the source gate to the destination sector, the jump needs to go from gate-to-gate, preserving the momentum and course of the entering ship or player (a ship entering the source gate would exit on the opposite side of the destination gate, depending on gate module orientation). This would allow building jump gates as interior structures, an builders could plan where the traveling entity will appear upon exiting the gate.