Jump Calculators: Understanding Your Ship's Heat and Fuel Limits

Published November 4, 2025 • 8 min read

In EVE Frontier, jump drive mechanics are governed by two fundamental constraints: heat buildup limits how far you can jump in a single hop, and fuel capacity determines your total trip range. For pilots planning long-distance routes, understanding these limits is critical.

We just shipped Jump Calculators—a seemingly simple feature that turned into a fascinating exercise in iterative UX refinement. What started as a quick afternoon project became a multi-day polish marathon, revealing how much difference thoughtful interface design makes for complex calculations.

The Feature Request

The initial request was straightforward: add two calculators to the Reachability panel in our routing tools:

1. Single Jump Range (Heat-Limited): How far can you jump based on current temperature and ship mass?
2. Total Trip Distance (Fuel-Limited): How far can you travel with your current fuel load?

Each calculator needed to account for ship-specific stats (mass, specific heat capacity, fuel tank size), fuel quality (D1 at 10% vs EU-90 at 90%), and cargo grids. Simple enough, right?

The Formulas

EVE Frontier's jump mechanics are deterministic. The formulas aren't published officially, but the community has reverse-engineered them:

Heat-Limited Jump Range

range = (MAX_TEMP - current_temp) × ship_specific_heat × HEAT_CONSTANT / current_mass

// Where:
// MAX_TEMP = 150
// HEAT_CONSTANT = 3
// ship_specific_heat = varies by ship (4.0 for Recurve, 11.0 for Chumaq)
// current_mass = bare hull + cargo + fuel

Fuel-Limited Trip Distance

range = fuel_volume × fuel_quality / (FUEL_CONSTANT × ship_mass)

// Where:
// FUEL_CONSTANT = 0.0000001 (1e-7)
// fuel_volume = liters (fuel_quantity × 0.28 m³/unit)
// fuel_quality = 0.1 to 0.9 (10% to 90% purity)

The second formula took several iterations to get right. Initial versions had the fuel volume wrong (0.01 m³ instead of 0.28 m³) and the constant off by nearly 80x (0.00001 vs 0.0000001). We validated against known ship data—a Reflex with 5,286 units of fuel should get ~813 light-years—and adjusted accordingly.

The Initial Implementation

The first version took about 2 hours to build:

• Ship database with 11 vessels (Recurve to Chumaq)
• Fuel types (D1, D2, SOF-40, EU-40, SOF-80, EU-90)
• Two calculator sections with dropdowns and number inputs
• Real-time calculation as values change
• localStorage persistence

We hooked it into the existing Reachability panel, ran a quick smoke test, and shipped to preview. Done!

Except... not really.

The User Feedback Loop

After the first user testing session, feedback started rolling in. What followed was a ~4-hour refinement process that doubled the initial development time. Every change was small individually, but together they transformed the feature from "functional" to "polished."

Round 1: Visual Consistency

