Travel Calculations

rinku · 2025-12-16T02:50:09+0000

I'd also suggest the idea that if you ARE going to boost to jump point then effectively do turnaround in the destination system, it becomes a lot more important to have an accurate jump than usual. Variations in emergence point normally don't matter, but if you emerge with a significant relative vector it may do.

In fact you could go with the ideal vector to enter jump with isn't "as fast as possible" but "synched with the destination world", so that on arrival - even if you overshoot - your're in the same orbit as the target all you need to do is reorient and do a normal turnover journey. If you come in hot and miss, you'll have to correct all that burn and THEN do a normal trip.

MarcusIII · 2025-12-16T02:51:54+0000

I keep a few handy calculators in html form in a folder for when a player wants to do X.

Here's one for final speed anyone can save as an html file and run

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Speed Calculator</title>
<style>
body { font-family: sans-serif; padding: 20px; }
.form-group { margin-bottom: 10px; }
label { display: block; margin-bottom: 5px; }
input { padding: 5px; }
button { padding: 10px 15px; margin-top: 10px; }
#result { margin-top: 20px; font-weight: bold; color: green; }
</style>
</head>
<body>
<h1>Calculate Final Speed</h1>

<div class="form-group">
<label for="initialVelocity">Initial Velocity (m/s):</label>
<input type="number" id="initialVelocity" placeholder="Enter initial velocity" required>
</div>
<div class="form-group">
<label for="acceleration">Acceleration (m/s²):</label>
<input type="number" id="acceleration" placeholder="Enter acceleration" required>
</div>
<div class="form-group">
<label for="time">Time (s):</label>
<input type="number" id="time" placeholder="Enter time" required>
</div>

<button onclick="calculateSpeed()">Calculate</button>

<p>Final Speed: <span id="result">0 m/s</span></p>

<script>
function calculateSpeed() {
// Get values from the input fields
const initialVelocity = parseFloat(document.getElementById('initialVelocity').value);
const acceleration = parseFloat(document.getElementById('acceleration').value);
const time = parseFloat(document.getElementById('time').value);

// Check if inputs are valid numbers
if (isNaN(initialVelocity) || isNaN(acceleration) || isNaN(time)) {
document.getElementById('result').textContent = "Invalid input. Please enter numbers.";
document.getElementById('result').style.color = "red";
return;
}

// Calculate the final velocity using the formula: vf = vi + at
const finalVelocity = initialVelocity + (acceleration * time);

// Display the result
document.getElementById('result').textContent = finalVelocity.toFixed(2) + " m/s";
document.getElementById('result').style.color = "green";
}
</script>
</body>
</html>

rinku · 2025-12-16T03:05:09+0000

Back of the envelope calculations are almost always enough. It's sufficent to answer the simple situational questions.

e.g:

Will they intercept close enough to shoot? That's mostly a function of thrust difference - if "no" you can ignore them if you don't want a fight.

How long to destination when they do get close enough? Then express it in combat rounds. If that's more than the fight is going to take, it's mostly irrelevant. In particular, a ship that gets jumped close to jump in point doesn't much care where the destination is - they won't be getting there in time.

How quickly can help arrive? This only matters if they get there before the fight is over. Often they'll just be a salvage team and exactly when they arrive isn't important.

MarcusIII · 2025-12-16T03:08:00+0000

rinku said:
Back of the envelope calculations are almost always enough.

many players aren't good at that. Especially if they are under 50 years old.

rinku · 2025-12-16T04:18:53+0000

Even better. Just make it up, it's likely to still be good enough.

"The pirate overhauls you and starts firing"

"Damn, where's the space patrol?"

(Rolls)
"Fortunately they weren't too far away. They'll arrive at very long range in an hour - twelve turns."

"And how far to the station?"

"More than two hours. They won't be any help and it'll all be over before you get there, one way or another."

"Okay. Guess we'd better buckle in and try to survive until the cavalry get here..."

