FTL Travel Terminology: Warp, Hyperspace & Jump

Type: Systems — Propulsion & Navigation Status: Canon (confirmed by creator) — full text preserved per archival standard

Source: conversations-001.json, conversation #81, "Temporal mechanics framework" — see Temporal Mechanics Framework: The Book I Manuscript for the full conversation this page is drawn from.

Formalizes Maf's three faster-than-light travel modes and their proper in-universe scientific terminology (as distinct from crew slang): the Warp Bubble (Inertial Nullification Translation Field), Hyperspace (Metric Topology Bridge), and Jump Drive (Maximum Compression Topology Bridge) — plus the physical reason wormhole exits are never exact (Endpoint Metric Variance) and the mandatory post-transit recalibration procedure (Post-Emergence Systems Reconciliation, "PESR"/"Endjump"). See The Principle of Distributed Motion for the underlying time/motion physics this builds on.

Creator: We have 2 types of FTL (faster than light) travel. 1. Warp "Bubble" Colloquially called a warp bubble this field manifests around a ship. The ship remains "at rest" within the "bubble" while the bubble becomes massless and propels the ship at speeds greater than the speed of light. Please generate an in-game scientific term for what in-game scientists and engineers call the "warp bubble." Then 2. Hyperspace. Hyperspace is when a ship generates a wormhole connecting two different locations of the universe together. The wormhole created is said to exist in "hyperspace" although same races call this subspace or other names. The length of the wormhole varies 1. on how far apart the 2 locations a… [truncated for brevity; see full manuscript]

Excellent — this fits very cleanly with what you’ve already built. I’ll give you formal in-game scientific terminology (what engineers, academics, and manuals use), plus the colloquial terms spacers use, and I’ll keep everything consistent with your motion/time framework.

I’ll separate the two systems clearly.

I. Warp “Bubble” FTL

(Field-based superluminal translation)

Formal in-game scientific term

Inertial Nullification Translation Field (INTF)

This is what scientists, engineers, and academies call the “warp bubble.”

You will often see it shortened to:

• INT Field
• INT Envelope (when referring to the ship-sized configuration)

Why this name works (in-universe logic)

• Inertial → relates to mass, resistance to motion
• Nullification → inertia is reduced to (effectively) zero
• Translation → displacement through space without local motion
• Field → a continuous spacetime effect, not a discrete jump

The ship is not moving through space in the normal sense.
Its inertia is decoupled, allowing spacetime to move around it.

This matches your description exactly: - Ship remains at rest relative to its local frame - The field becomes effectively massless - The field translates faster than light - Time inside the field remains near-normal

Common colloquial terms (NPC speech)

• Warp bubble (most common)
• Bubble
• Slip-field
• Null-field
• Blue skin (slang, from visual effects)
• Riding the envelope

Academy manuals tolerate “warp bubble” but insist it is imprecise.

“The ship does not warp. The field does.”
— Standard Academy footnote

In-universe explanation (layman-friendly)

An Inertial Nullification Translation Field surrounds the vessel and removes its inertia. The ship no longer resists motion because, for the purposes of spacetime, it no longer meaningfully possesses mass.

The field itself is then translated through spacetime at superluminal velocity. Since the ship is not moving inside the field, relativistic time loss is minimized.

This neatly avoids: - Violating local speed limits - Crushing the ship - Excessive time dilation

Why warp travel is “safe” for time

In your Distributed Motion model:

• Spatial Motion (%) ≈ 0 (ship is at rest)
• Gravitational Load (%) depends on local environment
• Time Flow (%) remains high

Warp is fast but not instant, and it respects causality globally.

II. Hyperspace / Wormhole Travel

(Topology-altering superluminal transit)

Formal in-game scientific term

Metric Topology Bridge (MTB)

This is the official term for what spacers call “hyperspace.”

Variants used in technical contexts: - MT Bridge - Topology Bridge - Bridged Transit

Why this name works

• Metric → refers to spacetime geometry
• Topology → concerns connectivity, not distance
• Bridge → two locations are joined directly

The ship does not move through space faster than light.
Instead, space itself is reconnected.

Hyperspace vs. Subspace (lore clarity)

Different cultures name the same phenomenon differently:

• Hyperspace — academic / human-standard term
• Subspace — older or alien terminology
• Foldspace — archaic
• The Between — spacer slang

All refer to the same thing:

A non-Euclidean spacetime region created during bridge formation.

How wormhole length works (in-universe)

The internal length of the bridge depends on two factors:

1. Real-space separation of the endpoints
2. Energy applied to bridge compression

Less energy → longer internal transit
More energy → shorter internal transit

This gives you a perfect sliding scale for gameplay.

III. Jump Drive (Instant / Near-Instant FTL)

Formal in-game scientific term

Maximum Compression Topology Bridge (MCTB)

This is what engineers mean by “jump drive.”

Why Jump Drive is not truly a third system

In-universe consensus:

Jump Drive is not a different form of travel.
It is a special operating mode of a Metric Topology Bridge.

A Jump Drive simply: - Applies maximum energy - Compresses the bridge to near-zero internal length - Collapses it immediately after transit

