Shipboard Chronometers & Jump Space

[rancke]

Rancke, I'm not going to argue a set of rules I have absolutely no interest in purchasing much less reading up on for jump physics that have evolved since CT. For the purposes of this conversation I can accept that this mechanic is now in place for most canon rules and that it is written for entertainment value, not consistency within a logical framework.

This mechanic has been in place since early MT at the very least.

Still doesn't deal with the other safety and cost factor, wanting to drop in at least distance to destination as opposed to possibly several light seconds out.

Say that your destination world moves 200 diameters in 30 hours in its orbit and that for some reason the movement of the solar system is compensated for. You aim for where the world will be in 168 hours. If you arrive 15 hours early, you will be at the 100 diameter limit straight ahead of the world. If you arrive 15 hours late, you will be at the 100 diameter limit right behind the world. If you arrive any time in between those two points in time, you will hit somewhere along the jump limit and be precipitated out somewhere along the 100 diameter limit. In any of these cases you'll find yourself in the exact position assumed by the various rules for arrival: 100 diameters from the world with a vactor neutral towards the world. If jump variation is distributed according to a bell curve, these instances will be by far the most frequent occurrence. Arrivals 16 or 17 early or late will be very rare and ignoring them for game purposes would be justifiable.

If you can spend extra time doing a calc and getting it exactly right, well I expect most ships will do exactly that to avoid wasting hours traveling on the other end. Doubly so for a fleet action with a maneuver plan relative to planetary defenses.

Reduce the variation from 10% to 1%. Still not exactly right. If the time the calculations take is more than the average time you can save at the other end, ships won't bother with them.

The technique is indeed described as a way for a fleet to arrive close together.

(Which, incidentally, would be unneccessary if jump time was the same for all ships leaving for the same destination at the same time).

And if the rules say you just always end up at 100-D even if you arrive 8 hours later then the plan, well I say the rules are ignoring planetary motion at the very least, or that you have a lot more control then is suggested by the jump plan mechanic.

The rules are ignoring solar system movement, right enough, but planetary motion can be accounted for quite nicely, as shown above.


Hans

 

[mike wightman]

So we allow for planetary movement, but not solar system movement or galactic movement?

The law of unintended consequence strikes again.

The only way it makes sense to me is if you are moving from one point in spacetime in our universe via jump space to another point in spacetime in our universe.

The accuracy of jump is such that you arrive within of your aim point, all relative motion having being accounted for by the incredibly complicated n-body hyperdimensional maths crunched by the model 1 computer (or the generate program if that is easier).

This journey takes about a week - you may use the time variant meta rule first introduced in HG to get a more precise time - but you arrive where you want to be within a few 1000km. You are not early or late, because you are within a few 1000km of where and when you plotted to be in spacetime.

 

[rancke]

So we allow for planetary movement, but not solar system movement or galactic movement?

The law of unintended consequence strikes again.

Certainly. The thing is, made-up universes don't come with built-in self-consistency the way the real universe does. Self-consistency is nice, as it increases the verisimilitude of a setting. But gamability is even better.

The only way it makes sense to me is if you are moving from one point in spacetime in our universe via jump space to another point in spacetime in our universe.

That's also the only way it makes sense to me. And in principle I'm all in favor of realism and sense. It's really nice when things are realistic and make sense. But if realism interferes with my gaming fun, realism can take a long walk off a short pier.

In this case I ask myself: Do I want fleets to arrive in systems scattered in time? Do I want the possibility of a pursuer arriving at a destination ahead of the pursued due to jump variation? Do I want arriving ships to (mostly) arrive along a hemicircle along the jump limit? And since the answer to these and other related questions is "yes", I'm going to ignore solar system movement yet allow for planetary movement. And I'm going to use the handwave that it's due to a mysterious effect of jump travel.

However, after skimming through various rules sets for evidence to back me up, I do have to admit that the descriptions of jump are more than just a bit vague here and there. They flat out contradict each other on important points. So I concede that my interpretation is only one of many possibilities, none of which are self-consistent. I guess that an OTU version would have to be the most recently published one and I'm not sure that that one says.


