Jump vector question

[kristof65]

Some of the threads here on travel - particularly the pirates ones - have me thinking about how I want to handle stellar system traffic control IMTU.

One of the questions that comes to mind is how jump vectors translate to real space travel. (Confused yet? I am.)

Take the following 2 situations:

1. Spaceship takes off from planet A in system A, travels out to the 100d limit, jumps to the 100d limit of planet B in system B and then travels to planet B.

2. Spaceship takes off from planet A in system A and travels via m-drive to planet C, also in system A.

In the second situation, the spaceship must leave planet A at a certain vector (or one of a few vectors) in order to make the most timely trip from A to C. Upon arriving at planet C, he'll be approaching via a very predictable vector.

So now apply that to jump space, and situation 1 - when the ship jumps at the 100d limit of planet A, it will have a very specific heading and speed. Does that heading and speed from it's departure of planet A matter at all for it's approach to planet B, or will it automatically come in at the correct vector needed to reach planet B, regardless of how it left planet A?

It makes sense to me to say that a ship retains it's same real space heading and speed that it had before jump upon returning from jump space. I beleive I've even read that somewhere within one of the rule sets, but can't find it now (I admit, I haven't looked very hard).

The only reason this matters to me is that I'm planning on posting some of my thoughts regarding in-system traffic control here for comment/ critique, and this makes a big difference to how things can be handled.

 

[captainjack23]

IMTU I have jump preserve vector and course; I think its mentioned in Marcs jump article in JTAS.

I also assume that part of the calculation is to zero out the velocities of the jump point system and the destination system with respect to some arbitrary reference. Retaining a high vector gets one away from the jump point quickly -MTU does have a jump flash- but also gives one less time to react to unexpected issues (like the jump uncertainty). merchants tend to try to jump as close to a 100d limit as possible, so they generally shoot for zero vector. Military ships have high exit vectors to prevent being zapped by lightspeed weapons.

Most class C+ ports have defined entry zones at the 100d, based on average traffic, and ship type, which obviously vary as time goes on; but all such info is easily available at nearby ports or from a central registry.

More to come if you want, gotta run !

 

[EDG]

In the second situation, the spaceship must leave planet A at a certain vector (or one of a few vectors) in order to make the most timely trip from A to C. Upon arriving at planet C, he'll be approaching via a very predictable vector.

So now apply that to jump space, and situation 1 - when the ship jumps at the 100d limit of planet A, it will have a very specific heading and speed. Does that heading and speed from it's departure of planet A matter at all for it's approach to planet B, or will it automatically come in at the correct vector needed to reach planet B, regardless of how it left planet A?

I think this is how it's supposed to work: say that in one system a ship is pointing toward some suitably very distant reference object (say, the exact galactic centre) and travelling toward it at a speed of say 10 m/s (in some Mythical External Reference Frame (MERF), I guess). It enters jump with that vector, and when it exits it will still be pointing toward that reference object and travelling at that speed towards it.

I would guess that in most cases it'd be in a ship's best interest (if safety is more of a concern) to reduce its velocity in that Mythical External Reference Frame to zero. Then when it jumps back into realspace it can reorient itself toward its destination and accelerate toward it without having to worry about working off its existing velocity or changing vectors first.

(Presumably the "MERF" is something to do with jumpspace, or this all really wouldn't work at all. Though IIRC the point of Relativity is that there is no absolute external reference frame, which makes this all a bit weird).

Either way it's not relative - if the ship is pointing toward the star in its departure system, it won't necessarily be pointing to the star in its arrival system (in fact that'd only be possible if the systems are oriented exactly the same way, and if the ship didn't jump through the star's 100D limit because that would drop it out of jumpspace).

 

[GypsyComet]

As a side note, the long smooth curved tracks we see on NASA animations about missions are somewhat less likely in Traveller unless you are chasing a world close in to the star. Even a modest amount of sustainable thrust, and for this purpose even 1G is quite a lot, causes many in-system paths to become straight lines. Curves only become necessary if you have to avoid something along the line of travel. The star itself is the most obvious example of this.

The fuel-as-reaction-mass variant presented in High Guard will tend to cause more care in route planning, as a ship is going to spend a large part of an in-system trip simply coasting and will have a limited fuel budget at the end with which to reach dock, but even here the paths are going to be pretty straight.

 

[AndrewW]

As a side note, the long smooth curved tracks we see on NASA animations about missions are somewhat less likely in Traveller unless you are chasing a world close in to the star. Even a modest amount of sustainable thrust, and for this purpose even 1G is quite a lot, causes many in-system paths to become straight lines. Curves only become necessary if you have to avoid something along the line of travel. The star itself is the most obvious example of this.

Well, NASA missions can have rather curved trajectories in order to save fuel by using a gravity assist from other celestial bodies.

 

[GypsyComet]

As a side note, the long smooth curved tracks we see on NASA animations about missions are somewhat less likely in Traveller unless you are chasing a world close in to the star. Even a modest amount of sustainable thrust, and for this purpose even 1G is quite a lot, causes many in-system paths to become straight lines. Curves only become necessary if you have to avoid something along the line of travel. The star itself is the most obvious example of this.

Well, NASA missions can have rather curved trajectories in order to save fuel by using a gravity assist from other celestial bodies.

Including the eventual target. If you don't need to burn much fuel to peg a stable orbit around the final destination, so much the better.

 

[kristof65]

Either way it's not relative - if the ship is pointing toward the star in its departure system, it won't necessarily be pointing to the star in its arrival system (in fact that'd only be possible if the systems are oriented exactly the same way, and if the ship didn't jump through the star's 100D limit because that would drop it out of jumpspace).

If you said what I think you said...

Presumably then, the ship arriving would be on a real space heading towards their desired destination planet upon dropping out of jump.


Hmm - trying to get my head wrapped around the implications here. If one always tries to compute the shortest real space path between the two planets for the actual jump trip, then the departure and approach vectors will pretty much always be the same for every departure and arrival (well, changing slowly over time for planetary movement, of course).

However, since the extra few million miles really doesn't matter to the time spent in j-space, theoretically, you could fly away from planet A in real space in a direction opposite of your intended direction, and wind up on the "far side" of planet B in relation to planet A. Hrmmm...

But, that would technically be calculating a jump trajectory that led "through" the 100d limit of both departure and arrival planets. Which means you theoretically wouldn't want to chart any course that might lead you through any other body of gravity.

In theory, then, this should pretty much narrow down the departure/arrival lanes to a handful between any two worlds, shouldn't it? However, that could be dozens or even hundreds, when one takes into account the number of systems within 6 parsecs and the number of worlds in those systems that one might jump to, right?

Does a rough calculation of 1d6 traffic lanes per system with 6 hexes sound reasonable?

 

[EDG]

Either way it's not relative - if the ship is pointing toward the star in its departure system, it won't necessarily be pointing to the star in its arrival system (in fact that'd only be possible if the systems are oriented exactly the same way, and if the ship didn't jump through the star's 100D limit because that would drop it out of jumpspace).

If you said what I think you said...

Presumably then, the ship arriving would be on a real space heading towards their desired destination planet upon dropping out of jump.

Only if the destination planet is in the right place .

Here's a way to visualise it - take a counter with an arrow on it (or at least something with a "front" to it) and put it facing a certain direction on the table. Then quickly slide it over to the left or right a few inches without changing its orientation. Advanced readers ( ) can also move the counter slowly in one direction and then slide it rapidly to the left or right, and keep it moving in the same direction it was going before. That's what jump does.

Thing is, unless you have really accurate ephemerides for the destination system you can't really know in advance if the ship will actually have the right vector relative to what you want it to be oriented to when it arrives.

Forget the planets, stars, and other bodies in either system - the only thing that matters is the ship's orientation and speed relative to the "MERF" I mentioned earlier (again, presumably jumpspace or something related to it?). Whether it actually ends up pointing toward a planet or other body, or in the direction that you want to go in depends either on coincidence or on really good (possibly prescient) planning.

(and don't forget, stars move relative to eachother. What may be "stationary" relative to one star may be travelling at 300 mph relative to another).

 

[GypsyComet]

Does a rough calculation of 1d6 traffic lanes per system with 6 hexes sound reasonable?

If a system wants to push traffic into specific lanes that's up to it.

In theory (and assuming Jump Masking is being used) any vector out to the Jump horizon that doesn't put that horizon in front of the target system is acceptable. That is half the sphere under ideal circumstances.

Where you may get natural (if temporary) lanes is when the planet/port is on the far side of the star. Outgoing ships will be vectoring to get around the star, while incoming ships may be on several paths inbound, depending on whether they used the star's Jump horizon, some other handy planet's horizon, or simply popped into open space as a target.

This sort of information is the "hidden" level of information that Library data, navigational ephemera, and port news updates will have in them that most people (and all players) never see, but is assumed as part of the setting.

"Lanth is occluded by its primary until 1106-023. Lanth System Traffic Control asks that incoming ships from our port use the small gas giant Mu as their jump precipitation target until that time. Ephemera supplements are available through the Office of the Port Master."

 

[Woas]

Wait, in canon or OTU or official ruling.. or whatever, J Engines send a ship in a direction independent from where the M drives make the ship 'face'?

So a ship could be thrusting forwards to Woasulus Prime, with the thruster exhaust pointing to a target system and then jump 'backwards' to said target system?

In my head, I was picturing J drives more like warp drives on Star Trek, where they still had to propelled the ship 'forward' and required the ship to face/aim to the target.

 

[kristof65]

In theory (and assuming Jump Masking is being used) any vector out to the Jump horizon that doesn't put that horizon in front of the target system is acceptable. That is half the sphere under ideal circumstances.

Crud. I keep thinking inside the orbital plane of a star system.

Hmm - it's looking like it might be easier to talk about the headings and vectors that can't be used.

This poses an interesting issue for traffic control in planetary sytems - the only real control they have over traffic coming in/going out are really just bureaucratic measures.

 

[GypsyComet]

Crud. I keep thinking inside the orbital plane of a star system.

Hmm - it's looking like it might be easier to talk about the headings and vectors that can't be used.

This poses an interesting issue for traffic control in planetary sytems - the only real control they have over traffic coming in/going out are really just bureaucratic measures.

This will be most important in near the mainworld (or other subsidiary ports) and around gas giants with established fueling stations around them. Near the port the concerns become similar to modern airports: big fast-moving craft all heading for the same chunk of real estate. Once they are out of the atmosphere the areas to move in get very big, very fast.

If a gas giant has a dedicated orbital station or a floater like Bespin, certain refueling dip paths are going to be off-limits, assuming they let you do a wilderness dip in that gas giant at all.

The other "bureaucratic" control will revolve around military installations, and staying out of their zones of control.

These are all concerns that affect well-developed systems. To be honest, the vast majority of systems are simply not going to care.

 

[captainjack23]

In theory (and assuming Jump Masking is being used) any vector out to the Jump horizon that doesn't put that horizon in front of the target system is acceptable. That is half the sphere under ideal circumstances.

Crud. I keep thinking inside the orbital plane of a star system.

Hmm - it's looking like it might be easier to talk about the headings and vectors that can't be used.

This poses an interesting issue for traffic control in planetary sytems - the only real control they have over traffic coming in/going out are really just bureaucratic measures.

Yes, exactly...although in a high traffic system, predefining target areas for different time periods may in fact be very helpful to avoid collisions and or etc.

"Terra-Sol control requires incoming jumps to target area A6 for jumpspace insertion completed at 0600 hours reference for 1105-136 "

Recommended Vectors for this breakout area are [...] with maximum velocity limited to[...] for rendezvous with Phoenix Highport.

Unregulated traffic zones L2-L5 will be occluded by Luna for this date thru 2317 reference. "

(I just thought of this: Outgoing jumps would be the standard reference, I suspect - we know when they occur -breakout is randomized -but would at least have predictable statistical distributions that could be assigned to various jump times to even out traffic)

 

[captainjack23]

Wait, in canon or OTU or official ruling.. or whatever, J Engines send a ship in a direction independent from where the M drives make the ship 'face'?

So a ship could be thrusting forwards to Woasulus Prime, with the thruster exhaust pointing to a target system and then jump 'backwards' to said target system?

Depending on its status, the DGP material describes the situation somewhat like that. In fact, the ship's vector and "tumble" at insertion determines the course in jumpspace; it does not necessarily correspond to a realspace vector towards the intended target.

Basically, I think the CT version of the explanation is essentially that vector and velocity are retained throught jump, but are irrlevent in jumpspace; thus, they do not necc correspond to the "direction" of the breakout, one essentially teleports from A to B, with a weeks delay with whatever movement in whatever direction you had at teleport.

Me, I like the idea that the vector is retained at breakout, but randomized with regard to heading. This makes the nasty jump weapons much less effective. I also make a running jump a harder task. It seems to feel right, assuming that a jump point to exit point calculation can get stale (re jump tapes) over time -presumably the actual position that the jump begins from is somewhat important and changes depending on time -and accuracy helps -or at least fails to hinder.

 

[Gee4orce]

If you can track it down, the Megatraveller Starship Operator's manual had a bunch of diagrams and table and - gasp - formulae for calculating the optimum route between two orbits (so, for instance, two planets around the same star).

I seriously doubt if you'd ever want to really use them in a game though, unless you wanted to turn it into a physics lesson !

As for entering Jumpspace, you're going to have to somehow control the direction of the jump, so it makes sense for this to be 'hardcoded' to straight ahead in the direction the ship is pointing. Note, that this is obviously not the same thing as the direction the ship is travelling, so I envisage ships maneuvering onto a different orientation before hitting the big J switch. This could provide a vital clue to observers as to the direction of the jump however...

 

[ribby]

i think the promblem is how do gravity voids are assigned by the locol starbase
in your 2nd example gravity has no effect on the trip really unless u need to fly around the systems sun in that case good luck.
but inorder to jump safely a ship must find a gravity void
not all system will have orbits as organized as our and i am sure if a ship is about to leave it will be given by the starport information on certain voids available.
this would be a great job for a pirate spy to get but that a whole other story.
remember planets move and so do the gravity voids with them unless the ship fly completly outside of the system it will need to rely on sensors and info
imgine being chased by pirate in your freetrader and trying to find a gravity void in the middle of a system you have never visited before and dont have accurate info on

 

[Rikki Tikki Traveller]

This is strictly IMTU, but I tied Jump Emergence and Jump Masking.

I said that when a ship emerges from Jump Space, it emerges with ZERO velocity relative to the mass the it emerged near. If a ship emerges at the 100D limit, it emerges with zero relative velocity to the planet. If it emerges farther out, it might emerge at zero relative velocity to the star.

So, normal policy was to accelerate from a planet to the 100D limit (no turn and decellerate needed). Then the ship emerges from Jump Space with zero relative velocity to the planet and then accelerates into orbit around the planet.

MGT is very vague on how velocity and momentum are (or are not) conserved through jump space. Each Referee is free to interpret how ships behave in jump space as they want to and how it best works for their game.

 

[EDG]

MGT is very vague on how velocity and momentum are (or are not) conserved through jump space. Each Referee is free to interpret how ships behave in jump space as they want to and how it best works for their game.

I suspect that the ships keep the same vector when they exit jumpspace because of the laws of conservation of momentum. Much like how teleporters heat up or cool down if they move up or down because of conservation of energy (though I was never particularly convinced about how that was implemented). Though given the presence of other wacky tech in Traveller that ignores things like that (like reactionless drives), I wonder why Marc bothered to pay lip service to it in these particular cases.

 

[AKAramis]

If you can track it down, the Megatraveller Starship Operator's manual had a bunch of diagrams and table and - gasp - formulae for calculating the optimum route between two orbits (so, for instance, two planets around the same star).

I seriously doubt if you'd ever want to really use them in a game though, unless you wanted to turn it into a physics lesson !

As for entering Jumpspace, you're going to have to somehow control the direction of the jump, so it makes sense for this to be 'hardcoded' to straight ahead in the direction the ship is pointing. Note, that this is obviously not the same thing as the direction the ship is travelling, so I envisage ships maneuvering onto a different orientation before hitting the big J switch. This could provide a vital clue to observers as to the direction of the jump however...

I've used SSOM in play. It's not bad with a sci-calc to hand.

Anyway, EVERY in-system trip is curved due to movement through at least one gravity well.

 

[GypsyComet]

The teleporter thing probably came from whatever piece of fiction inspired the addition of teleportation to the game, and really, it helps both suppress and enhance different types of "stupid teleportation tricks".