Literally the only thing that's needed to check in the above exchange is time to the station (so that you don't say two hours if 100D to world is one hour...), and if the attackers have a thrust advantage. Everything else is at Referee discretion - at what point of the trip the pirates showed up, how far away the patrol is.

MonsterX · 2025-12-16T07:58:43+0000

rinku said:
I'd also suggest the idea that if you ARE going to boost to jump point then effectively do turnaround in the destination system, it becomes a lot more important to have an accurate jump than usual. Variations in emergence point normally don't matter, but if you emerge with a significant relative vector it may do.

In fact you could go with the ideal vector to enter jump with isn't "as fast as possible" but "synched with the destination world", so that on arrival - even if you overshoot - your're in the same orbit as the target all you need to do is reorient and do a normal turnover journey. If you come in hot and miss, you'll have to correct all that burn and THEN do a normal trip.

It definitely makes sense to consider how the ships' jump entry vector will position it in the destination system.

However, in most cases the ships' own vector will only be one of three vectors to consider, and in most cases not the largest: the relative vectors of the destination star and departure star (these can be substantial), and the orbital velocity of the destination planet.

If the departure world is small and outside of any large object jump shadows, the accumulated vector from leaving it will be small and insignificant. In the other end, if you have a departure point inside a large star's jump shadow, you could accumulate a very big vector if you don't decelerate to jump. Which might or might not be a problem.

All this is why when I referee these things, it is usually just random, influence by the astrogation roll - i.e. it takes you 2d6 hours, or 1d6 days if it was bad astrogation. If there is an adventure reason to put the PCs somewhere - then the jump can require a particular vector because of "relative stellar velocities".

MarcusIII · 2025-12-16T13:48:49+0000

MonsterX said:
However, in most cases the ships' own vector will only be one of three vectors to consider, and in most cases not the largest: the relative vectors of the destination star and departure star (these can be substantial), and the orbital velocity of the destination planet.

IMTU I simplified all this. And eliminated some other problems long plaguing Trav. When a ship enters J-space it looses all inertia from this universe frame of reference. When reentering this space it has the vector (direction and velocity) of the mass within 1 yl. So when you jump into a system the ship is almost stationary with the star.

rinku · 2025-12-17T00:10:45+0000

MonsterX said:
It definitely makes sense to consider how the ships' jump entry vector will position it in the destination system.

However, in most cases the ships' own vector will only be one of three vectors to consider, and in most cases not the largest: the relative vectors of the destination star and departure star (these can be substantial), and the orbital velocity of the destination planet.

Actually in most cases the ship WILL be the thing with the biggest potential factor.

Most star systems are in similar galactic orbits to their neigbours. The relative velocites between them are usually on the order of tens to hundreds of kps. That's trivial to acheive with a 1G constant thrust drive ( adding100 kps takes less than 3 hours of thust).

Earth orbits at about 30 kps. Even jumping from a world at that orbital speed to one diametrically opposed is only a difference of 60kps... again a matter of hours of thrust. Very fast orbiting worlds by definition will be close to their primary, so the star's Jump shadow will prevent direct jumps anyway.

Most 100D transits require hours of thust anyway, so it should be mostly a matter of using that to synch up with the destination world, so that the ship emerges not just as close to 100D as possible, but already in a matching solar orbit with it. Clever lining up of the emergence point may also help, then there's hours of transit thrust to arrive that can be used to correct it all.

TLDR - in almost all cases, not worth calculating. Use it if plot requires (jumping to a rogue planet for example).

Travel Calculations

rinku

Emperor Mongoose

MarcusIII

Cosmic Mongoose

rinku

Emperor Mongoose

MarcusIII

Cosmic Mongoose

rinku

Emperor Mongoose

MonsterX

Emperor Mongoose

MarcusIII

Cosmic Mongoose

rinku

Emperor Mongoose

Similar threads