Planetary Relative Speeds With Regard to Jump

[jawillroy]

I recall there was some good discussion of this in a thread which I can't find at all.

Someone had pointed out that because
A) stars move in relation to each other and
B) planet certainly move as well,
therefore C), a ship with no vector relative to planet Y jumping into the vicinity of planet Z will arrive with a vector equal to the relative speed of those two planets in relation to one another.

On a day to day basis, this is not really something that PCs and Referees really need to be worrying their little heads about. But from time to time, it might be relevant. SO:

QUICK & DIRTY STELLAR RELATIVE SPEEDS:

(Gentlemen, please check my numbers and assumptions)

Thought about this a bit, and did some googling. Near as I can tell, stars move anywhere from a few KPS to 500+kps; planets in our system move from a few kps to somewhere near 50.

Now, taking this to Book 2 combat speeds, where each turn is 1000 seconds and a vector produced over a turn's worth of 1G acceleration is 10,000kilometers long (a ship traveling on such a vector is then moving 10kps.)

The really fast stars seem to be in the very core of the galaxy; slow ones are in globular clusters. So on average, they ought to be between, on the low side. Right?

for system Y, (6D6)*10 speed in kps. (60-360kps.)
Roll D6; make Y's speed a negative number if 1-3
for system Z, (6D6)*10 speed in kps. (60-360kps.)
Roll D6; make Z's speed a negative number if 1-3
Add the speeds of systems Y and Z; the resulting number is the relative speed of the two systems. It will vary from This should be recorded, as it will not change over the course of the game.

For a given jump, do the same process with 1D6, and add that result to the stellar relative speed to take planetary movement into account.

So say that system Y has a speed of 300 (moving away from Z at 300kps)
and system Z has a speed of -250 (moving towards from Y at 250kps)
they'll have a relative speed of 50kps.
Figure planetary speeds for y and z at 30 and 50 kps; add that for a total of 130kps.

A free trader jumping from one planet to the other from a relative standstill will arrive moving at 130kps, or in book 2 game terms, will have a vector 130,000km per turn. It will take that free trader about 13 turns to decelerate and match speeds with the planet in order to achieve orbit.

On the other hand, the free trader might have decided instead to match speeds with her destination at launch, and spent 13 turns accelerating prior to jump. A scout could do this in half the time, either way.

This would have interesting tactical repercussions, if a fleet's navigator chose to come out of jump moving towards the target at half a light-second per turn. No?

It also means that ships coming in and out of system can be expected to be moving at absolutely hellacious speed about half the time.

 

[Gadrin]

GURPS Traveller deals with this on p120 using a Standing Jump and Running Jump.

No matter the game system, I'd just assume the navigator covers all of this when he plots his jump course.


>

 

[jawillroy]

GURPS Traveller deals with this on p120 using a Standing Jump and Running Jump.

Really! I've never looked at GURPS Traveller, so I'd no idea. Fascinating, Captain.
Offhand, do you remember what the speed-spread was like?

No matter the game system, I'd just assume the navigator covers all of this when he plots his jump course.

Oh, me too, and I'd generally have it ignored as routine. IMTU the preferred standard commercial procedure would be for ships to run for jump: I suspect most starports would prefer to not have ships screaming in hot.

I suspect that an observer of a jump-run, with a decent computer, a nav program, and the requisite skill, would be able to make a very reasonable guess at the jumping ship's target system based on this.

 

[Icosahedron]

For the record, I believe I was the one who mentioned the problems with stellar motion, and IIRC it was the Piracy Redux thread.

My take was and is to forget the whole thing as an irrelevant can of worms.

 

[jawillroy]

Can of worms? Probably, if you take it too seriously and try to figure out the vector of every single system for consistency's sake, and have it all hold together.

Like I said before, it's certainly not something one would want to have to figure out often.

 

[Kyle Aaron]

It's irrelevant with standard Traveller technology.

If you have technology which we know or at least have reasonable hopes will work in the real world, then stellar and planetary relative velocities affects travel time.

IMTU, it's modern-day plus thirty years, the only change in technology being the invention of a warp drive. So ships have to deal with their relative velocities coming out of warp. They never have enough fuel to do this, so they have to do it with planetary passes to get gravity assists or slow-downs. Sometimes they have to make multiple passes - pass, gain/lose momentum, warp back, pass again, etc.

So it increases travel time, and makes some systems which are close in parsecs actually quite far in travel time. For example if A and B are 1 parsec apart but have 100km/sec relative velocity, it'll take longer for a ship to make planetfall between them than with A and C 6 parsecs apart but relative velocity zero.

Sometimes interstellar routes which are not in a straight line, or which even loop and backtrack, will turn out to be quicker than straight line routes. This increases the "age of sail" feeling.

It also means some systems will be difficult to "surprise attack", as the fleet is seen zipping past some gas giant over 30 days or so... But other systems will be more vulnerable.

Of course this only applies with today's technology plus warp; if you can zip along at 2G for weeks then relative stellar velocities are, as others have said, essentially meaningless and cosmetic only.

 

[jawillroy]

I'm not really sure why it's irrelevant. I can see why it wouldn't be worthwhile to figure in detail, often. And a lot of the benefit is cosmetic, true, but part of that is what goes into the storytelling element of the game, isn't it?

 

[Kyle Aaron]

It's irrelevant because at the accelerations and with the ranges achievable by OTU spacecraft, making up for relative velocity will be smaller in effect than the normal inaccuracy of a jump.

It's indistinguishable in effect from much larger effects. So that it adds complication to the game without adding any in-game effect. It's like having (say) ten types of armour which have the same in-game rating and effect. What for?

For realism? Well... two-dimensional interstellar space... hmmm.

 

[jawillroy]

Fair enough, in terms of play. In terms of thinking about how stuff might work, I still think it's nifty.

 

[boomslang]

On a day to day basis, this is not really something that PCs and Referees really need to be worrying their little heads about. But from time to time, it might be relevant.

Actually, it is a gigantic something that PCs & Refs need to deal with every single time they jump, since the absurdity of decelerating to "zero velocity" (relative to what, exactly, Starkiller?) or not can dramatically effect travel times, escaping one's pursuers, and so on.

So, I'm all in favor of an abstract mechanism to address it.

And I think that this may be the thread that you were looking for...

 

[jawillroy]

Yay! That one up there work for you, Boomslang?

Yeah, I think that was the discussion.

I think it's an issue that every navigator and every decent pilot would consider every jump. I think that in roleplaying terms, accounting for the movement of the target relative to the departure point is going to be included in whatever S.O.P. the crew has.

IMTU, the commercially available jumpcharts all require a specific, assigned run to jump and a near-100d, near-stationary exit. So that's what'll happen most of the time, nobody thinks twice about it.

An emergency jump done under-vector or out of position... Something like that, I'd pay attention to and roll numbers for. "You've got blips on scan; mass and speed suggesting they're a pair of the Marquis' Jaeger corvettes, closing fast." "Jump's been programmed? Hit it. Now." "'Puter's howling something about Under Velocity For Assigned Jum..." "HIT IT." **** "Navigator, make note of how much we were off by. I want to know how fast I'm going to have to decel next week when we break out. I'm having a drink."

 

[boomslang]

Yay! That one up there work for you, Boomslang?

It's straightforward enough to be plugged into a calculator for quick use...

IMTU, the commercially available jumpcharts all require a specific, assigned run to jump and a near-100d, near-stationary exit. So that's what'll happen most of the time, nobody thinks twice about it.

See, this is the problem: stationary with respect to what? (Dr. Einstein, call your office. And see the older thread I linked to previously.)

"Stationary" only described a relationship between objects; what two do you have in mind? The starship and..?

...out of position...

Ah, but what "position" are you talking about? The only technical nav requirement is to be outside the "jump shadow" (i.e., beyond the 100-diameter limit) of everything nearby; relative vector and relative position are immaterial beyond that one consideration... if you jump from a position that's stationary with respect to the world you're leaving, you're pretty much guaranteed a long, time-and-fuel-consuming burn to "catch up with" your destination world.

Once more, with feeling: There is no "stationary" reference frame in space except with respect to another, specific object. I promise. You always have an inertial reference frame, but that's not the same thing...

The flip side is that we could assume a Jump mechanic that has you leave stationary with respect to your departure world and arrive stationary with respect to your destination world, but that is a double-edged sword: on the one hand, it means that misjumps will tend to precipitate out standing at the 100-diameter limit of some large body (just hope it's not a neutron star or whatever) which helps avoid marooning, but on the other hand, without some massive object to anchor the exit point, it's going to be nearly impossible to deliberately jump into empty space (which is part of canon: The Battle of Two Suns, at alia)...

 

[jawillroy]

It's straightforward enough to be plugged into a calculator for quick use...

Thanky!

See, this is the problem: stationary with respect to what? (Dr. Einstein, call your office. And see the older thread I linked to previously.)

"Stationary" only described a relationship between objects; what two do you have in mind? The starship and..?

We're not disagreeing, you're quibbling about my apparent inability to write with precision. ^_- In this case, it's near stationary to the destination world.

Ah, but what "position" are you talking about?

If running for jump is necessary in order to match the vector of the system you're jumping into, and you're buying a pre-programmed jump chart that assumes a specific run for jump, then if you jump too late or too early, the calculations for the jump will be wrong - at least in terms of coming out of jump close to the speed of the target world. [/QUOTE]

 

[boomslang]

If running for jump is necessary in order to match the vector of the system you're jumping into, and you're buying a pre-programmed jump chart that assumes a specific run for jump, then if you jump too late or too early, the calculations for the jump will be wrong - at least in terms of coming out of jump close to the speed of the target world.

True enough.

Not having the luxury of being "stationary" does tend to be more of an issue when departing than when arriving (pursuit by corsairs/enforcers/victims/creditors, et cetera). The major headache with plotting a "destination" arises from the randomness of the travel time; everything in the universe moves during the time that traditionally constitutes the "exit window".

Of necessity, I've gotten into the habit of ruling that although a Jump can take a variable amount of time (more or less as written in Old School HG2, not as per the SOM and that ilk); upon plotting a particular Jump, the Jump duration for that Jump plot is fixed for those point-to-point calculations and as a result can be known ahead of time (this permits fleets to Jump together, among other things).

Thus, knowing the expected position of all the relevant celestial bodies at your scheduled arrival time, you can usually angle the vector you'll be arriving with to put you on an efficient (and safe) intercept course with your destination upon breakout.

And seriously, who uses Jump Tapes [sic] anymore? I bought a big-enough computer so I can run Generate pretty much continuously after liftoff, to make sure I always have an up-to-date plot ready to go should trouble arise and flightplans change...

 

[robject]

Of necessity, I've gotten into the habit of ruling that although a Jump can take a variable amount of time (more or less as written in Old School HG2, not as per the SOM and that ilk); upon plotting a particular Jump, the Jump duration for that Jump plot is fixed for those point-to-point calculations and as a result can be known ahead of time (this permits fleets to Jump together, among other things).

Thus, knowing the expected position of all the relevant celestial bodies at your scheduled arrival time, you can usually angle the vector you'll be arriving with to put you on an efficient (and safe) intercept course with your destination upon breakout.

And seriously, who uses Jump Tapes [sic] anymore? [...]

That's a pretty good rule. And hey, perhaps Jump Tapes "merely" contain the parametric representations of the source and target; that plus the ship's clock could dynamically generate the actual jump instruction set and insertion/cruise/detach routines.

 

[jawillroy]

And seriously, who uses Jump Tapes [sic] anymore?

IMTU, what they call Jump Tapes aren't tape anymore, they're sticks... but they call them tapes, in the same way that sometimes cd's are still referred to as albums. (do YOU know why a cd or lp was called an album? You know what Traveller is, so I'm sure you're antiquarian enough to recognize an lp...)

Actually, the term used to refer to maps and charts, well into the 17th century, was tabula. Which resulted from Ptolemy's having not recorded physical maps, but tables indicating the relative distance of various cities in the known world. Wasn't until the 15th century that you start seeing maps based on Ptolemy's tables... but they still called 'em tables.

So my jumpcharts are called tapes, even though they haven't been tapes for centuries. As much as I would love making PCs deal with great godawful spools of two-inch tape. "I can't help you load up the target program: I threw out my back the last time."