Jump Drive

[BackworldTraveller]

So what does a jump drive do while you are in jump space...is the grid active or is your ship flying through hyperspace like a football in those seconds after someone has kicked it off the ground?

Is the J-Drive something that the engineers can strip and check over while in hyperspace - or something that is left well alone because it's doing something vital?.

 

[mike wightman]

The jump drive, along with the hull grid, maintains a region of normal spacetime around the ship.
This will either be conformal to the hull out to a metre or so or will be a bubble that surrounds the ship. Note that this normal spacetime region does not require anything other than the field being maintained by the jump drive with the hull grid.

So yes, the jump drive is doing something for the week you are in jump space and you don't want to switch it off :toast:

 

[AnotherDilbert]

Agreed, the jump grid in the hull keeps "jumpspace" out, maintaining normal physics in the ship.

But the "jump drive", i.e. the big lump in Engineering, isn't doing much. The jump is fixed as you enter jump space, the ship will emerge as usual even if you blow up the jump drive after that.

 

[coliver988]

I go with Mike's view that the jump drive is still doing something, though I think I've seen other views in print to to contrary.

If the jump drive is not necessary during jump, that really opens the door to jump gates: if the drive just opens the jump space universe then does nothing else, then in theory it could be an external jump drive that shoves you through and you pop out a week later just by the nature of jump space and your jump grid/bubble.

And jump gates change Traveller (though I would not mind a hidden one or two here and there but if it were as common as the fabled z-drive per another thread :CoW: it would change everything. You could have a 1000dton ship with just maneuver drives and all cargo or passengers make a jump 6 without having to devote 60% of your volume to jump fuel)

 

[willtron3030]

And jump gates change Traveller (though I would not mind a hidden one or two here and there but if it were as common as the fabled z-drive per another thread :CoW: it would change everything. You could have a 1000dton ship with just maneuver drives and all cargo or passengers make a jump 6 without having to devote 60% of your volume to jump fuel)

:thinks:
I'd say that, perhaps:

