Jump Space and Conservation of Mass and Energy

JTAS 3 pg12 states "The laws of conservation of mass and energy continue to operate on ships that have jumped; when a ship exits jump space it retains the speed and direction that it had when it jumped."

I think this is a bad thing and that the laws of conservation of mass and energy don't need to apply through Jump Space.

1) It leads to a lot of undesirable in-game possibilities
The rules as written make sense to me. See the attached drawing for my interpretation.

You are jumping from star system 1 to star system 2, relatively close by (on a galactic scale). Say the center of mass of star 1 and its planets is moving relative to star system 2 center of mass at 20 km/s in the x-direction. That's pretty typical of the relative velocity between stars in Charted Space.
Planet A orbits star 1 and is currently moving at 20 km/s along the y-direction relative to star 1. That's pretty typical for a planet in an orbit similar to Terra around Sol.
Planet B orbits star 2 and is currently moving at 15 km/s along the negative y-direction relative to star 2.

If you want to jump to an orbit around Planet B, you want to leave Planet A and enter jumpspace with a velocity vector that will cancel out the relative motion and give you a velocity vector that closely matches that of your destination, Planet B. In this case, you'd want to leave Planet A at around 40 km/s in the correct direction (vjump on the diagram). That's a little over an hour acceleration at 1 G. If the Astrogator's doing their job and the jump goes well, you should exit jumpspace at the right speed to enter an orbit around B, or close enough to make small adjustments when you get there.
 

Attachments

  • jump velocity.JPG
    jump velocity.JPG
    28.1 KB · Views: 1
The way I work it in my game is that the jump calculations can finagle the ship's velocity a bit. Like a car merging onto an intersecting freeway. Place your desired exit point so that the new system relative velocity either cancels out your momentum, reduces it to a manageable level, or has you pointed at your destination at a vector that requires you to flip and start your deceleration burn after a period sufficient to scan and get your bearings.
Momentum is conserved, just be creative on where and how you merge with the new systems' flow of traffic.
For me it is a holdover from that old Traveller PC game. I'd look at the map, see where I needed to be facing and burn so that after the jump, I'm going full speed towards the planet.

Most times, it doesn't matter, though, so we just use the chart to see how long it takes to get to 100D and use the same on exit... and then more often than not they don't need that level of detail, and assume one day coming in and one day leaving, to factor in travel, customs, docking, bureaucratic delays... gives them something to roll dice at if they want to get through it all faster.
 
Last edited:
Emerging moving at same vector of the object whose 100D limited cause the emergence solves a lot of problems, because it answers the question: immobile relative to what frame of reference? Any other answer leads to difficult calculations and sometimes to crazy vectors being imparted to ships emerging from jump, if you try to tackle the problem with any consistency.

However, it doesn't really solve the problem completely: merchants will want to emerge at 100D limits. Other ships may have other priorities. Naval attack forces will want to emerge based on their battle plans and operational needs, which will often put them elsewhere. Research ships will want to emerge where they need to be to do the research, mining vessels near the attractive asteroids etc. They'll want to emerge with vectors that suit their needs and if a 100D rule like this is implemented, it gives them all certain operational limits and opportunities. A systems objects' 100D limits and the knowledge of those immediately becomes important - defenders will need to find all the objects and put monitoring stations on them. If attackers secretly find an object, they can muster their fleet there in secret. All systems will have the 100D around the primary as a huge area where they can expect enemy fleets to emerge. The point is, if you implement this consistently, it will shape the behavior and practices of starship operation a lot.

And what if they want to emerge elsewhere? Can they? if so , what is their vector on emergence?
 
You could Zero velocity out to the star's vector anywhere in the system not at 100D of a planet... (but at 101D from the planet, is it still the planet?... the math part of my brain says the Hill Sphere is the limit: for Earth-Sol, that's very roughly 120D in this case) The Earth moves at 30 kps in it's orbit so there would be velocity 'shear' somewhere out there. But as someone pointed out at full gee acceleration 30kps isn't a ton of delta-v - less than an hour's worth, so it could be fudged on a voyage that would take about 6.8 hours under 'Earth-Zeroed' conditions from 1.5 million km out.

I do think the Referee should at least decide how it works in their universe and then stick to it. Inconsistence and all that just causes grief.
 
ANSWER: It IS conserved relative to all of them. Speed (or more properly velocity as long as our mass is not changing, because it is momentum that is conserved), is undefined EXCEPT as it is in regard to a specified reference frame/point-of-reference. Then you can compare it to different reference frames.

The other references frames you mentioned above may be of interest academically, but are irrelevant the issue of Jump, any more than I am concerned about my speed relative to galactic expansion or the Earth's rotation or its Revolution about the Sun when I drive to the grocery store. The only reference frame information that matters to me is my position in my own frame, the location of the store relative to my position in my frame, my velocity relative to the store, and the relative velocities of any intervening objects and/or other cars relative to my reference frame as I make my way to the store. All of the other extra-planetary relative velocities of planetary and stellar bodies and galaxies may be interesting, but they have no relevance to the motion of the cars and store, regardless of the actual magnitude of the velocities involved.

The real issue in-game (presuming you wish to include this) is simply to get a feel for a range of real-world believable values for stellar proper motion and planetary orbital velocities at given orbital ranges and use a random roll for the difference between the departure and destination velocities. The values by and large aren't as large as you might think they would be, and with Traveller-style M-Drives with effectively unlimited Delta-V and relatively large continuous accelerations, they can be corrected for in very reasonable amounts of travel time (but occasionally long enough to be a nuisance for some time-sensitive plot reason).

Anything galactic/extra-galactic is likely to far too small on the local level between the two stars to matter for Jump-drive operational ranges.

Exactly this.

WRT the practicalities. Pilots should not simply point their ship away for a planet and get to the 100D point asap. This is unlikely to be the most time efficient route. Instead, they should consult with the Astrogator to determine the optimal entry and exit points.

The first part of the Astrogation calculation would be to determine the relative velocity between the ship and the target destination (at the planned time of exit). The pilot and the astrogator can then work together to determine the optimal entry and exit jump points and the two m-drive courses to and from these jump points - minimizing the total time required.

However, as was pointed out - M-Drives make this issue easy. Even if the jump is bad and the dV is large - a Traveller ship can plot a course to the desired orbit. The only question is whether this takes a few hours/days/weeks. Traveller Companion p150.
 
.... wow... or you could just say speed/velocity is zeroed out by jump (relative to the nearest planetary/stellar body) when they arrive like I originally posted.

Then your tables in the core book actually still apply, because they are all about burn-flip-burn from zero.
Then you have a better chance of a ship realistically encountering you at the 100d limit, instead of whizzing by for less than a microsecond.
Then you don't have to work out a bunch of math to figure out how to slow the ship for landing on a planet that has a different diameter/100d mask at the destination.
Then you don't have to drive your players up the wall as they are probably not physics or math undergrads looking for more homework.

but most importantly... you don't have to figure out all the crazy real world physics that folk are trying to apply to completely fictional "jump navigation" as stated in most of the posts of this thread. lol

Thanks guys! I have my plan! :)
 
.... wow... or you could just say speed/velocity is zeroed out by jump (relative to the nearest planetary/stellar body) when they arrive like I originally posted.

Then your tables in the core book actually still apply, because they are all about burn-flip-burn from zero.
Then you have a better chance of a ship realistically encountering you at the 100d limit, instead of whizzing by for less than a microsecond.
Then you don't have to work out a bunch of math to figure out how to slow the ship for landing on a planet that has a different diameter/100d mask at the destination.
Then you don't have to drive your players up the wall as they are probably not physics or math undergrads looking for more homework.

but most importantly... you don't have to figure out all the crazy real world physics that folk are trying to apply to completely fictional "jump navigation" as stated in most of the posts of this thread. lol

Thanks guys! I have my plan! :)

Of course - do it your way. It is YTU at the end of the day.

FYI: I and I imagine 99.99+% of Referees do not run physics engines to calculate in game ship courses. You would have to generate a model for each system - an insane amount of work, to bored your players to tears.

Rather, all the activity I described is incorporated in "Make your EDU + Astrogation roll.". At most I would briefly narrate it. Wrt being intercepted, it is no difference. If you are heading to dock with a highport - the spatial location and velocity window on jump exit is just as narrow...
 
Of course - do it your way. It is YTU at the end of the day.

FYI: I and I imagine 99.99+% of Referees do not run physics engines to calculate in game ship courses. You would have to generate a model for each system - an insane amount of work, to bored your players to tears.

Rather, all the activity I described is incorporated in "Make your EDU + Astrogation roll.". At most I would briefly narrate it. Wrt being intercepted, it is no difference. If you are heading to dock with a highport - the spatial location and velocity window on jump exit is just as narrow...
Yeah. My players, make their astrogation roll and jump. They arrive at zero velocity relative to the nearest "body". Anymore complicated than that and I will lose players.
 
Unless, of course, the detail is needed for an adventure opportunity...

I always ask what the players want their characters to be doing during the week in jump and roll a couple of dice, that way if I want a scenario event to take place it can catch them a bit off-guard.

There is nothing worse than routinely narrating "ok you arrive at your destination world" because when there is something happen during the week onboard the ship it is obvious shenanigans are afoot.
 
Yeah. My players, make their astrogation roll and jump. They arrive at zero velocity relative to the nearest "body". Anymore complicated than that and I will lose players.

I am not sure what difference this makes to the players? I look at the effect level of their Astrogation roll and if it adds the the story I vary to transit time to the highport. It works raw or with this zero velocity house rule.
 
I am not sure what difference this makes to the players? I look at the effect level of their Astrogation roll and if it adds the the story I vary to transit time to the highport. It works raw or with this zero velocity house rule.
None of My players currently have gone beyond 6th grade, most of them only have a 4th grade education before they had to leave school to start working to support their families, so I try and keep the math and such to the absolute bare minimum. Gone are the days when most of My players were college grads.
 
Emerging moving at same vector of the object whose 100D limited cause the emergence solves a lot of problems, because it answers the question: immobile relative to what frame of reference? . . .

Actually, this makes for an interesting bit of potential "physics" for both a solution and game play.

So if you "aim" for the jumpline to intersect/overshoot the 100D limit of an object, you force-precipitate out of jump at the 100D limit and simultaneously transfer you momentum and kinetic energy to the "obstructing" body (i.e. your destination star or world) and come out of jump at rest-relative momentum. Consequence is you get a "rough ride" as being forced out of jump by the g-well is always a wrenching experience and can lead to problems (one of the reasons for jump-sickness and equipment failures, etc).

OTOH, if you "plot" a jump to terminate shy of the limit, you exit much more easily, but you need to account for relative momenta, etc. Perhaps a good pilot/astrogator can do some controlled relative momentum transfer in these circumstances as well, but that should be part of the rolls for successful jump (perhaps the closer to 100D, the more you can transfer reliably, but you run a greater risk of hitting the 100D "wall").

Also makes a misjup and it's reason more interesting.
 
but most importantly... you don't have to figure out all the crazy real world physics that folk are trying to apply to completely fictional "jump navigation" as stated in most of the posts of this thread. lol

Thanks guys! I have my plan! :)

One additional wrinkle that I take into account on the Astrogation calculation is attempting to sync time clocks to arrive closer to the ship's clock. Purely for roleplaying purposes.
 
All this supposed that you are jumping to a known system, say in the Imperium, where your astrogation database has all the information needed to know where the target planet will be.
If, on the other hand, you can only observe the system from where you are (say one parsec / hex away) then all you know is where the planets (approximately) are 3.5 years ago.
For a 6 hex jump you can see where things were 21 years ago.
This is assuming that the sensors are capable of detecting these planets - after all our TL7.5 sensors are detecting some already so a TL12 ship should be able to do better.
Alternatively, ship’s sensors cannot detect planets at that range and, if it is an unknown system, the players just have to state how far out from the star they arrive and drive the rest of the way.
Or is there a better option?
 
All this supposed that you are jumping to a known system, say in the Imperium, where your astrogation database has all the information needed to know where the target planet will be.
If, on the other hand, you can only observe the system from where you are (say one parsec / hex away) then all you know is where the planets (approximately) are 3.5 years ago.
For a 6 hex jump you can see where things were 21 years ago.
This is assuming that the sensors are capable of detecting these planets - after all our TL7.5 sensors are detecting some already so a TL12 ship should be able to do better.
Alternatively, ship’s sensors cannot detect planets at that range and, if it is an unknown system, the players just have to state how far out from the star they arrive and drive the rest of the way.
Or is there a better option?

If you can spot a gas giant, then you will know the plane of the ecliptic. Jump to about 150D wrt the star above that plane. Should be safe.
 
On the astronomic scale, three and a half years isn't an eon ago.

A good enough telescope will locate large gravity wells, and allow a transition, without the likelihood of surprises.
 
The original article by Miller oversimplified things as far as orbital mechanics go. He was concerned with the ship only, and not the complications related to two different star systems having different angular momentum, let alone the fact that jump travel is inherently straight-line based. Which makes for some interesting course plotting if you are attempting to line up on a planet form a parsec or more away - and that assumes your course will allow you to travel the distance along a straight line without running into an object that could pull you out of jump space. While space is vast, it's still a question of lining up all the stars, worlds, moons and larger objects between you and your destination and threading that needle. So it may not even be possible to make the entry you want due to the complications.

For me I've tried to not go down the rabbit hole of calculations for other planetary objects or kuiper belt rocks that may or may not also cause your ship to precipitate out of jump. Instead I treat it more simply. If one wants to be accurate about the emergence location in the other star system then one needs to come to an essentially halt relative to your departure system. That gives you zero velocity upon re-entry and from there you will take on the local angular velocity conditions - but you have a star drive and that will be easily overcome within seconds, so no muss no fuss.

For ships that are at speed when they jump, the higher your velocity the larger your margin of error upon emergence. As I see it, you are incentivized to come to a stop prior to jumping, however you aren't prohibited. Making a jump at speed and emerging 10 million KM off your planned arrival point is not a bad thing when running away. :)
 
I'll chime on the side zero-ing out a ship's velocity relative to the nearest gravity well as part of a jump in MTU, for a few reasons: 1) as mentioned above, it simplifies the math. 2) I don't want to have to deal with some psycho fictional terrorist group loading up a 100dton ship with as many engines and jump range as they can, calculating the correct relative vectors ( which you'd presumably have to do anyway for a normal jump. I'd imagine Astrogation charts would have known relative vectors of all systems known ) and then accelerating to something like .1 c, jumping to 100d of a planet, and smashing into it within a few seconds at a kinetic velocity like an order of magnitude higher than the asteroid that killed the dinosaurs. ( if I did my math correctly )

Now, there would be other ways to deal with #2.. maybe the more distorted newtonians physics become, the harder entering or leaving jump space becomes.. thus the greater chances of a misjump. That's why I picked .1 c. from some google searches, that's about when the old equations start to break down. ( I could be wrong on this, of course.. I'm no physicist. but whatever the value, it'd no doubt be Really Fast. ) But stilll, combined with just simplifying everything ( point #1 ), I find it somewhat compelling.

Anyway, that's what I'll do the next time I run Traveller. :)
 
Back
Top