🌀 Jump Drives generate short-lived wormholes that instantaneously transport a vessel across space.
They are portable, high-efficiency FTL systems that balance low Graviolium cost with strict operational constraints.

Unlike Warp Drives, which allow continuous travel, or Jump Gates, which are fixed, Jump Drives offer burst-point FTL with risks and tradeoffs.

There are several different types of jumps available that depend on player interest and unlocked tech. All jump types require line of sight to the destination unless otherwise noted.

• Interplanetary jumps are the entry-level jump type. This type of jump can be achieved at naturally occurring, gravitationally stable places called Jump Points.
• A Jump Point must be surveyed before it can be used; see Zero Force Point below.
• Jump range isn't a factor when jumping between in-system Jump Points.
• Local gravitational fluctuations can affect the success of the jump.
• Degraded Jump Point nav data can affect the success of the jump.

• You must travel outside of a star system's Sphere of Influence to travel interstellar distances.
• The jump drive's maximum jump range becomes a factor when making an interstellar jump.
• Local gravitational fluctuations can affect the success of the jump.
• Other names for this type of jump include Long Jump or Far Jump.

• "Jump drives elegantly dance with space-time, feeling for a moment of perfect balance to perch upon. Jump beacons just sledgehammer it flat."
• Jump beacons are advanced tech that generates an artificial Jump Point.
• They can be located anywhere desired- orbit is best for avoiding crashing into the ground.
• A vessel can initiate a jump from either a Jump Point or a Jump Beacon, and travel to another Jump Point or Jump Beacon.
• But there's a catch: if a Jump Beacon appears along a 20-30 degree cone along the jump line, the ship will end up at the Jump Beacon instead of the intended destination.

• An advanced form of a Jump Beacon, a Jump Gate can not only be placed anywhere, it also doesn't require line of sight to use.
• Vessels don't require their own jump drive.

In classic sci-fi settings, Lagrange points are often used as places where jumps are made, claiming that they're gravitationally stable. In reality, a Lagrange point is where the forces of gravity are couterbalanced by centripetal forces. Blueshift instead uses the lesser-known concept of a Zero Force Point (ZFP). A ZFP is a point in space where the gravitational forces between two bodies cancel each other out. Technically there is a ZFP between any two bodies, which means hundreds of jump points are scattered about and shifting around the star system. But for practical purposes, it's better to limit jump point calculations between star and planet, and planet and moon- unless you've got some good navigation tech.

Zero Force Points must be surveyed to be used as a Jump Point.

Zero Force Points are easily calculated, but they must be surveyed to enable them as Jump Points. The survey process determines:

• Whether gravitational wave turbulence permits a stable Jump Point (there's a chance that a Jump Point would be too unstable to use).
• Gravitational field fluctuations related to the celestial bodies' mass concentrations.
• Graviolium field harmonics required to achieve resonance with the Jump Point and form a wormhole.
• The jump radius, representing the spherical space where a vessel may initiate a jump.
• Gravitational flux tolerance (affects success of the jump; mass concentrations cause slight gravitational fluxuations).
• Predictable patterns that let the nav computer figure out where the Jump Point is at any given time (orbits of the celestial bodies change the Jump Point's position constantly).
• Nav data degredation rate.

To detect the ZFP, you'll need a Gravioli Flux Detector (GFD). This part is non-trivial in size; think Alpha Magnetic Spectrometer (AMS). The real AMS is 5m by 4m by 3m and masses 7.2 metric tons according to NASA. For KSP, we'll use 2m by 1.6m by 1.2m, and 2.88 metric tons. The GFD is a one-shot experiment and requires cleaning or replacement to be used again.

As the detector approaches the ZFP, you'll see messages like:

• Gravity gradient flattening.
• Field harmonics rising.
• Spatial tensor dropping.

When you complete the survey, the ZFP officially becomes a Jump Point and is added to the registry, organized by star system. Behind the scenes, the Jump Point is registered into the network identified by star (e.g. Kerbol_Jump_Points).

Although you can completely automate the survey, having a scientist aboard the survey ship will increase the survey speed and improve the chances of success.

Should a survey fail, the player can spend Science Points to try again.

Hard Core Mode: Imagine requiring a HiRes SAR SCANSat sensor that maps the mascons of the two celestial bodies before a ZFP can be properly surveyed.
From ScanController: if (SCANUtil.GetCoverage((short)SCANtype.ResourceHiRes, b) >= 100). Just use AltimetryHiRes as well as ResourceHiRes, and you've got your mascons mapped.

The Jump Point name is derived from symbols that define the type of Jump Point as well as the names of the two bodies. The order of the symbols and names is based on the celestial body with the largest mass first, followed by the body with the smaller mass. The symbols are Star (S), Planet (P), Moon (M), Special (X). Examples:

• PM-Kerbin-Mun
• PM-Kerbin-Minmus
• SP-Kerbol-Kerbin

In the map view, players will see a custom icon representing an unsurveyed ZFP as well as a custom icon and transparent sphere representing a surveyed Jump Point.

Due to changes in orbital positions, rotations, local spacetime metrics, and so on, surveyed Jump Points degrade over time and must be re-surveyed to update navigation computers. The accuracy of the surveyed data is an additional factor in the success of a jump. In Hard Core mode, you won't need to re-survey the celestial bodies, but you will need to re-survey the ZFP.

Contract Configurator Idea: Contracts are offered that ask you to re-survey Jump Points to update the navigation database.

Star-planet and planet-moon Zero Force Points are easily calculated, predictable and stable, but as mentioned, there can be hundreds of potential Jump Points within a star system. While star-planet and planet-moon ZFPs are the most practical, jump drives can in fact calculate the nearest ZFP between any two celestial bodies, which can then be surveyed as a potential Jump Point. However, these Transient Jump Points have a limited lifetime. The unsurveyed Transient ZFP will become invalid as celestial bodies continue about their orbit, and once surveyed, the Transient Jump Point is only valid for a single use.

Technically, all Zero Force Points are transient in nature due to celestial bodies being in constant motion...

Jump drives aren't a traditional engine like a rocket motor or even a warp drive. Instead, they generate a wormhole from one place to another that stays open just long enough for a vessel to pass through. There are several different jump drive models, but they all have the following characteristics:

• FlexGrav: jump drives are heavily modified FlexGrav generators and still retain that functionality. For reference, FlexGrav generators tune gravity wave harmonics to effectively reverse local gravity, but the effect diminishes as gravity diminishes.
• Flat Spacetime: jump drives require a flat spacetime metric to form the wormhole. It can be done at a naturally occurring Jump Point, outside of a star's Sphere of Influence, or via an artificially flattened spacetime metric generated by a Jump Beacon.
• Linear: the travel path of a jump really wants to go in a straight line.
• Line of Sight: if something blocks the way to the destination, the ship can't jump.
• Limited Range: while not an issue for in-system jumps, when jumping between stars, range becomes a factor. Engineers can coax more jump range at the expense of increased cooldown time and reduced jump success.
• Accuracy Degrades with Distance: a non-issue for in-system jumps, jumping at max range introduces inaccuracies. Pilots and scientists can improve accuracy.
• Spin Up: jump drives require time to prepare to jump. They accumulate Electric Charge that will be used to burst-zap graviolium/gravitonium. Engineers can reduce spin up time at the expense of increased cooldown time and reduced jump success.
• Cooldown: jump drives require time to cooldown before they can jump again. This is literally the case when System Heat is installed.

• 🔧 S2 "Altair" Jump Drive
  This is a first-generation jump drive. It is inaccurate, prone to error, has a long spin up and long cooldown, but it can be upgraded.
  When upgraded after unlocking Jump Technologies, it gains 2 subcomponent bays along with other improved stats.

• 🚀 S3/Mk3 "Deneb" Jump Drive
  Heavy-duty interstellar jump core. Offers unmatched range and charge rate, but it can only make Long Jumps.
  It has 4 subcomponent bays.

• ⚙️ S1/Mk2 "Rigel" Jump Drive
  The smallest and safest jump drive available. Designed for short tactical hops and probes.
  Low power requirements and extremely forgiving - but very limited in range and capacity.
  It doesn't have any subcomponent bays.

Though all Jump Drives retain the FlexGrav capabilities of their ancestor, some Jump Drives have one or more subcomponent bays that provided increased functionality. The subcomponents available are:

• Quantum Waveform Amplifier (Gravity Wave Applications): Modifies the FlexGrav system to warp spacetime like a dedicated warp engine, but it cannot exceed light speed.
• Micro Flux Detector (Jump Technologies): Adds ability to survey Zero Force Points.
• ZFP Navigation Core (Jump Technologies): Calculates the nearest Zero Force Point.
• Quantum Astrogation Core (Advanced Jump Tech): Improves accuracy for interstellar jumps.
• Jump Recovery Optimizer (Advanced Jump Tech): Reduces cooldown time.
• Quantum Resonance Array (Advanced Jump Tech): Improves jump range.

OUTDATED BELOW!!!

REWORK EVERYTHING BELOW

Jump Drives operate based on a set of core physical and navigational rules that make jump planning both strategic and cinematic.

• 📡 Linear Jump ("Jumpline")
  📏 When performing a jump, the vessel travels along a straight line — called the Jumpline — up to its maximum jump range.
  ❌ Obstacles WILL block travel, and drift effects apply.
  🧭 Vessels retain their velocity vector after performing the jump- except when grabbed by a Jump Beacon.

• 🔄 Orbital Jump
  📏 This is also linear travel, but the vessel ends up in a stable orbit of the targeted celestial body if it is in range.
  ❌ Obstacles WILL block travel, and drift effects apply.
  🌌 Conservation of gravity must be observed when performing a jump. This will affect the destination orbit.
  🔧 The vessel's velocity vector will be adjusted to achieve the stable orbit.
  💰 Cost is increased to make a stable orbit compared to Linear Travel.

• To enable Orbital Jump, simply target a celestial body. To enable Linear Jump, don't select a target.
• If linear travel intersects the SOI of a planet or moon, and jumping to planets and moons isn't allowed, then the jump won't activate.
• If the vessel targets a planet or moon, and jumping to planets and moons isn't allowed, then the jump won't activate.
• Targeting a Jump Beacon is always allowed.

• 🎚️ Adjustable Jump Range
  A slider (1–100%) lets the player adjust jump distance, allowing for partial-range jumps.

  • Lower percentage = lower ElectricCharge and Graviolium cost
  • Useful for precision insertions or conserving fuel

• 🧲 Jump Beacon Integration
  If a Jump Beacon is located within a 20–30° cone along the Jumpline and is within maximum jump range, then the vessel will lock to and arrive at the beacon’s location, overriding manual target and/or distance input.

• 🧭 Velocity Conservation
  During Linear Travel, a ship conserves its velocity vector relative to the source star — maintaining momentum and direction — except when jumping to a Jump Beacon, where the vessel does an orbital rendezvous with the Jump Beacon like what happens with Jump Gates.

• 🙈 Blind Jumps
  If the vessel loses its selected celestial body or Jump Beacon during engine warmup, or the target becomes occluded, then the ship will make a random jump, called a Blind Jump - up to its maximum jump range.

  • Velocity is conserved during the jump.
  • There's an increased chance of a mis-jump when performing a blind jump.
  • The ship can still be snared by a Jump Beacon if the blind jump would leave the ship within range.

• 🌌 Gravity Consideration (Open Question)
  🚧 This mechanic is under evaluation and may depend on player feedback or difficulty settings. 🚧
  For Orbital Travel, should gravity be conserved?
  This would affect:

  • Arrival speed near massive bodies
  • Post-jump orbital shape and correction burns
  • Engines are rated for their maximum gravity level.
    • The gravity at the current location, plus the gravity at the destination, must match the engine's rating.
    • Ex: The ship is in a heavy gravity well, and is rated for 1g. It jumps where the gravity is at 0.9g, so its destination orbit must have a gravity level of 0.1g.
    • Put another way, the further away from the current star that the ship jumps away from, the closer to the star the ship can reach.

Under certain risky conditions — such as planetary targeting, occluded jumps, or high jump drift — the Jump Drive system may experience a mis-jump. This is a form of controlled failure, adding tension and consequence to aggressive jump usage.

Mis-jumps can occur when:

• The vessel performs a jump with a high jumpRiskMultiplier
• Jumping to a planet or moon without a beacon
• Jumping through occlusion or gravitational interference
• Jumping while damaged or overcharged
• Performing a blind jump guarantees a mis-jump

• "⚠️ Jump Field Instability Detected — Attempting Correction..."
• "⚠️ Mis-jump Risk Exceeds Safe Threshold!"
• "‼️ Jump Solution Degraded — Emergency Vector Calculated"

• 🛰️ Jump Beacons: Lock vector, eliminate drift and reduce risk
• 🧠 Astrogation Computers: Lower the jumpRiskMultiplier
• 👩‍🚀 Trained Crew: May apply a passive bonus to reduce failure probability
• 🚦 Abort Window: If implemented, allow the player to cancel the jump during charge-up

"Phase instability grows with every variable you fail to control.
The deeper the gravity well, the darker the outcome if you miscalculate.
Most ships reappear. Some... don't."

• Technically mobile, but not easily

Jump Drives are ideal for:

• Frontier expeditions to uncharted stars
• Emergency jumps to retreat or escape
• Bridge ships that support beacon placement

They are not ideal for:

• Combat repositioning
• Precise orbital insertion
• Rapid multi-hop navigation

The jump drive forms wormholes — momentarily, unpredictably.
For a few seconds, your ship becomes a whisper in a storm of mass and momentum.
That’s why you never jump blind… unless you’re ready to miss the target by a star system.

In installations where only one star exists (e.g., the stock Kerbolar system), Jump Drives will adapt their behavior to remain useful:

• In-system stellar orbit jumps are enabled
• Jump Beacons can be deployed to create anchor points
• Planetary orbit jumps are allowed, but may introduce drift or risk penalties

This fallback mode ensures Jump Drives remain viable even before interstellar exploration is unlocked.

Jump engines rely on creating a brief resonance inversion across the vessel's mass geometry.
The farther the jump, the harder it is to maintain waveform coherence across the jump bubble.

Even minor deviations in field stability result in vector drift — often measured in kilometers or more.
While navigational computers attempt compensation, only quantum-linked Astrogators or Jump Beacons can guarantee precise arrival.

• ⚙️ S1/Mk2 "Rigel" Jump Engine
  The smallest and safest jump drive available. Designed for short tactical hops and probes.
  Low power requirements and extremely forgiving — but very limited in range and capacity.

• 🔧 S2 "Altair" Jump Engine
  A general-purpose system for system-wide navigation. Offers solid performance without excessive risk.
  Can be integrated into mid-sized vessels and benefits from Jump Beacon support.

• 🚀 S3/Mk3 "Deneb" Jump Engine
  Heavy-duty interstellar jump core. Offers unmatched range and charge rate,
  but suffers in planetary environments and is highly dependent on support infrastructure.
  Misuse can lead to catastrophic mis-jumps. Requires high orbit and proper field stabilization.

• 🚧 MW-5 “Protostar” Jump Engine One of the only early models that worked… barely. It survived just long enough to get real data. Other prototypes? Disintegrated or disappeared.
  Before quantum field compression was understood, jump engineers tried to brute-force mass into alternate states.
  Consumes Graviolium inefficiently, requiring over 1.5× the cost of modern S3-class engines.
  Prone to mis-jumps.
  Large (5m diameter, 15m long), massive (32t), and bulky.

• The jump engine requires ElectricCharge & Graviolium to activate.
• ElectricCharge is generated by Fusion Reactors.
• The engine absorbs ElectricCharge over time until the required cost is met.
• Once charged, the engine expends the required Graviolium and rapidly discharges ElectricCharge into it to create the wormhole.
• Charging is visible in the UI and supports cinematic FX buildup.

Graviolium jump cost is dynamically calculated based on:

// csharp
totalCost = baseCost
          + (vesselMass × massMultiplier)
          + (jumpDistance × distanceMultiplier)
          + (gravityModifier × gravityStrength × gravityPenaltyMultiplier)

Jump engines culminate in a dramatic Graviolium discharge event that visually marks the formation of the wormhole.
This is the moment when massive amounts of stored ElectricCharge are funneled into the Graviolium core, triggering the jump.

• Energy surge: Electric arcs dance around the drive coil during charge-up
• Field collapse: Sudden implosion or warping distortion just before the jump
• Flashpoint: A sharp visual flash or ripple when the wormhole opens
• Discharge wave: Shockwave, blue plasma arc, or blackhole-like shimmer
• Sound FX: Deep pulse or oscillating hum that builds with charge, then snaps or booms

• Higher-mass vessels = larger discharge effect
• Failed jump = unstable burst of Graviolium plasma or partial flicker
• AI-enhanced ships = cleaner, symmetrical vortex formation

"Graviolium is inert until catalyzed by high-frequency power harmonics.
At the critical moment, the field collapses, and spacetime folds inward,
leaving behind only a brief ripple — and a long silence."

• Calculated based on proximity to the celestial body’s center.
• Uses a quadratic falloff:

    gravityModifier = 1.0 - (distanceFromCenter / SOIRadius)²

If jump efficiency < 40%, the following risks may occur:

• Jump misalignment (appearing off-target)
• System damage (overheat, energy loss)
• Jump failure (cancellation, partial refund)

Thresholds are configurable per engine or global setting.

• After a successful jump, the engine enters a cooldown period.
• Cooldown duration scales with the cost:
• cooldownTime = gravioliumCost × cooldownMultiplier

This prevents immediate repeat jumps and supports strategic retreat timing.

The GRAVMAX Negative Gravioli Detector has upgraded functionality:

• Displays Jump Efficiency %
• Gives a qualitative readiness state: Excellent, Good, Suboptimal, Poor

Uses shared logic from the WBIJumpDriveUtilities class.

Crew, Jump Beacons, specialized computer systems, and more can help reduce the risks and restrictions placed on jump engines. The Jump Beacon and computer system parts are available in Advanced Jump Tech.

Jump Beacons serve as anchor points in space that completely eliminate jump drift and improve jump precision.
They are manually deployed in orbit and must be powered to be effective. The part is 5m in diameter, 20m long, and masses 50t.

• ✅ Eliminates jump drift
• ✅ Allows jumps to planets & moons
• ✅ Enables blind jumps (optional)- the ship performing a blind jump may veer towards the Jump Beacon if within range.
• 🔋 Requires ElectricCharge and Graviolium to maintain lock
• ⚓ Must be placed and activated in advance
• ⚓ Must be calibrated at destination in advance

Specialized computer parts (like Quantum Astrogators or Navigational Cores) improve jump performance.

• 🧩 Configurable — Select the desired effect from the list of options.
• 🔽 Optionally jump drift by a percentage (e.g. 50%)
• ✅ Optionally improves jump range through superior navigation calculations.
• ✅ Optionally allows jumping from occluded positions
• 🧩 Modular — stack multiple assist modules for additive benefit
• ✅ Jump Beacons cancel the drift penalty if the vessel jumps into range of an active beacon.
• ✅ Beacons restore full jump accuracy, even when targeting moons or planets.

• ⏳ Reduces cooldown between jumps

• ✅ Allows jumps to moons and planetary surfaces
• ⚠️ Introduces positional drift penalty or increased misjump chance
• 🔧 Best used when Jump Beacons aren't available at the target.
• 🚫 Does not reduce cooldown or eliminate drift on its own

Normally, jump drives avoid planetary gravity wells due to high field instability.
The Targeting Override Array forcefully synchronizes a jump solution to a planetary body — but at the cost of precision.
When used without proper compensation, the results can be catastrophic.
Skilled pilots and field beacons are strongly recommended.

If allowsOccludedJump = true, consider applying the following mechanics in your jump engine code:

• 🌀 Drift Penalty:
  Add a percentage increase to driftRadius:

  driftRadius *= 1.5; // 50% greater inaccuracy

Increase the chance of:

• ❌ Jump failure
• ⚡ Energy backlash
• 📍 Arrival offset far outside the intended target zone

Display contextual warnings when attempting risky planetary jumps:

• "Warning: Jump Lock Degraded — Navigational Drift Expected."
• "Caution: Planetary Jump Lock Compromised. Engage Beacons or Risk Misjump."

MODULE
{
  name = WBIJumpAssistModule
  driftReductionPercent = 0
  cooldownModifier = 0.75 // Reduces cooldown by 25%
  allowsOccludedJump = false
}