• Such gates would have to be activated as a pair in physical contact and then transported in normal space to their endpoints, a project taking years or decades
• It's the kind of critical infrastructure I, as an invader, would consider destroying first, unless I planned to exploit it myself. Start over.
• A ship with it's own jump drive mis-jumping in or out of system within some distance of either end (~1000 light seconds) risks termination of the connection between gates. Start over.
• Mis-jumps are still possible, and without an on-board jump drive, they're a one-way ticket.
• You could rule that the gate can only be used for one jump transit at a time, and thus could only be used for four transits, two round trips, a month.
• You could even play silly-buggers with time due to relativistic effects at each end, if it's been in service for a long time, or if only one endpoint was transported at relativistic speeds.
• IMTU, even with a jump-gate instead of a jump drive, jump fuel ("buffer medium") would still be needed. It is heated by the power plant and ejected into the jump bubble. At the bubble boundary, where the laws of physics change, the gas is energetically annihilated, keeping the bubble from collapsing. (This heresy precludes use of drop tanks. I'm unashamed.)

 

[Condottiere]

1. Mongosian jump bubble creation doesn't require continued maintenance once the starship has successfully (or unsuccessfully) hypered.


2.

I guess you could use giant ring jump gates, if you assume that the bubble can be created externally from the spaceship.

 

[AnotherDilbert]

I go with Mike's view that the jump drive is still doing something, though I think I've seen other views in print to to contrary.

Quite, the "other views" seems to be canon, see e.g. T5:

A ship cannot voluntarily terminate jump early.
If its drives are destroyed, it still exits Jump Space at the end of the Jump time period (rather than immediately).
If the Jump Field is breached, much of the matter is destroyed by Jump Space. What matter that remains exits Jump Space at the end of the time period.

 

[coliver988]

Quite, the "other views" seems to be canon, see e.g. T5:

true, though I don't think CT specified one way or another. So canon now may not have been canon then

Per book 2 (p6):
Failed drives cease operations completely; maneuver drives will no longer thrust, jump drives will fail and indicate that they cannot support jump; power plants stop delivering power.

Cannot support jump could be could not support jump initialization -or- cannot support the jump process during jump.

I played before jump masking and all that, though it is implied by the rules it never really went there as we worried about the planet only. T5 also changes the jump process, adding 3 types of jump systems, as well as getting knocked out of jump if a gravitational force is somehow interacting with the jump space. Possibly implied by the rules but pretty sure CT did not have the "precipitate out of jump when hitting a gravity well".

Having said all that, yes, if I were playing T5, I would use that rule & you could do engine maintenance on the jump drive while in the jump. I generally play (okay, ref as no one in my group wants to ref Traveller) a mix of classic, Mongoose & Cepheus (with fun chrome from GURPS).

 

[AnotherDilbert]

true, though I don't think CT specified one way or another. So canon now may not have been canon then

I agree that T5 isn't CT canon, but JTAS#24 says the same thing, and is technically CT:

The duration of a jump is fixed at the instant that jump begins, and depends on the specific jump space entered, the energy input into the system, and on other factors. In most cases, jump will last a week.
...
At the end of the week in jump, the ship naturally precipitates out of jump space and into normal space.

Possibly implied by the rules but pretty sure CT did not have the "precipitate out of jump when hitting a gravity well".

Again, JTAS#24:

Ships naturally precipitate out of jump as they near the 100 diameter limit.

 

[Grav_Moped]

<snip>
I played before jump masking and all that, though it is implied by the rules it never really went there as we worried about the planet only. T5 also changes the jump process, adding 3 types of jump systems, as well as getting knocked out of jump if a gravitational force is somehow interacting with the jump space.<snip>

That reminded me of an old post:
(bold added)

Having asked Marc about this when doing some math workups for him...

In the OTU, jump really is a 2-D plane. It has no Z-axis to it. Not all systems are on it. It's generally pretty close to mapped 3D distances.

The big limits:
FTL comm goes by FTL craft
Minimum 100Td jump craft
Quantum steps on drive performance; there is no J1.1. There is J1, J2, J3 ... J9, ..., J∞, but never a decimal. A J0 drive fails to jump, but otherwise acts normally.
Astrogation requires a sufficiently large (but not of need sophisticated) computer... a 1950's era 20Td model 1 (comparable to ENIAC) can do the needed calculations, which implies that some sensor is included, more than "the math is hard".
The time is known as jump commences, but not until.
A course plot is 162:00:00±16:12:00 H:M:S
Ships sharing a course plot vary by ±1:37:12 from each other.
Courses can be reverse engineered in a few hours if the exit flash is captured on sensors.
Everything bigger than the ship can pull it out of jump.

That last, I've tried to pin Marc down on a few details, but have gotten cryptic answers. ( "" is typical)

That got me thinking.

The "larger ship 'stepping on' a ship's Jump track makes it come back to the origin" rule allows faster-than-Jump communication, albeit of a "yes/no" sort.

1. Send XBoats daily, so the destination should be receiving one daily after 7 days in Jump each.
2. Record each XBoat's exact departure point, corrected for all appropriate drift relative to whatever reference frame is necessary.
3. In the event you want to send a fast yes/no signal (though in this basic case, the signal is "no"), move the XBoat Tender to "step on" the Jump origin point of the XBoat nearest the destination, pulling it back to the origin point.


The "no" signal is the XBoat not arriving on schedule. It is controlled with no more than a 1-day lag, not the 7 days of a normal Jump.

To provide validation, stop alternating days' XBoats for a NO YES NO signal. This takes up to 3 days for a validated indication. Alternately, send two XBoats per day and have the one Jumping first be the designated "signal" boat whose absence is the signal. The second would have seen the first one Jump, to provide verification on arrival that it did depart as expected and should have arrived if not yanked back. In that case, having two consecutive days' XBoats halted could provide a verified signal.

This gets you a "yes/no" signal that can travel at the XBoat's Jn in 2-4 days, depending on the verification method. Using two J6 XBoats in parallel provides an effective message speed of (7 days/2 days)* Jump 6 = Jump 21. With 4-day validation, it's only Jump 10.5. 4-day validation and J4 (that is, using the normal XBoat pacing and NO YES NO for the signal, it's Jump 7.

Given the cost (one day's message traffic between each pair of worlds on the link for all links, and in the fastest version, 14 J6 ships per link) it'd be reserved for the highest importance messages: "War -- flee or send reinforcements", or "The Emperor is dead, long live the new Emperor", depending on which way the message was traveling.

 

[coliver988]

I agree that T5 isn't CT canon, but JTAS#24 says the same thing, and is technically CT:

Again, JTAS#24:

good points all, but not in the original books and added later. Though it is in the CT era so canon. I bow to your superior knowledge

now to re-read all those journals - I have most of them in print, and there are some good rules expansions and explanations in them. There was a gap of about 30 years between when I played in college versus my resurgence a few years ago after finding this very forum. For some reason all my Traveller books followed me over the years, as well as the few Fantasy Trip books. All the other game systems and games are long gone.

 

[BlackBat242]

I agree that T5 isn't CT canon, but JTAS#24 says the same thing, and is technically CT:

Ships naturally precipitate out of jump as they near the 100 diameter limit.

good points all, but not in the original books and added later. Though it is in the CT era so canon. I bow to your superior knowledge

You have clipped a single sentence out of an article in a manner that strips it of context, and therefore of specific meaning.

There are three paragraphs in that article which describe a ship "precipitating out of jump" - one which says:

At the end of the week in jump, the ship naturally precipitates out of jump space and into normal space.

This has little pertinence to the discussion at hand.

The other two occur in descriptions involving gravity... and both say the same thing in slightly different ways. First, in the initial description of "The Physics of Jump", in discussing the "100D limit":

The perturbing effects of gravity preclude a ship from exiting jump space within the same distance. When ships are directed to exit jump space within a gravity field, they are precipitated out of jump space at the edge of the field instead.

Then, in the section "Jump Effects", there is this:

On the other hand, there seems to be a built-in safety feature for ships trying to leave jump space within 100 diameters of a world. Ships naturally precipitate out of jump as they near the 100 diameter limit.

So all that tells us is that if you are trying to leave jump space within 100D of a world (sun, etc) you drop out at 100D instead.

There is NO mention anywhere else in the article of gravity forcing a drop from jump in any other circumstance.

Similarly, there is no mention of having to avoid gravity-producing objects in plotting a course, nor is there mention of any effects produced by "passing too near a gravity well".

If there is question, I can email scans of the article upon request.

 

[mike wightman]

I have been arguing that very point for years.

At some point in the past the Traveller fanon decided to interpret MWM's article in such a way that a ship can be pulled out of jump space by a gravity well. Loud voices then convinced MWM himself that this was how the article could be interpreted. I still think they are wrong.

And thus from on high didst the holy canon writers of GURPS Traveller invent jump masking or shadowing or whatever.

My understanding is the same as yours. Real space gravity has not affect on a ship in jump unless the ship is trying to leave jump space at the end of the journey - in which case the 100D precipitation occurs.

 

[whartung]

There is NO mention anywhere else in the article of gravity forcing a drop from jump in any other circumstance.

Similarly, there is no mention of having to avoid gravity-producing objects in plotting a course, nor is there mention of any effects produced by "passing too near a gravity well".

My understanding is the same as yours. Real space gravity has not affect on a ship in jump unless the ship is trying to leave jump space at the end of the journey - in which case the 100D precipitation occurs.

That's what I surmised when I summarized JTAS #24.

From that I quote:

+ Gravity inhibits jump. If you try to ENTER jump within 100D, you will likely misjump, probably catastrophically. If you try to exit jump within 100D, you will not misjump, rather you will simply re-enter at the 100D border.

What can we infer from these?

One, is the affect of the 100D limit. Don't start jump within a 100D limit, but if you try to exit jump within a 100D limit, the nature of the system simply spits you out at the 100D limit. This implies limited "jump masking". Notably if you're within the 100D limit of a star, you can not jump, nor can you enter within the 100D limit of a star. However nothing here suggests that the 100D sphere around a body "blocks line of sight". There's nothing to suggest that you will be pulled out of jump by a rogue gravity well. Rather, only when you actually leave jump space does the 100D limit apply, not within jump space. So, if you want to jump to the other side of a star in the same system, the star can't stop you, it's not "in the way". You can't jump in or out of it within 100D, but once you're in, it's not yanking you out. You're in the wrong dimension.

 

[BackworldTraveller]

What is "Near" given that the ship is outside dimensions X,Y and Z and tied in a limited fashion to dimension T. "Near" implies that somehow they are still bound by dimensions X, Y or Z. How does that work?

Example: I want to move from place to place in a piece of string without moving along the piece of string. So take the piece of string and loop it. Where the string first crosses are the entry and exit points of my extra-dimentional journey...in the middle of the loop the existence of the string is not relevant.

n.b. For an exact parallel, due to technological constraints, I can only bend the string so the first crossing point is up to (say) 6cm from the starting point.

 

[AnotherDilbert]

You have clipped a single sentence out of an article in a manner that strips it of context, and therefore of specific meaning.
...
This has little pertinence to the discussion at hand.

The topic of the thread is (was?) what the jump drive is doing during jump, not jump masking, hence that is what I was addressing. I certainly considered it more pertinent than an unrelated discussion of gravity effects.

 

[Condottiere]

Seems edition specific.

For Mongosian hyperspacing, the jump drive just shuts down after it tears a hole in the Einsteinian universe.

 

[mike wightman]

Where does it state that?

Maintainance of the jump drive takes place after a jump - if the drive has shut down once you are in jump space then you could do this while in jump space.

The cabling in the hull maintain the jump field during the jump, the inference is that they are getting power from the power plant via the jump drive to maintain this field.

 

[Condottiere]

You can bet that due to the fact we have to regulate the power budget during transition, we nailed down the Mongosian oracles on this issue.

Calculate a course bypassing gravitational wells, power up the jump drive, punch a hole through reality, drop through the rabbit hole, shut off the jump drive, and surf to the destination.

In a bubble, recreating the Einsteinian universe.

 

[Grav_Moped]

Where does it state that?

Maintainance of the jump drive takes place after a jump - if the drive has shut down once you are in jump space then you could do this while in jump space.

The cabling in the hull maintain the jump field during the jump, the inference is that they are getting power from the power plant via the jump drive to maintain this field.

Power plant fuel consumption rate also supports this (and seemed to me to be the in-game reason for the second-edition requirement of Pn=Jn; even though HG says it's about charging Jump capacitors, the stated capacitor capacity is far beyond what the appropriate power plant can generate).