LONG DISTANCE SC
Those binary+ systems with long distance treks to outlying stations are either a game wasting it's resources or a player wasting his/her time. If these were real life distances and speeds (and credits) we wouldn't think twice about traveling 45 minutes with a load of goods out to a distant station, dropping them off and getting paid. But in a game, piloting a ship in a staight line for 45 minutes is just plain boring no matter how realistic that straight line may be. It becomes Elite Train Simulator 2015 without any scenery. Yes "space is big". So what to do?
WHY NOT MICROJUMPS?
It has been proposed by some that in-system microjumps are the answer. I disagree because it's an idea that feels broken in several ways. In many systems this would utterly break the pirate/inderdiction mechanic (which is already hard enough). Mechanically, it seems, FSD's don't really work that way and from my point of view supercruise is already pretty well balanced. If implemented you would need new lore to explain how FSD's distinguish (based on gravity) between a normal hyperspace jump and a microjump. Additionally, microjumps seem like a gimme, and offer no danger and/or risk. I think most importantly, it speaks to the real broken mechanic, hyperspace. So perhaps we should attempt to fix hyperspace instead of fixing/breaking supercruise.
GRAVITY
Gravity, it seems, makes the Frame Shift Drive work. Without it the FSD computer has nothing to lock on to and therefore nowhere to go. Now, there really should be no reason an x,y,z coordinate couldn't be plugged in, a vector and fuel consumption calculated and a destination (any destination) jumped to. But the FSD, though brilliant by design, is a fickle . It's computer is smart enough not to jump us straight into the middle of a gravity source (like star) but isn't smart enough to jump us to an x,y,z coordinate near a gravity source without a gravity lock some x,y,z distance near to it. The game and lore is missing an opportunity here and with the SC issue I think we can introuce a mechanic that fixes both without breaking both.
FSD Jump Mechanics
Just as an FSD hyperspace jump has an upper limit (max range based on max fuel dump) it is reasonable to assume that it also has a lower limit (min range based on min fuel dump). And I would suggest that the lower limit is about 1 Ly. To put it another way, the mechanics of the FSD are such that a minimum portion of fuel (something like .05 to .27 tons depending on the ships mass and installed drive) MUST be dumped in order to engage in a hyperspace jump and that portion happens to equate to about a 1 Ly jump. Any less and the drive simply won't engage. This would therfore be true for all ship masses and all classes and grades of FSD. Which necessarily means that if we're in a a system with stations waaaaaay out there but not greater than 1 LY then we'll need to supercruise out. The SC mechanic is left untouched and intact. Pirates rejoice.
But with that mechanic there is a new alternative to navigation. We will now use NAV Beacons along with a new mechanic... JUMP NAVIGATION.
NAV BEACON'S
NAV Beacons don't currently serve much purpose in ED. They could, however, act as a relay for in-system stations that would allow us to peruse READ ONLY shipyard, outfitting, top bounties, bulletin board missions, and commodities data for all stations in the system. I believe others have suggested this in the past and it is something I agree with. But more importantly (and to the topic), they would also store updated orbital system data obtained by Universal Cartographics. NAV Beacons would therefore become activity hubs for ALL professsions in most systems. But for the player wanting to cut down the SC time in a neighboring system they will become essential.
MODULE
Assuming that we're already in a neighboring system with a NAV Beacon we'll need some way of communicating with it. To get the station relay feeds (shipyard, commodities, etc.) we just need to target the NAV Beacon and scan it (just point our ship towards it). No additional modules are needed. When the scan is completed we just pick a station from the list and the READ ONLY UI for that station pops up. This UI looks identical to the station UI, however no interactions with the data can be made. It is READ ONLY.
The Universal Cartographics orbital data stored in the NAV Beacon is NOT compatible with our FSD computer. But without this data our FSD must use large gravity sources, like stars, in order to make hyperspace jumps. We can however get this data translated. To do so, we'll need to purchase and install a Gravimetric Translation Array (GTA) module from a station. Though large and bulky, this module will translate the orbital data into gravity coefficients our FSD can understand. To make the GTA connection, we'll simply target the NAV beacon, select the GTA fire group and activate it. After a long series of audible BWEEPS we'll recieve a message "GTA: SECURE LINK ESTABLISHED". Note: targeting any other object breaks our connection.
FULL SYSTEM DATA
Now that we're connected to the NAV Beacon with our GTA, we can open our galaxy map and choose the system information for the system we want to jump to. Here there are two possible states. We either have the full system data or we don't. If we don't have the full system data then we'll see a message displayed below the system name: "FULL SYSTEM DATA MISSING". If we want to be able to jump navigate this system then we'll need to acquire it. We can either explore the system and detail scan ALL the bodies (including roid belts and extraction sites) OR we can click the "PURCHASE FULL SYSTEM DATA" button below the message. Note: now that this data is more useful it's also MUCH more expensive.
DATA TRANSLATION
Now that we've acquired the data a new message is displayed below the system name: "THIS SYSTEM IS JUMP NAVIGABLE". Now we'll select the body that we want to jump to (like the one with that far off station .22 LY from the main star) and click the "PLOT DIRECT JUMP" button. The following message is overlayed on the system information screen: "GTA: RECEIVING UPDATED ORBITAL DATA". Once the data has been downloaded from the NAV Beacon we'll receive a another message: "GTA: TRANSLATING ORBITAL DATA". The higher the grade GTA installed, the faster the translation will be: E:24 sec. D: 21 sec. C: 18 sec. B: 15 sec. A: 12 sec. Once the translation has completed, our FSD computer then plots the final vector to within .5 Ls of the selected body. Note: We can close our galaxy map as soon as the translation has begun.
JUMP
Once our FSD has received the translated data and plotted the vector we'll recieve the "ALIGN SHIP TO JUMP VECTOR" message. Now we just align our ship to the jump vector icon and engage our FSD to travel directly to our destination. Assuming the body was within our max Ly jump range, we'll arrive approximately .5 Ls from the selected body directly above it's north/south pole. NOTE: We will always exit hyperspace at one of the poles. Pirates, you know where to look.
And there you have it. We've just executed our first JUMP NAVIGATION sequence. We didn't break lore (or the game). We didn't break SC. We didn't break FSD. We didn't break pirating (actually we enhanced it). We added choice with a tradeoff. We added convenience with a risk. We added danger!
ABSTRACT
Praise, bash, discuss.
Those binary+ systems with long distance treks to outlying stations are either a game wasting it's resources or a player wasting his/her time. If these were real life distances and speeds (and credits) we wouldn't think twice about traveling 45 minutes with a load of goods out to a distant station, dropping them off and getting paid. But in a game, piloting a ship in a staight line for 45 minutes is just plain boring no matter how realistic that straight line may be. It becomes Elite Train Simulator 2015 without any scenery. Yes "space is big". So what to do?
WHY NOT MICROJUMPS?
It has been proposed by some that in-system microjumps are the answer. I disagree because it's an idea that feels broken in several ways. In many systems this would utterly break the pirate/inderdiction mechanic (which is already hard enough). Mechanically, it seems, FSD's don't really work that way and from my point of view supercruise is already pretty well balanced. If implemented you would need new lore to explain how FSD's distinguish (based on gravity) between a normal hyperspace jump and a microjump. Additionally, microjumps seem like a gimme, and offer no danger and/or risk. I think most importantly, it speaks to the real broken mechanic, hyperspace. So perhaps we should attempt to fix hyperspace instead of fixing/breaking supercruise.
GRAVITY
Gravity, it seems, makes the Frame Shift Drive work. Without it the FSD computer has nothing to lock on to and therefore nowhere to go. Now, there really should be no reason an x,y,z coordinate couldn't be plugged in, a vector and fuel consumption calculated and a destination (any destination) jumped to. But the FSD, though brilliant by design, is a fickle . It's computer is smart enough not to jump us straight into the middle of a gravity source (like star) but isn't smart enough to jump us to an x,y,z coordinate near a gravity source without a gravity lock some x,y,z distance near to it. The game and lore is missing an opportunity here and with the SC issue I think we can introuce a mechanic that fixes both without breaking both.
FSD Jump Mechanics
Just as an FSD hyperspace jump has an upper limit (max range based on max fuel dump) it is reasonable to assume that it also has a lower limit (min range based on min fuel dump). And I would suggest that the lower limit is about 1 Ly. To put it another way, the mechanics of the FSD are such that a minimum portion of fuel (something like .05 to .27 tons depending on the ships mass and installed drive) MUST be dumped in order to engage in a hyperspace jump and that portion happens to equate to about a 1 Ly jump. Any less and the drive simply won't engage. This would therfore be true for all ship masses and all classes and grades of FSD. Which necessarily means that if we're in a a system with stations waaaaaay out there but not greater than 1 LY then we'll need to supercruise out. The SC mechanic is left untouched and intact. Pirates rejoice.
But with that mechanic there is a new alternative to navigation. We will now use NAV Beacons along with a new mechanic... JUMP NAVIGATION.
NAV BEACON'S
NAV Beacons don't currently serve much purpose in ED. They could, however, act as a relay for in-system stations that would allow us to peruse READ ONLY shipyard, outfitting, top bounties, bulletin board missions, and commodities data for all stations in the system. I believe others have suggested this in the past and it is something I agree with. But more importantly (and to the topic), they would also store updated orbital system data obtained by Universal Cartographics. NAV Beacons would therefore become activity hubs for ALL professsions in most systems. But for the player wanting to cut down the SC time in a neighboring system they will become essential.
MODULE
Assuming that we're already in a neighboring system with a NAV Beacon we'll need some way of communicating with it. To get the station relay feeds (shipyard, commodities, etc.) we just need to target the NAV Beacon and scan it (just point our ship towards it). No additional modules are needed. When the scan is completed we just pick a station from the list and the READ ONLY UI for that station pops up. This UI looks identical to the station UI, however no interactions with the data can be made. It is READ ONLY.
The Universal Cartographics orbital data stored in the NAV Beacon is NOT compatible with our FSD computer. But without this data our FSD must use large gravity sources, like stars, in order to make hyperspace jumps. We can however get this data translated. To do so, we'll need to purchase and install a Gravimetric Translation Array (GTA) module from a station. Though large and bulky, this module will translate the orbital data into gravity coefficients our FSD can understand. To make the GTA connection, we'll simply target the NAV beacon, select the GTA fire group and activate it. After a long series of audible BWEEPS we'll recieve a message "GTA: SECURE LINK ESTABLISHED". Note: targeting any other object breaks our connection.
FULL SYSTEM DATA
Now that we're connected to the NAV Beacon with our GTA, we can open our galaxy map and choose the system information for the system we want to jump to. Here there are two possible states. We either have the full system data or we don't. If we don't have the full system data then we'll see a message displayed below the system name: "FULL SYSTEM DATA MISSING". If we want to be able to jump navigate this system then we'll need to acquire it. We can either explore the system and detail scan ALL the bodies (including roid belts and extraction sites) OR we can click the "PURCHASE FULL SYSTEM DATA" button below the message. Note: now that this data is more useful it's also MUCH more expensive.
DATA TRANSLATION
Now that we've acquired the data a new message is displayed below the system name: "THIS SYSTEM IS JUMP NAVIGABLE". Now we'll select the body that we want to jump to (like the one with that far off station .22 LY from the main star) and click the "PLOT DIRECT JUMP" button. The following message is overlayed on the system information screen: "GTA: RECEIVING UPDATED ORBITAL DATA". Once the data has been downloaded from the NAV Beacon we'll receive a another message: "GTA: TRANSLATING ORBITAL DATA". The higher the grade GTA installed, the faster the translation will be: E:24 sec. D: 21 sec. C: 18 sec. B: 15 sec. A: 12 sec. Once the translation has completed, our FSD computer then plots the final vector to within .5 Ls of the selected body. Note: We can close our galaxy map as soon as the translation has begun.
JUMP
Once our FSD has received the translated data and plotted the vector we'll recieve the "ALIGN SHIP TO JUMP VECTOR" message. Now we just align our ship to the jump vector icon and engage our FSD to travel directly to our destination. Assuming the body was within our max Ly jump range, we'll arrive approximately .5 Ls from the selected body directly above it's north/south pole. NOTE: We will always exit hyperspace at one of the poles. Pirates, you know where to look.
And there you have it. We've just executed our first JUMP NAVIGATION sequence. We didn't break lore (or the game). We didn't break SC. We didn't break FSD. We didn't break pirating (actually we enhanced it). We added choice with a tradeoff. We added convenience with a risk. We added danger!
ABSTRACT
- Supercruise mechanic is unchanged.
- FSD mechanic is changed to allow direct jump navigation (with specific limitations).
- User must make a choice (risk) to use the new FSD mechanic (it's module based and requires entry to NAV Beacon instance).
- User must accept a tradeoff (module) to use the new FSD Mechanic.
- Risk of pirating is maintained. Common destinations are known via high traffic ports or long distance SC destinations, hyperspace entry locations are known (NAV Beacons) and hyperspace exit locations are known (poles).
- NAV Beacons become useful (and more dangerous). High-activity player hubs.
- Cartographics data becomes more useful (and more expensive).
- Exploration balanced. Deep space explorers will not benefit from this mechanic, because of the NAV Beacon requirement. However, now that exploration data is more useful (and more expensive) the payout is accordingly higher.
- Lore is maintained.
- Gameplay is enhanced.
Praise, bash, discuss.