Problem: Dropdown boxes had white backgrounds (couldn't read text on some monitors).

Solution: Match the site's charcoal theme (#2a2a2a) with accent color highlights.

Round 2: Space Efficiency

Problem: The panel was too tall for 1080p displays. Users had to scroll.

Solution: Rearrange inputs into side-by-side pairs:

• Current Temperature ↔ Current Mass
• Fuel Type ↔ Cargo Grids

This reduced vertical height by ~40% without sacrificing readability.

Round 3: Number Formatting

Problem: Mass values like "9750000" are hard to parse at a glance.

Solution: Add comma formatting ("9,750,000 kg"). This required switching from type="number" to type="text" inputs with custom formatting functions:

const formatNumberWithCommas = (num: number): string => {
  return num.toLocaleString('en-US');
};

const parseFormattedNumber = (str: string): string => {
  return str.replace(/,/g, '');
};

Round 4: The Mass Field Surprise

This is where things got interesting. User testing revealed a critical confusion: the calculator auto-populates with bare hull mass, but in reality, your ship is almost never at bare hull weight. You have cargo, fuel, ammunition, modules—all adding mass.

First attempt: Add a warning tooltip.

Second attempt: Make the warning icon bigger (25% increase to fontSize: 14).

Third attempt: Add increment/decrement buttons (±250,000 kg steps) so users don't have to type large numbers.

Fourth attempt: Implement "smart snapping"—the first click rounds up to the nearest 250k increment, making values cleaner:

• Lorha at 31,000,000 kg → click up → 31,250,000 kg
• MCF at 52,313,760 kg → click up → 52,500,000 kg
• Subsequent clicks add/subtract 250k normally

Fifth attempt: Handle pasted values from in-game. Players can right-click their ship, go to Attributes, and copy mass. But the clipboard contains HTML:

<color=0xffffff00>3,046,250,638 kg</color>

We added a special paste handler that strips HTML tags, removes "kg", and extracts the numeric value:

const stripGameFormatting = (str: string): string => {
  let cleaned = str.replace(/<[^>]*>/g, ''); // Remove HTML
  cleaned = cleaned.replace(/\s*kg\s*$/i, ''); // Remove "kg"
  cleaned = cleaned.replace(/,/g, ''); // Remove commas
  return cleaned.trim();
};

The Lesson: Input Fields Matter

Here's what surprised us: roughly 70% of the post-launch refinement time was spent on a single input field—Current Mass. Not the core calculations, not the formulas, not the ship database. Just getting mass entry right.

Why did this field need so much attention?

1. High precision matters: A 250k kg difference significantly affects jump range
2. Large numbers are cognitively taxing: Reading "52313760" vs "52,313,760" makes a huge difference
3. Data entry friction: Typing 8-digit numbers is error-prone
4. Context mismatch: Game shows fitted mass, calculator defaults to bare hull
5. Format impedance: Pasted data from game includes formatting

The final mass input includes:

• Comma-formatted display
• HTML/tag stripping on paste
• Smart increment buttons (±250k)
• First-click snap-to-nearest-250k
• Warning tooltip with copy/paste instructions
• Minimum value validation (can't go below bare hull)

Design Patterns Worth Reusing

Several patterns emerged that we'll apply to future calculator features:

1. Smart Increment Snapping

When users manually enter values, the next increment click should snap to a "round" number rather than just adding the step:

const roundUpToNearest250k = (value: number): number => {
  const increment = 250000;
  return Math.ceil(value / increment) * increment;
};

2. Format-Aware Paste Handling

Always intercept paste events for numeric fields that might receive formatted data from external sources:

onPaste={e => {
  e.preventDefault();
  const pastedText = e.clipboardData.getData('text');
  const cleaned = stripGameFormatting(pastedText);
  const num = parseFloat(cleaned);
  if (!isNaN(num)) {
    setValue(num);
    setDisplay(formatNumberWithCommas(num));
  }
}}

3. Inline Tooltips for Context

Instead of separate help sections, embed warning icons with tooltips directly next to fields that have "gotchas":

<span 
  title="⚠️ Default shown is bare hull mass. For accurate results: 
         Right-click your ship in-game → Show Info → Attributes tab → 
         Copy the mass value → Paste here."
  style={{ cursor: 'help', fontSize: 14, color: '#fbbf24' }}
>
  ⚠️
</span>

Performance Considerations

All calculations happen client-side in real time. With the formulas being simple arithmetic, there's no performance concern even with aggressive reactivity:

const singleJumpRange = useMemo(() => {
  if (!selectedShip || currentTemp >= MAX_TEMP || currentMass < selectedShip.mass) {
    return null;
  }
  return calculateSingleJumpRange(selectedShip, currentTemp, currentMass);
}, [selectedShip, currentTemp, currentMass]);

We use useMemo to avoid recalculating on unrelated state changes, but even without memoization, the calculations complete in microseconds.

What's Next

Future enhancements we're considering:

• Fuel consumption calculator: Given a route, how much fuel will you need?
• Heat dissipation timer: How long to cool down from 140° to 50°?
• Optimal fuel quality recommendations: Given trip distance and budget, which fuel type?
• Integration with route planner: Auto-calculate if a plotted route is achievable with current fuel

Try It Yourself

Jump Calculators are live in the Reachability panel. Select your ship, enter current stats, and see your range instantly. The calculator syncs with our Scout Optimizer and pathfinding tools to help you plan fuel-efficient routes.

Try Jump Calculators on EF-Map →

Key Takeaways for Developers

1. User testing reveals non-obvious pain points: We didn't anticipate how confusing bare hull vs fitted mass would be
2. Input fields deserve as much attention as algorithms: The formula was right on the first try; the UX took 4 iterations
3. Format impedance is real: Users will copy/paste from anywhere—handle it gracefully
4. Progressive disclosure works: Tooltips reveal help without cluttering the interface
5. Small polish adds up: Comma formatting, smart increments, paste handling—each is 10 minutes of work but transforms usability

Related Posts

• Scout Optimizer: Solving the Traveling Salesman Problem in Space - How we calculate efficient routes that the Jump Calculators help you validate for fuel feasibility
• A* vs Dijkstra: Choosing the Right Pathfinding Algorithm - Understanding the routing algorithms that benefit from accurate jump range calculations
• User Overlay: Real-Time In-Game Navigation HUD - See your calculated jump ranges directly in-game with our DirectX overlay
• Web Workers: Keeping the UI Responsive - How we keep complex calculations from blocking the interface

---

EF-Map is an open-source interactive map for EVE Frontier. Calculate your jump ranges at ef-map.com or explore the source code on GitHub.