Pointing the ship at a star and jumping is relatively straightforward. Eventually the ship will reach a gravity gradient and be forced out of hyperspace. Pointing the ship at a planet is more complex – the gravity gradients are much smaller, requiring precision, and the heliocentric orbital velocities and different planetary positions introduce all sort of complications.
Generally the aim is to get the ship to drop out of hyperspace as close to the target as possible while matching heliocentric orbital velocities as conveniently as possible.
To initiate a jump, a ship generally has to be outside the Safe Jump Radius of the star and at least 0.05 AU from the nearest planet-sized body (or at least 200 times the planetary radius). The former figure is a Dominion regulatory requirement and the latter a physical one.
A star’s Safe Jump Radius is reckoned to be approximately 200 times the Solar Radius in AU. Operating a starship is a team effort between the Navigator, the Pilot and the Engineer.Space
First – the Navigator calculates the Jump
Apply the following modifiers.
| Condition | Modifier |
| Arrive close to star (close star jumps are harder because the ship is more likely to be forced to leave hyperspace unexpectedly) Close to star is defined as within the star’s Safe Jump Distance. | -2 and worse |
| Arrive at Safe Jump Distance | 0 |
| Arrive far from Star (further star jumps are more difficult to achieve because the gravity threshold is lower.) This is defined as more than 1.5 times the Safe Jump Distance, and is cumulative with other modifiers for target size. | -1 |
| Use Large Gas Giant as Target* | -2 |
| Use Medium Gas Giant as Target* |
-3 |
| Use Small Gas Giant as Target* | -4 |
| Use Large Terrestrial planet as Target* | -6 |
| Use Standard Terrestrial planet as Target* |
-7 |
| Use Small Terrestrial planet as Target* |
-9 |
| Use Tiny Terrestrial planet as Target* |
-11 |
| Use smaller space object as target* | -13 or worse |
| For each additional drive module being used in the jump A ship may use additional drive modules to gain this bonus even if they are not needed to make the jump range; if a drive module is used in this way it counts double the bonus (+2) | +1 |
| Random factors – stellar occlusion and stellar orbital differences† | 3D-10 |
| Precise astrogation data not available | -4 |
| Jump destination is optimised for ease of Nav Plot (for example, used when the destination is a transit point only and ship will jump straight out again) NB: Ignore Base AU coefficient. Ship will arrive near the star or a gas giant. Use orbital data modified by a random factor for in-system travel distances. |
+4 |
*If you plot these courses and they are successful, the pilot has to roll one less die for AU variance.
† See Random Factors below for more detail
Results
| Result
|
Base AU Coefficient |
| Critical Success | 0.05 |
| Success | 0.10 |
| Failure | 0.50 |
| Critical Failure | 1.00 |
| Natural Critical Failure | 5.00 |
Second – the Pilot executes the jump
Apply the following modifiers.
| Condition | Modifier |
| In combat, controlled drift | -2 |
| In combat, any other | -6 |
| Can’t maneuver | -10 |
| Jump plot calls for multiple drives and they are not used (for example, because of damage) | -2 per drive (double if drive is solely being used to improve success chance) |
Results
| Result
|
AU Variance |
| Critical Success | 1D |
| Success | 2D |
| Failure | 3D |
| Critical Failure | 4D |
| Natural Critical Failure | 5D |
- If jumping without having first re-tuned the drives, or with a damaged drive, the result is one level worse than the roll would indicate. This increases by one level for every jump attempted without repair or re-tuning (as appropriate). On a result worse than Natural Critical Failure, the ship either never emerges from Hyperspace, never enters Hyperspace (may or may not explode) or emerges from Hyperspace and explodes.
- It is possible for circumstances to reduce AU variance to zero; a ship will never emerge closer than 80 diameters from a massive object such as a star or planet.
Jumping in Combat
To jump in combat, the pilot will generally need to make one or more Hold Course maneuvers to reach the jump point calculated by the Navigator and then one or more Controlled Drift maneuvers while the jump is actually executed. The final turn must be a Controlled Drift or the pilot must make a roll to cut the engines in time to engage the FTL drive.
| Maneuver
|
Modifier |
| Controlled Drift | 0 |
| Success | 2D |
| Failure | 3D |
| Critical Failure | 4D |
| Natural Critical Failure | 5D |
Jumping in Combat
It usually takes about 9 minutes [I’m using minutes not moments because that’s the time scale the GURPS Space Combat rules are written in.] to spin up the drives. Most space combat will be fought in standard scale 3-minute turns, so three turns. The drives must have sufficient power for the jump applied to them for these three turns.
The ship will jump at the end of the third turn.
Procedure
Determine AU Variance by rolling the number of dice shown to by the result of the pilot’s roll and multiply the result by the coefficient given as a result of the navigator’s roll.
The result is how many thrust-equivalent AU* the ship has arrived from its target. Mostly, ships arrive about 0.7 AU away.*Thrust-equivalent AU is given as an acceleration from rest then deceleration for simplicity of game mechanics. In reality the ship could have a different emergent velocity vector to the heliocentric orbital speed of the target or other jump-exit issues.
Jump Time
An engineer may roll to reduce time in jump by tweaking and tuning the drive as the jump is executed. For every point the engineer succeeds on their roll the ship reduces travel time by 2.5%, a critical success doubles this factor, up to a maximum of 50% reduction. Failure increases the travel time by 3D%. Critical failure also damages the drive in some way.Calculating Jump Time
The effect of the engineer’s work can usually be determined once 20% of the jump’s standard duration has been completed. This can be done by either the Engineer or the Navigator using their respective skills. -2 for every 5% duration before 20%, +1 for every 5% duration afterwards. It is not unknown for ships to run a sweep on jump exit time, with the book closing once 10% or 15% of jump has been competed.
Re-tuning the Drive
Once a jump is made, the FTL drives have to be re-tuned. This is not a simple matter of feeding them power, but requires re-tuning (sometimes called harmonisation in Engineer-speak) of certain drive components by the engineering staff at the same time.
Every drive module used in a jump takes an engineer four hours + one hour per FTL speed to re-tune and requires an allocation of an energy point during the process. Multiple drive modules can be re-tuned at the same time if there are sufficient power points and engineers available (putting multiple engineers or power points on a single drive module does not reduce the time). If the process is interrupted, it must be restarted. An engineer can roll to speed the process, reducing the base time to three hours on a success or two on a critical success. Failure increases the base to eight hours and critical failure doubles the total time. See Executing the Jump, above, for effects of not tuning the drive before jumping.Emerging from Jump
The jump space drop out is one of the most important times for the flight crew on a starship. The Pilot must be ready to take evasive action in case there is an immediate threat, the Navigator must try and establish the actual location of the ship, the Scan officer must try and determine the nature of local traffic or obstacles to advise the pilot of threats and the Comms officer must try and unscramble the variously time-delayed comms traffic and determine what is going on. The Engineering department is on stand-by in case there are any mechanical issues or emergencies that need attention, but do not usually have any urgent tasks.
Both Comms and Scan are affected by a phenomenon known as Jump Light Lag. This is the result of a combination of two factors:
- emissions reaching the ship’s passive sensor array are limited to travel at the speed of light; and,
- there is no context for any of the signals prior to arrival in system.
It takes time, based on doppler radar data and lateral movement to determine range and direction of anything detected, and any communications picked up from a distant object will be subject to lag as well.
Consider the diagram below:
- The instant the ship arrives in system it receives two communications.
- In reality, these signals were generated 500 and 350 seconds ago from ships 1AU and 0.7AU distant, respectively.
- This means communications may be received out of chronological order.
The very long ranges are shown here for effect, and relate mostly to lags in communications traffic. Detection ranges are realistically much shorter. Typically, ships can detect other ships travelling under thrust in open space at a distance of 1 light second (300,000 km) about 75% of the time. Bigger and closer ships are easier to detect, as are ships using active sensors. Smaller ships, ships with stealth masking, on low power, drifting, or with a stellar object such as a star or planet behind them, are more difficult to detect (but noting that bigger ships generally have better sensor arrays). It takes a minimum of 20 seconds to do a complete scan around a ship, taking longer increases the chance of a successful detection. For more info, see GURPS Spaceships, pages 14-15, 44-45.
Random Factors
Planets and stars move. While not a huge surprise to anyone, the orbital dynamics of a stellar system can affect how easy or difficult it is to perform a hyperspace jump. As part of determining the difficulty of making a hyperspace jump the GM should roll 3D-10 and add that figure to the difficulty modifier.
If it is necessary to simulate how this factor changes over time, roll another 3D-10 once per Cycle:
-
If the roll is higher than the previous modifier, increase the modifier by 1;
-
if lower, decrease the modifier by 1;
-
if it is the same, roll 3D again – this is the number of days that the modifier will remain as it is before the GM needs to roll again.
Each jump route from a world has a different modifier that changes on its own schedule.
All starports in the dominion publish predictive jump tables, sometimes for hundreds of cycles in advance.
Alternately a Navigator with access to astronomical equipment or positional data for stellar objects can calculate them. This is not a difficult task (an unmodified roll is sufficient), but it takes at least a day if there is no positional data available.
For example, the table shows how a jump modifier can change over time. In this case, assuming it is Cycle 1 if the ship is not in a hurry, the best jump window out of system is in 3 Cycles time.
| Date | First 3D roll | Effect/ Second 3D roll | Jump Modifier |
| Cycle 1 | 6 | -4 | |
| Cycle 2 | 13 | + | -3 |
| Cycle 3 | 12 | + | -2 |
| Cycle 4 | 11 | + | -1 |
| Cycle 5 | 5 | – | -2 |
| Cycle 6 | 13 | + | -1 |
| Cycle 7 | 4 | – | -2 |
| Cycle 8 | 8 | 14 | -2 |
| Cycle 9 | 13 | -2 | |
| Cycle 10 | 12 | -2 | |
| Cycle 11 | 11 | -2 | |
| Cycle 12 | 10 | -2 | |
| Cycle 13 | 9 | -2 | |
| Cycle 14 | 8 | -2 | |
| Cycle 15 | 7 | -2 | |
| Cycle 16 | 6 | -2 | |
| Cycle 17 | 5 | -2 | |
| Cycle 18 | 4 | -2 | |
| Cycle 19 | 3 | -2 | |
| Cycle 20 | 2 | -2 | |
| Cycle 21 | 1 | -2 | |
| Cycle 22 | 13 | + | -1 |
| Cycle 23 | 15 | + | 0 |
| Cycle 24 | 13 | + | +1 |
| Cycle 25 | 12 | + | +2 |
| Cycle 26 | 11 | – | +1 |
| Cycle 27 | 8 | – | 0 |
| Cycle 28 | 16 | + | +1 |
| Cycle 29 | 10 | – | 0 |
| Cycle 30 | 13 | + | +1 |
| Cycle 31 | 10 | – | 0 |
| Cycle 32 | 10 | 9 | 0 |
| Cycle 33 | 8 | 0 | |
| Cycle 34 | 7 | 0 | |
| Cycle 35 | 6 | 0 | |
| Cycle 36 | 5 | 0 | |
| Cycle 37 | 4 | 0 | |
| Cycle 38 | 3 | 0 | |
| Cycle 39 | 2 | 0 | |
| Cycle 40 | 1 | 0 | |
| Cycle 41 | 11 | + | +1 |
| Cycle 42 | 13 | + | +2 |
| Cycle 43 | 10 | – | +1 |
| Cycle 44 | 12 | + | +2 |
| Cycle 45 | 8 | – | +1 |
| Cycle 46 | 8 | – | 0 |
| Cycle 47 | 16 | + | +1 |
| Cycle 48 | 13 | + | +2 |
| Cycle 49 | 9 | – | +1 |
| Cycle 50 | 13 | + | +2 |