Result: - Transit time: fractions of a second - Energy cost: extreme - Navigation tolerance: very tight

Why spacers treat it as a separate drive

Because functionally: - Warp = continuous motion - Hyperspace = travel through a tunnel - Jump = “blink and you’re there”

So culturally, Jump Drive is discussed as its own thing.

Summary table (clean and game-ready)

NPC-quotable one-liners

• Warp:
  “The ship doesn’t move. The universe does.”

• Hyperspace:
  “Distance still exists. It’s just folded.”

• Jump:
  “Distance exists for a moment… then regrets it.”

If you want, next I can: - Integrate time flow effects for each FTL mode
- Define failure modes (bubble shear, bridge drift, misjump)
- Write an academy comparison chapter explaining why nav officers prefer one over another
- Tie FTL choice into politics, law, and religion

Just tell me where you want to go next.

Creator: And a wormhole's exit into normal space is always just a guess when engineers compute the location to travel to. The exiting spaceship will almost always (in-game -> Always) ("almost always" is what instructors will state to students when studying propulsion systems and methods, but in-game, the location will always vary), vary by hundreds or thousands of miles from that predicted. This may increase to millions of miles for longer transits.

Perfect — this is a very strong design choice, and it slots naturally into both your science and gameplay. Below is a clean in-universe explanation, written the way an NPC academic text or propulsion manual would explain it, with a clear distinction between what instructors say and what actually happens in-game.

Exit Uncertainty in Metric Topology Bridges

(Standard Hyperspace Limitation)

The Official Academic Statement

(what students are taught)

“The emergence point of a Metric Topology Bridge can be calculated with high precision. Minor deviations may occur due to stochastic metric noise and local gravitational gradients, but these are typically negligible at practical scales.”

The phrase “minor deviations” is doing a lot of work here.

The Practical Engineering Reality

(what professionals know)

A wormhole does not reconnect spacetime at a single point.

It reconnects it across a probability volume.

The ship exits somewhere inside that volume.

Engineers can calculate: - The center of the exit volume - The expected radius of deviation

They cannot determine the exact exit point.

In-universe rule (absolute, even if unspoken)

Metric Topology Bridges do not possess deterministic endpoints.

Exit variance is not a flaw. It is a fundamental property of spacetime topology.

Why exit variance exists (in your science)

Three unavoidable factors interact:

1. Metric Grain

Spacetime is not smooth at the scales bridges operate.

When the bridge collapses, it “snaps” to the nearest stable metric configuration — not the mathematically ideal one.

2. Gravitational Gradient Interference

Gravity curves spacetime unevenly.

The bridge endpoint is pulled toward local mass concentrations during collapse, but not predictably.

The stronger and more complex the gravity well: - Stars - Gas giants - Binary systems

…the larger the exit variance.

3. Energy Compression Noise

Higher-energy bridges (especially Jump Drives) compress internal length aggressively.

This increases: - Transit speed - Endpoint instability

Shorter transit ≠ higher accuracy.

In fact, it’s the opposite.

Formal term for the phenomenon

Endpoint Metric Variance (EMV)

Sometimes called: - Exit Scatter - Bridge Bloom - Hyperspace Drift

Academy texts prefer EMV.

The Exit Variance Law (NPC textbook phrasing)

“The exit of a Metric Topology Bridge is not a coordinate but a distribution.”

Typical variance ranges (game-facing)

In-game rule:
➡️ There is always variance. No exceptions.

Why instructors say “almost always”

Because teaching the truth too early causes confusion.

Students expect: - Coordinates - Precision - Determinism

Instructors soften the language:

“Almost always”
instead of
“Always, without exception, and you will never beat it.”

This creates a nice in-universe tension between: - Academy idealism - Field experience

Veteran nav officers often say:

“Anyone promising a perfect exit has never made one.”

Why this does NOT apply to Warp (important distinction)

Warp (INTF) travel: - Moves through normal spacetime - Preserves continuous coordinates - Has cumulative navigational error, not endpoint scatter

Hyperspace: - Breaks and reconnects topology - Cannot preserve exact endpoints

This reinforces why warp is preferred for: - Precision approaches - Formation travel - Military operations near assets

Gameplay advantages of this rule

• Prevents hyperspace “telefragging”
• Forces sublight travel after exit
• Makes nav skill, sensors, and charts meaningful
• Explains why ships don’t jump inside stations
• Creates emergent encounters on arrival

NPC-quotable one-liners

• “You never arrive where you aim. You arrive where spacetime allows.”
• “A jump gets you close. Flying gets you there.”
• “Coordinates are polite suggestions to hyperspace.”

Optional next expansions

If you want, I can next: - Formalize a variance equation tied to distance & energy
- Integrate EMV into jump misfire / anomaly events
- Write a training academy sidebar vs. a veteran engineer’s rebuttal
- Tie exit variance into ancient navigation relics or forbidden tech

Just say the word.

Creator: Also all ships require recalibration after hyperspace travel. There are several reasons for this. 1. The exit location is Never exactly where predicted - requiring scanning and indentifying nearer and farther stars and celestial objects to pinpoint one's location. 2. Creating a wormhole always requires nearly all the power a ship generates. Essentially everything aboard must be powered down, "off," except for life support and minimum shield layering to protect the loss of hull integrity within the wormhole. 3. The wormhole itself is topologically unstable creating cascading electronic failures and degradation of systems at 'Every' electronically powered system aboard the ship including life … [truncated for brevity; see full manuscript]

This is excellent worldbuilding, and it’s internally consistent with everything you’ve established. Below is a fully in-universe, NPC-authored explanation, written in the tone of a propulsion / navigation manual, with clear terminology, doctrine, and cultural practice. I’ll also give you official terminology, crew slang, and a clean reason why this is always required.

I’ll treat this as something that could appear almost verbatim in one of your books.

Post-Transit Recalibration After Metric Topology Bridge Emergence

(Commonly known as Endjump Services)

The Fundamental Rule

No vessel exits a Metric Topology Bridge in a state fit for immediate operation.

This is not a procedural failure.
It is a physical certainty.

Official Term (Academy & Engineering)

Post-Emergence Systems Reconciliation (PESR)

This is the formal name for what spacers call Endjump Recalibration or Endjump Services.

You may see it abbreviated as: - PESR Cycle - Emergence Reconciliation - System Rebind

Academy texts prefer Post-Emergence Systems Reconciliation.

Why PESR Is Always Required

Three independent failures occur during every hyperspace transit.
Any one of them would be enough to demand recalibration.

All three occur every time.

1. Exit Coordinate Indeterminacy

As previously established:

• The exit location is never exact
• Endpoint Metric Variance guarantees positional uncertainty
• Errors scale with transit length

Immediate consequence:

The ship does not know where it is.

All inertial, stellar, and long-baseline nav data is invalidated.

First task after emergence

Re-identify nearby stellar bodies and rebuild a local coordinate frame.

This must be done from scratch.

2. Total Power Reallocation During Bridge Formation

Creating a Metric Topology Bridge requires: - Near-total reactor output - Total collapse of nonessential systems - Temporary shutdown of: - Sensors - Navigation - Communications - Fire control - Secondary shielding - Noncritical life support layers

Only the following remain active: - Primary life support - Minimum hull cohesion fields - Emergency shield skin (thin and unstable)

In-universe phrasing

“During transit, the ship is functionally unconscious.”

3. Topological Instability & Electronic Cascade Damage

The wormhole itself is topologically unstable.

This causes: - Phase noise in power conduits - Desynchronization of system clocks - Microfaults in every active electronic system - Partial memory corruption - Sensor drift - Shield misalignment - Life support desync

No electronic system is immune.

Even hardened military vessels experience this.

The Reconciliation Problem

After emergence, the ship’s systems: - Do not agree with each other - Do not agree with the ship’s structure - Do not agree with local spacetime

Therefore, systems must be:

1. Rebooted
2. Diagnosed
3. Re-synchronized
4. Re-calibrated
5. Cross-validated

This is the PESR Cycle.

Duration of PESR

During this period: - Sensors are unreliable - Weapons are offline or inaccurate - Shields are partial - Communications may be intermittent - Navigation is approximate at best

Operational Status During PESR

The ship is considered blind and vulnerable.

This is why: - Fleets stagger jumps - Escorts form defensive screens - Military doctrine forbids combat jumps unless unavoidable

Analog Navigation During PESR

Because digital systems cannot yet be trusted, ships rely on:

Visual Astrometric Estimation (VAE)

This is performed by Navigation Engineers using: - Optical portholes - Fixed star maps - Parallax measurements - Manual angular calculations - Pre-calculated stellar fingerprint tables

This process produces:

Initial Location Fix (ILF)

Not a coordinate — an estimate.

Chain of Command Procedure

1. Nav engineers generate ILF
2. ILF is reported to the Captain
3. Captain approves dissemination
4. Crew receives First Location Estimate
5. Systems begin digital recalibration using ILF as a seed

Only after multiple passes is a Confirmed Position Solution obtained.

Why precision always improves over time

Each recalibration loop: - Tightens sensor alignment - Improves clock sync - Refines gravitational models - Narrows positional error

But the first fix is never perfect.

Cultural terminology (crew slang)

• Endjump
• The Blind Minutes
• Coming back online
• Finding our feet
• Star-counting
• Rebinding the ship

Common saying:

“You don’t arrive from hyperspace.
You wake up from it.”

NPC-style closing paragraph (book-ready)

Every hyperspace transit ends the same way: with uncertainty. The bridge collapses, the stars return, and for a time the ship knows nothing — not where it is, not what it can trust, not even which of its systems agree with one another. Endjump Recalibration is the act of restoring coherence — between machines, between maps, and between the vessel and the universe it has rejoined.

Optional next steps

If you’d like, I can next: - Formalize PESR as a checklist or flowchart
- Tie recalibration time to ship class & tech level
- Design ambush mechanics during Endjump
- Write a navigation academy training chapter
- Create ancient or forbidden tech that shortens PESR (with consequences)

Just tell me where to go next.