Hans

 

[aramis]

So we allow for planetary movement, but not solar system movement or galactic movement?

We cannot measure movement through spacetime except relative to other objects in spacetime.

Solar movement is beyond the readily playable level of detail.
Galactic movement is even more so. Especially since, if we account for it as part of a larger reference frame, we need to define the reference frame - if that frame is anything less than the universe itself as a whole, then there will in fact be motion within that larger reference frame.

And in the case of a nearly or truly universal reference frame, then everything in reach is going to have a vector; if J-space inherently shares that vector then it's irrelevant to calculate it.

The lack of accounting for it in any of Marc's articles and in the rules implies that J-space and N-space share the same overall vectors. It also implies that system corrections are well known.

Either that, or the software pretty much requires the jump plan automatically account for the differences in Galactic-speed and in system speed, but allows for no entry on planetary speed because not all jumps are intended to exit into a planetary body.

 

[rancke]

We cannot measure movement through spacetime except relative to other objects in spacetime.

Solar movement is beyond the readily playable level of detail.
Galactic movement is even more so. Especially since, if we account for it as part of a larger reference frame, we need to define the reference frame - if that frame is anything less than the universe itself as a whole, then there will in fact be motion within that larger reference frame.

And in the case of a nearly or truly universal reference frame, then everything in reach is going to have a vector; if J-space inherently shares that vector then it's irrelevant to calculate it.

The lack of accounting for it in any of Marc's articles and in the rules implies that J-space and N-space share the same overall vectors. It also implies that system corrections are well known.

Either that, or the software pretty much requires the jump plan automatically account for the differences in Galactic-speed and in system speed, but allows for no entry on planetary speed because not all jumps are intended to exit into a planetary body.

Hey, that even makes sense!


Hans

 

[simonh]

What if a ship can operate it's manoeuvre drive while in jump space, and that doing so will affect it's final vector on exiting jump space, relative to it's point of origin? If that's the case, compensating for the relative motion of the target star system and the target planet's orbital motion while in jump becomes pretty trivial. That potentially solves the relative motion issue.

Jump duration is a bit trickier, but I think the issue can be mitigated as well. If the distance of a jump is always relative to the point of entering jump, in principle all you have to do is match velocities with the target point before entering jump. Then it doesn't matter how long the jump takes, you will still exit jump space at your target point because the ship's relative motion in jump space will match the target point's relative motion in real space. If you can manoeuvre relative to your jump entry point in jump space as well, you don't even need to match velocities with the target point before entering jump, as long as you take into account your intended relative motion and vector change in jump space ahead of time in the jump calculations.

"My intended destination relative to the target planet is point X. While in jump space I will need to manoeuvre by vector V1 to match velocities with the target planet. The net relative motion compared to point X due to vector V1 is S1. Therefore my jump exit target point before entering jump is point X offset by S1."

Of course this makes 'dinosaur killer' attacks against target planets a lot easier, because you can do the required acceleration before going into jump and give the target system virtually no chance to react. But then I belong to the 'Laa Laa Im Not Listening' school of thought when it comes to relativistic planet busting in Traveller. It's the same approach I take to time travel paradoxes due to FTL travel. I think they're both just beyond the scope of the game.

Simon Hibbs

 

[whartung]

Gonna refer back to this thread, as it accurately summarizes the salient points of the JTAS 24 article regarding jump space.

http://www.travellerrpg.com/CotI/Discuss/showthread.php?t=25076

Despite the discussion of compensating for planetary motions, etc., the other elephant in the room that is not discussed is the preservation of a ships vector after exiting jump.

Since a ships vector, to be useful, is relative to the system where the ship entered jump, then the differences in overall system motion must be compensated for. Upon exiting jump space, the differential vector between the originating system and the destination system is added should be added to the ships vector in order to get the "true" vector relative to the entry system.

So, a ship could be "stopped" (i.e. 0 vector) in the entry system, but have a 1000 km/s magnitude vector, "going up", when they arrive at the destination system. And the vector will need to be compensated for so the ship can get in to orbit or to where it wants to go.

