• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.
  • We, the systems administration staff, apologize for this unexpected outage of the boards. We have resolved the root cause of the problem and there should be no further disruptions.

Jumping at velocity?

...but seriously I seem to recall a Q&A or some such where Marc Miller clarified that it was a random effect in the reality of the game. Ships really do drop out of jump with only a vague idea of where they are and enter jump with the same vagueness of when they'll get there. Though it is contrary to at least one bit of (semi-)canon lore, from SOM (and istr some elsewhere) about knowing you've misjumped when the countdown clock passes the anticipated time of jump precipitation, or you drop out before the anticipated time.
No contradiction. In a normal jump you will emerge somewhere between 151 and 185 hours after entering, most of the time a lot closer to the average than that (the last bit is assuming jump durations follow a bell curve). So when the clock edges into the 175-180 hours elapsed, tensions begin to mount, and when you pass 185 hours you know you're in trouble.


Hans
 
Not the way I recall it, contextually (if not specifically). My recollection is a definite implied precision in the one (or more) colour notes vs Marc Miller's definitive jump is random statement. I'll have to have a look again sometime...
 
Last edited:
Well the muttering around the jump window always focused on attack fleets and how they deal with the discrepancies of it. And there was always babbling about precision syncing of jumps, what if the fleet train etc arrives first, yada yada yada. Regular flights don't really much care about the window save for perhaps dramatic purposes, chasing someone through jump, "did you arrive before them or do they have a 30hr head start on you...", etc.
 
...but seriously I seem to recall a Q&A or some such where Marc Miller clarified that it was a random effect in the reality of the game. Ships really do drop out of jump with only a vague idea of where they are and enter jump with the same vagueness of when they'll get there. Though it is contrary to at least one bit of (semi-)canon lore, from SOM (and istr some elsewhere) about knowing you've misjumped when the countdown clock passes the anticipated time of jump precipitation, or you drop out before the anticipated time.
Was it MWM or was it a DGP Q&A in one of their magazines?

Too much of what we now call canon is seen through the misconceptions that the DGP designers had about the rules, compounded by those same errors being propagated then expanded on by GT authors.

I'm going to read through CT (every edition) and HG 1 & 2 too to see what they actually say rather than what we think they say.

And Marc's jumpspace article too of course :)
 
From MWM Jumpspace article:

"The duration of a jump is fixed at the instant that jump begins..."

"The exact time of emergence is usually predicted by the ship's computer"
 
From MWM Jumpspace article:

"The duration of a jump is fixed at the instant that jump begins..."

"The exact time of emergence is usually predicted by the ship's computer"
'Usually predicted' implies a certain uncertainty.

In any case, the duration of the jump is fixed when the jump begins. I interpret that to mean when the ship enters jumpspace, so at the time you're selecting your velocity and direction (which is prior to entering jump), you've no way of knowing how long the jump is going to take and thus no way of knowing exactly where along its orbit the world you're aiming for will be.


Hans
 
I read is under normal circumstances - i.e no misjump - it is known.

My contention is that the folks at DGP introduced their own interpretation when they wrote the SOM (note that they got jump fuel usage wrong as well) and that it isn't actually supported in CT rules.

So when your jump program or jump cassette generated the jump parameters the crew knows how long the jump will take the instant the jump begins.
 
Yep - that is how I read it too.

The variable time part - is not unknown in-game, rather a mechanic for making jumps take differing amount of times at any given moment and position. Which, obviously, cannot both be identical for different ships - either position or time is different at the time of jump.

IIRC, CT had a time range, but originally, no explicit dice mechanic. From the Marc article quoted above (don't have myself) - in-game the expected jump time is known as part of the jump plot.

IMTU it is dependent on the 3D distance from a 'jump plane' by both departure and arrival systems and not random (except by moments - fleets are not synchronized to the minute for the reason mentioned above, though skill helps).
 
If you only know it the "instant" that you enter jump space, then you essentially DON'T know it before you enter jump space. Which means that BEFORE you enter jump space, you can't predict your exact arrival time or destination, so you can not ACT on that knowledge. You have to act as if you will arrive within a given window.

Once you do enter jump you now know all of those details, but there's nothing you can do about it. Simply, as was mentioned earlier, you know precisely when you will be out of jump space and if you leave jump before or after that time, you'd had some kind of misjump (the ramifications of which would be the subject of another thread entirely).

Basically you can imagine the navigator plotting everything within the known tolerances, but after they get everything set up and enter jump the navigator can say "Got lucky this run boys, we're going to be arriving a 10 hours early this time."

I think it would be an interesting argument that higher TL jump drives are perhaps higher precision jump drives, and thus narrow the arrival window, or that military jump drives are higher precision (and twice the cost) in order narrow the jump window. Or navigator skill can affect the size of the window. Something like that would all be interesting. Most of the time, folks simply don't care. It's just part of the trip like a tail or head wind.
 
they wrote the SOM (note that they got jump fuel usage wrong as well) and that it isn't actually supported in CT rules.

Not "got wrong" but "intentionally changed". In the very same way that CT Bk5 "got wrong" MD and JD volumes vs Bk2.

The repercussions of that change were not fully explored*, but it was noted in the designer's notes (In one of their mags) that JFuel was changed because they were using striker PP rates for fuel, resulting in much higher fuel volumes for PPFuel.

*It leads to courier ships able to do 2j5 or 3J4. And makes carefully designed freighters with non-LS cargo holds really cheap... and a couple other interesting dodges.
 
My original reply was essentially saying what whartung has said; part of the job of the jump program is to calculate all the vectors for the known objects/masses and figure where the destination will be, and put the ship in a place that will allow the ship's vector and velocity that is carried through jump to get the ship there in the minimum time (or in whatever state you desire to be).

Jump time is variable but estimable.

"Following some one through jump" to a known destination is possible but since you don't know where the vessel will aimed at, it's likely not going to result in a similar emergence point.

IMTU, the Authorities require commercial vessels to emerge at a particular place in order to control the lanes and for safety. Warships generally follow this rule for convenience. There are bouys proximate to the emergence points which broadcast system data for vessels and tracked objects except SBDs and other system defense vessels /warships whose locations are desired to remain hidden to non active scans. Active scan is discouraged as it clutters the frequencies. Ships entering the system must arrive at solar polar north and travel south; departures head south to the exit point. In system traffic operates at the ecliptic plane.
 
From MWM Jumpspace article:

"The duration of a jump is fixed at the instant that jump begins..."

Says to me the duration is fixed once you jump, not before. Once you jump, "the instant that jump begins", you cannot change it, you are committed to the jump and it will take that long to complete.

"The exact time of emergence is usually predicted by the ship's computer"

And I agree the "usually" here refers to circumstances other than a normal jump. A normal jump has an exactly predictable time of emergence when the jump is computed. And this can be done far ahead of time as evidenced by the use of jump cassettes. Only misjumps will have an unpredictable time factor.

In my opinion it follows logically from this that the x,y,z component is also exactly known.

And further if the exact time of emergence can be computer predicted then the whole boondoggle of fleet jumps is done away with. Fleets can simply have each ship plot its "exact time of emergence" for the agreed upon jump destination and then stage its departure* such that the ships arrive in the desired order with the desired separation. No need for all the fuss with coordinated jump rules later introduced and still arriving at random times (which the statements rule out as the actual effect).

* a factor of the jump plot
 
Not "got wrong" but "intentionally changed". In the very same way that CT Bk5 "got wrong" MD and JD volumes vs Bk2.

The repercussions of that change were not fully explored*, but it was noted in the designer's notes (In one of their mags) that JFuel was changed because they were using striker PP rates for fuel, resulting in much higher fuel volumes for PPFuel.

*It leads to courier ships able to do 2j5 or 3J4. And makes carefully designed freighters with non-LS cargo holds really cheap... and a couple other interesting dodges.
Nope, they got the way jump fuel is used wrong.

They reverted to the original CT paradigm of all jump fuel used regardless of jump distance - which is contradicted by CT revised and HIgh Guard 2 (HG 1 having clarified things by introducing the jump regulator).

I'm also of th long held belief that the designers of HG 1 to the jump drive and manoeuvre drive tables transposed and we were stuck with that - yet CT revised, TTB and ST all retained the original large jump drive, small manoeuvre drive paradigm.
 
I read is under normal circumstances - i.e no misjump - it is known.
That's certainly an equally possible interpretation. But I have to ask, what advantage does it have in a gaming context? It can convey no tactical advantage, because once you get the information it's too late to use it. You're in jump-space and you're going to stay in jump-space until you're past the arrival moment. And as for the role-playing part of the game, I really think the dramatic possibilities of uncertainty are a lot greater than those of certainty.

Compare:
"Jump drive engaged! Let's see... we'll emerge in 6 days, 20 hours, 43 88/100 seconds. Looks like you'll be on Regina in time for the Grand Opening of the Credo Midsummer Festival, Mr. Brassall."

6 days, 20 hours, and 44 seconds later:

"Oh dear! We're over time. That means we've got ourselves a misjump. Guess you won't be attending that Grand Opening after all, Mr. Brassall."
With:
"We're 4 hours past the average. Looks like you might not make it to that Grand Opening, Mr. Brassall."

"We're 6 hours over. Sorry about that, Mr. Brassall."

"We're 8 hours over. Hope we're not having a misjump. Just kidding!"

"We're 10 hours over. Do you think we might be having a misjump? How often is a ship 10 hours over time?"

"We're 12 hours over time! Only one ship in a thousand is that late!! We're having a misjump!!!"

"Captain, I'm detecting emergence vibrations!"

"Thank the Great Galactic Bird for that!! Did you hear that, people! We're going to be all right! Drinks are on me in Brubek's tonight! First round, anyway..."
What reasons am I missing?

mike said:
My contention is that the folks at DGP introduced their own interpretation when they wrote the SOM (note that they got jump fuel usage wrong as well) and that it isn't actually supported in CT rules.
They retconned the fuel usage. Happily that got retconned back again later.

Traveller writers don't need to be supported by anything in the CT rules.

There are several possibilities when writers come up with new stuff:

a) The new stuff expands on previously published information and fits in with no contradictions. No problem there; the new stuff is simply additional canon.

b) The new stuff deliberately replaces old stuff. In this case the new stuff is in and the old one is out. Unless it is re-retconned again later, of course.

c) The new stuff inadvertently contradicts some old stuff that the writer didn't know about or forgot. In that case you have a canon conflict that must be resolved by The Powers That Be, hopefully soon enough to head off numerous futile discussions on the various Traveller forums. (Well, a guy can dream, right? ;))


Hans
 
From MWM Jumpspace article:



Says to me the duration is fixed once you jump, not before. Once you jump, "the instant that jump begins", you cannot change it, you are committed to the jump and it will take that long to complete.



And I agree the "usually" here refers to circumstances other than a normal jump. A normal jump has an exactly predictable time of emergence when the jump is computed. And this can be done far ahead of time as evidenced by the use of jump cassettes. Only misjumps will have an unpredictable time factor.

In my opinion it follows logically from this that the x,y,z component is also exactly known.

And further if the exact time of emergence can be computer predicted then the whole boondoggle of fleet jumps is done away with. Fleets can simply have each ship plot its "exact time of emergence" for the agreed upon jump destination and then stage its departure* such that the ships arrive in the desired order with the desired separation. No need for all the fuss with coordinated jump rules later introduced and still arriving at random times (which the statements rule out as the actual effect).

* a factor of the jump plot
TCS also allows a ship to be slaved to the bridge and computer of another ship to make a jump in the event of battle damage - takes a week to set up though.
 
They retconned the fuel usage. Happily that got retconned back again later.

Traveller writers don't need to be supported by anything in the CT rules.

There are several possibilities when writers come up with new stuff:

a) The new stuff expands on previously published information and fits in with no contradictions. No problem there; the new stuff is simply additional canon.

b) The new stuff deliberately replaces old stuff. In this case the new stuff is in and the old one is out. Unless it is re-retconned again later, of course.

c) The new stuff inadvertently contradicts some old stuff that the writer didn't know about or forgot. In that case you have a canon conflict that must be resolved by The Powers That Be, hopefully soon enough to head off numerous futile discussions on the various Traveller forums. (Well, a guy can dream, right? ;))


Hans
Lol, I like your last point.

However back to the jump fuel retcon - I'm not talking about the amount of fuel - I understand the reason for that - but rather that they accidentally went back to using fuel as in CT first edition - all fuel is used for your jump regardless of distance.

Pretty basic error that.
 
A normal jump has an exactly predictable time of emergence when the jump is computed.
But that would mean that the jump duration was established before the jump was initiated, at a time when the ship can still abort the jump and recalculate a new one. ""The calculated jump will take 180 hours. Abort and recalculate for jump in 20 minutes' time. How long? 164 hours? What are the odd of getting a shorter duration on another jump? Hum... We'll take this one then. Ready for jump!!"

See how that doesn't work?

And this can be done far ahead of time as evidenced by the use of jump cassettes. Only misjumps will have an unpredictable time factor.
Jump cassettes would be calculating the jump a REALLY long time in advance. Now you'll have System Control calculating thousands of jumps and selling the short ones to the highest bidder.

I see a jump calculation determining that if you're at this particular spot in space at that particular time and engage the jump drive with these parameters, you'll end up in the destination system at THOSE coordinates (give or take the spatial uncertainty) in 168 hours +/- 10%.


Hans
 
So I take it from all this discussion that no-one actually knows the answer lol!

Therefore I am going to say that in my Traveller universe a ship has to slow to a stop to jump accurately and then emerges from jumpspace at zero velocity. If it is moving when it jumps there is an increased risk of a misjump. Direction of vector on emergence is pretty much random and cannot be predicted. Also emergence is somewhere outside the 100d limit from the main world but again exact location is random.

Thus Xboats entering a system have to wait to be picked up by a tender and this can take a long time due to the randomness of the entry point but they can transmit their messages straight way.

In terms of pirating the only feasible pirate location is to wait somewhere beyond the 100d limit of the main planet so that they can reach a closely emerging ship heading inbound if they have faster engines. I think the random jump entry point idea is the only thing that makes pirating feasible. If the entry point was common every time then the point would have a constant heavy police presence, and pirating would be impossible. A radom element at least gives pirates a chance to reach ships heading inbound if they are already in the area. I like the idea of the Frontier PC game where emerging from jump space causes a residue that is imminently detectable to ships in the system including pirates and defense squadrons.

I think in terms of leaving a system the obvious route out is a direction away from the orbital path of the planet so that the 100d limit is reached the quickest.

I dont consider pointing to a destination system is at all necessary when using a jump drive.

So there you go thats my take on it.
 
Nats,
there is no such thing as "zero velocity"... unless you reference something else. If you are in system A at V=0 vs it's star, and exit jump in system B, at v=0 to its star, you have to account for the difference in V of the stars themselves....

Some systems may be 100G-hours vector difference or more... but usually only a few 10's of KPS... 10kps is 1000G/sec... roughly 15 min at 1G. So typical jumps will be correcting for an hour or so...
 
Back
Top