This phenomenon is even mentioned in the JTAS 24 article, and captured in the summary.

Mind, I appreciate why none of this happens -- the real mechanic of Jump is that it takes a week.

 

[rancke]

Despite the discussion of compensating for planetary motions, etc., the other elephant in the room that is not discussed is the preservation of a ships vector after exiting jump.

Since a ships vector, to be useful, is relative to the system where the ship entered jump, then the differences in overall system motion must be compensated for. Upon exiting jump space, the differential vector between the originating system and the destination system is added should be added to the ships vector in order to get the "true" vector relative to the entry system.

So, a ship could be "stopped" (i.e. 0 vector) in the entry system, but have a 1000 km/s magnitude vector, "going up", when they arrive at the destination system. And the vector will need to be compensated for so the ship can get in to orbit or to where it wants to go.

This phenomenon is even mentioned in the JTAS 24 article, and captured in the summary.

My explanation is that the rules pertaining are a simplification for game purposes. What actually happens (according to me) is that the departing ship accelerates and decelerates, not to a zero vector vis-a-vis the departure world (as the rules say) but to a zero vector vis-a-vis the target world. Thus it arrives in the target system with a neutral vector towards the target world (just as the rules say). The procedure outlined in the rules of accelerating and decelerating in the departure system is a simple way to emulate this without having to futz around with relative motion of the two systems, so to simplify the game that's what is done.


Hans

 

[SanDragon]

Perhaps the variation of time-in-jump is where the velocity matching between departure and destination systems occurs...

 

[kilemall]

Well now, you can use awesome GM physicist powers and deal with this.

You could say that the jump plan is not to a specific point in time and space, but to a specific gravitic effect zone relative to major astronomical bodies, so as the ship nears its jump mark it's arrival 'snaps to' that relative location, whether that is a warp tunnel/grav tunnel/wormhole/teleport/jumpspace maneuver mechanic, etc.

So if your planned arrival point is 105 D leeward of the planet, that's where you go because its approximately the same point relative to the planet and star gravity fields, and variation is due to jumpspace conditions requiring more time or small gravitic effects of passing rocks or even ships that are affecting the arrival location.

Maybe the navigator is a busy sentient the last few hours to finalize that approach and emergence within the jump plan parameters, using various densitometers and other grav related sensors to 'hit the right spot'.

Makes my skin crawl, but would be at least a more consistent 'philosophy of jump physics'.

 

[Condottiere]

While not a misjump, I doubt that a perfect jump is possible, and if it occurs, the astrogator achieved that more by luck than skill.

Which means that on exiting hyperspace, the computer will try to reorientate itself in space and time.

 

[kilemall]

While not a misjump, I doubt that a perfect jump is possible, and if it occurs, the astrogator achieved that more by luck than skill.

Which means that on exiting hyperspace, the computer will try to reorientate itself in space and time.

Pulsars, variable stars, and recent supernovas are your tools of the trade. Possibly GPS type transmissions in the local cluster/main.

 

[Condottiere]

That's when you pull out the sextant, and take a sighting.

Though in inhabited systems, I'd expect that the Scout Service maintains a radio beacon.

 

[Patron Zero]

I would tend to believe that once out of J-space a ship's navigational systems would automatically take a 'sighting' as well as scan radio frequencies, for 'pings' from buoys or way-stations, to receive chronometer 'updates'.

 

[kilemall]

I would tend to believe that once out of J-space a ship's navigational systems would automatically take a 'sighting' as well as scan radio frequencies, for 'pings' from buoys or way-stations, to receive chronometer 'updates'.

Probably.

However, read enough of the Chanur series and you can get leery of what a system owner can do who owns all the navigational and IFF plot update type 'services'.

 

[simonh]

I would tend to believe that once out of J-space a ship's navigational systems would automatically take a 'sighting' as well as scan radio frequencies, for 'pings' from buoys or way-stations, to receive chronometer 'updates'.

I would imagine the main ship's clock would be accurate enough that ti shouldn't need updating all that often. When you do get updates, I think you'd prefer to do it by hard link rather than radio signal to avoid latency issues.

I was thinking about long distance clock synchronisation. I can see two good ways to do it.

One I mentioned in my first reply to the thread, pulsar signals, but I'll expand on it. One pulsar on it's own is not enough because you can't distinguish individual pulses. However there are many pulsars, each with a different period. Given that we know the direction to each pulsar and their period, this creates an 'interference pattern' of pulses with different periods across settled space. If we record the pulse pattern for each pulsar and share those recording across known space, we can calculate when specific combination-sequences of pulsar pulses from different pulsars in different directions should reach any given system or planet. This could actually be used for either positioning if you already have synced clocks, or clock calibration if you already have accurate positioning data. Position can also be calculated using triangulation against known quasars but the accuracy won't be all that great.

The other method uses good old fashioned atomic clocks. Any acceleration or deceleration of a ship carrying an atomic clock will cause relativistic dilation effects that will cause the clock to drift relative to an at-rest clock. There are two ways to mitigate this. One is to measure the acceleration with an accelerometer and calculate the offset, adjusting the clock to take it into account. The other is to not accelerate the ship. Time-sync x-boats would jump into a system and wait for a tender to come to it and refuel and re-crew it for it's next jump (or physically transfer the clock to a new xboat). You'd still need to account for gravitational effects, so you'd want these sync boats to jump into the outer system of the worlds it visits, well away from any planets and far enough from the star to minimise the effect, although again the mass and distance of the star will be known so you can account for the relativistic effects and offset the clock. The universal master clock would need to be kept in deep space.

My best guess would be that the atomic clock method would be the best way to do clock sync, and then the quasar pulse pattern method would be used for accurate positioning. However positioning relative to nearby systems can also be worked out based on the relative positions of ships when they enter and emerge from jump.

Simon Hibbs

 

[Condottiere]

The radio beacon is just meant to be an easy way to orientate you as you exit jump space, so you know where and when you are.

The computer updates itself with precise data from a certified source when it docks at the starport.

 

[rancke]

While not a misjump, I doubt that a perfect jump is possible, and if it occurs, the astrogator achieved that more by luck than skill.

What's a perfect jump? As far as we know, there are two kinds of jump, ordinary jumps and misjumps. Time distortions are associated with misjumps. So the first question is whether ordinary jumps ever involves any time distortion. AFAICR there's no evidence about it (either way), though I could be misremembering.

If a ships makes a jump and a return jump and its clock shows that it spent X time in the first jump, Y time in the turnaround system and Z time in the return jump, and, upon returning to the original system, finds that X+Y+Z time has elapsed there, I submit that a meaningful time realtionship between the two systems involved has been established.


Hans

 

[aramis]

What's a perfect jump? As far as we know, there are two kinds of jump, ordinary jumps and misjumps. Time distortions are associated with misjumps. So the first question is whether ordinary jumps ever involves any time distortion. AFAICR there's no evidence about it (either way), though I could be misremembering.

If a ships makes a jump and a return jump and its clock shows that it spent X time in the first jump, Y time in the turnaround system and Z time in the return jump, and, upon returning to the original system, finds that X+Y+Z time has elapsed there, I submit that a meaningful time realtionship between the two systems involved has been established.


Hans

Your lack of MT & TNE knowledge is showing.

Both have minor mishaps that result in the time flow aboard not being tied to time at either end.

As in, it's possible to Jump from Regina to Wypoc, experience 5 days in jump, jump back, experience 4 days in jump, and back to wypoc, taking 6 days in jump... but in both return cases, it's been 7 standard days per leg for the locals.

Or the opposite: another ship jumps both routes, and experiences 7 days each, but due to a (worse) mishap, the jumps took 11, 9 and 8 days.

Only when it's all working right is time in jump synched with time in N-space.

 

[Spartan159]

Your lack of MT & TNE knowledge is showing.

So why is it that I can picture Will in a Darth Vader outfit saying this in a deep voice while Force choking Hans? :rofl: