Diagonal parking in a parallel universe

[esampson]

or "Bootlegger Reverse, Mr. Sulu"
(I'm busting this out of the jump occlusion thread because it also has a lot of relevance to the thread on astrogation and what it is that the navigator does)
------------------------------------------------------------------------

. . . I don't know if you're accounting for the relative motion of the source world and destination world. Doing a little cocktail napkin math, I estimate that a scout leaving an earth-sized orbit 3 world for another earth-sized orbit 3 world could experience up to a 40% increase in relative speed that would have to be accounted for. That is perhaps enough to handwave away under the calculations a astrogator makes, but it could add to other things, like travelling from a larger planet to a smaller planet.

Last, I did a little looking up on relative motion of stars. Turns out they can be significant. Barnard's Star has a radial velocity of 111 kps, and a traverse velocity of 90 kps, giving a true motion of 140 kps. Now if you have a scout travelling at say, 160 kps at the 100 diameter point, that's a more significant fraction. The nearby star with the largest true velocity (relative to the Sun) is Wolf 424 (at 4 parsecs away) which moves at 555 kps, so it can vary by quite a bit.

555 km/s would take a bit under 16 hours to cancel out at 1G, or 8 hours to cancel out at 2G, and this is your largest case. My guess is that a good astrogator would take a course out that would result in a minimal velocity difference when he reaches the jump point. Remember that the jump point does not need to be within a line between the departure planet and the arrival point. It is quite possible for the scout to be flying almost directly away from his arrival point as long as he ends up with a clear jumpline.

I would assume astrogation between such an extreme differential for a 1G ship would work something like this:

The navigator would pick a point about 4,064,256 km out from his ultimate destination that is directly along the new vector path (i.e. assuming vectors remain unchanged he would ram into his goal at 555 km/s a little over 2 hours after arrival) assuming that point isn't occluded by the 100D limit of a star. If it is then he will pick a point close to that, though farther out that isn't occluded, but for now lets assume that the biggest problem our navigator has to overcome is extreme velocity.

He would then pick a point about the same distance away from his departure point (planet or station or wherever he is taking off from) in the direction of the vector differential. Again, if that point is occluded by the 100D limit of a star he's going to have to do some work, but that's why he gets paid the big bucks. He can alter the two distances until he finds one that works or at least is reasonably close, but once again let's assume the only big problem the navigator has to overcome is the large vector differential.

Neither of those distances are so great that there is any real chance of coming within 100D of another planet (it's about 1/10th of the closest Earth has even been to Mars in recorded history) except in extremely unusual circumstances so all the astrogator has to worry about is being within 100D of a satellite, running into things along the way, or that the jumpline itself is occluded. Nearly all of these things can be dealt with by either minor course changes or else altering the jump points so that they are no longer 'even' (one is now significantly further out than the other).

To reach the first jump point would take about 8 hours. During this entire time the ship is moving along the vector differential so it is essentially decreasing the differential to 227.5 km/s. Of course to everyone else on the ship it would simply seem like they are flying away from the planet to a random point in empty space, but again, this is why the navigator gets paid. The ship jumps and spends a week in j-space and when it precipitates out into r-space it starts up its engines again. For the next 8 hours it would look to passengers on the ship like the ship is approaching the final destination point backwards, firing its engines to slow down.

So 16 hours of maneuvering, about 7 of which would be essential anyway just to get to your 100D limits if you were taking off and landing on Earth sized planets, and that's the worst case scenario of pretty much the highest velocity differential around and a ship that is only a 1G ship.

Of course I haven't calculated in proper safety margins to deal with scatter and the fact that a jump isn't exactly 168 hours, but then I'm not really a navigator and I don't get paid for that.

 

[HG_B]

If using retained inertia, what you wrote is exactly what the Astrogator would be instructing the Pilot to do.

 

[Murdoc]

Yes, I have no doubt that is all the stuff a navigator would have to do, realistically speaking. My point is that none of that is really accounted for in the rules, which only mention accelerating to the 100D of the source planet, jumping to the 100D of the destination planet, and all travel times are calculated from that alone. Of course, making the players go through all that calculating (not to mention the GM which would have to figure out all the planetary orbit vectors and such) is just annoying, so that's why we ignore them. Hence, your earlier suggestion would be a good way to explain this particular handwave. That's all I'm saying.

 

[pendragonman]

T5 reference p149 gives how long it takes for an astrogator to manually confirm the calculations, computer aided is much faster.

 

[HG_B]

T5 reference p149 gives how long it takes for an astrogator to manually confirm the calculations, computer aided is much faster.

Given that the calculations would be more complex than those for the Apollo moon shot. Unaided by a computer, it should only take the lone Astrogator a few weeks... :rofl:

 

[esampson]

Yes, I have no doubt that is all the stuff a navigator would have to do, realistically speaking. My point is that none of that is really accounted for in the rules, which only mention accelerating to the 100D of the source planet, jumping to the 100D of the destination planet, and all travel times are calculated from that alone. Of course, making the players go through all that calculating (not to mention the GM which would have to figure out all the planetary orbit vectors and such) is just annoying, so that's why we ignore them. Hence, your earlier suggestion would be a good way to explain this particular handwave. That's all I'm saying.

Personally I would handwave it by saying that those actions take place but in the vast, vast majority of cases they are too trivial to worry about. So the entire trip took an extra 9 hours due to pretty much the most extreme conditions we can reasonably create. Unless they players are racing the clock and the ref has decided that such unusual circumstances are occurring it really doesn't need to be bothered with (and if they are racing the clock and the ref has decided such conditions are occurring then it is probably a plot point and the ref should come up with some kind of extra roll for cutting down the time because there are lots of additional possibilities like landing closer to the destination and using atmospheric braking to bleed off speed or maybe popping out close to a satellite and using its gravity to alter your vector).

Worrying about whether the trip takes a few extra hours because of unusual conditions is sort of like figuring out how long it takes a character to find a parking space after they've driven from one town to another. Sure, the character obviously had to do it but unless it is really crucial to the plot the ref will almost always just look at the distance between the two points and the average safe travel speed to figure out how long it took, if he even bothers with that.

 

[HG_B]

(and if they are racing the clock and the ref has decided such conditions are occurring then it is probably a plot point and the ref should come up with some kind of extra roll for cutting down the time because there are lots of additional possibilities like landing closer to the destination and using atmospheric braking to bleed off speed or maybe popping out close to a satellite and using its gravity to alter your vector).

Trying to bleed off >100 km/sec by hitting the atmosphere wil just result in a vaporized ship. A satellite (like our large moon) won't effect that type of velocity measurably.

 

[esampson]

Trying to bleed off >100 km/sec by hitting the atmosphere wil just result in a vaporized ship. A satellite (like our large moon) won't effect that type of velocity measurably.

True, but bleeding off 20 km/s could cut the trip by 1/2 an hour. Likewise if the navigator has the ship reach the satellite when it has slowed by a significant degree it might have a measurable effect. I'm not talking about turning 9 hours of extra time into 10 minutes or anything but maybe shaving off another fifteen minutes or something.

The truth of the matter is I'm not an astrogator and I don't know every trick a really good one might have up his sleeve for helping reduce time. Nor are my players astrogators. Somewhere along the line you use rolls to help abstract some of those actions, possibly with bonuses for novel suggestions (or penalties for suicidal ones).

Anyway, all of that is really beside the point because my main point is that the extra travel time can usually be handwaved away and in situations were it really can't be it's because the ref doesn't want it to be.

 

[HG_B]

True, but bleeding off 20 km/s could cut the trip by 1/2 an hour. Likewise if the navigator has the ship reach the satellite when it has slowed by a significant degree it might have a measurable effect.

You're not going to bleed off even 20 km/sec doing either of them. Even the grav from a size 8 world won't do that with its gravity well. And hitting the atmosphere at 72,000 kph (20km/sec) is going to ruin your day real quick.

 

[GrayPennell]

If your jumping into a system with any level of space flight lets say space ports or D class and better starports you probably have some sort of space traffic control system. Not only to handle orbital mechanics but to keep from bad mistakes from happing, or attacks.

The astrogator would plot a jump from one controlled space to another control port using SOP speeds for that port. The outgoing controller would get them to an accept jump point and the ship jumps out. Arriving in the system the local space control would direct the pilot to their destination.

• The less traffic a world has the less traffic control does
• The lower the skill, and/or computer the pilot, astrogator have the more one has to rely on traffic control
• Traffic control can be a DM or dice increase/decrease to astrogation/piloting
• If you jump into a system outside of traffic control orders you get introduced to an SDB
• Jumping into a wilderness system well you better be good at astrogation and piloting. Though a good astrogator may reduce the dangers faced by a pilot.

 

[HG_B]

[*]If you jump into a system outside of traffic control orders you get introduced to an SDB

Could be but, 1: Jumps aren't often that accurate, 2: when inaccurate, the odds of a SDB being within 12 hours of that ship are slim to none.

 

[pendragonman]

Given that the calculations would be more complex than those for the Apollo moon shot. Unaided by a computer, it should only take the lone Astrogator a few weeks... :rofl:

Given that today we can do "back of the envelop" calculations that couldn't be done even with computer help in the 60's, I am sure that by the time an astrogator has to manually confirm calcs could take only 24 hours.

 

[esampson]

If your jumping into a system with any level of space flight lets say space ports or D class and better starports you probably have some sort of space traffic control system. Not only to handle orbital mechanics but to keep from bad mistakes from happing, or attacks.

The astrogator would plot a jump from one controlled space to another control port using SOP speeds for that port. The outgoing controller would get them to an accept jump point and the ship jumps out. Arriving in the system the local space control would direct the pilot to their destination.

• The less traffic a world has the less traffic control does
• The lower the skill, and/or computer the pilot, astrogator have the more one has to rely on traffic control
• Traffic control can be a DM or dice increase/decrease to astrogation/piloting
• If you jump into a system outside of traffic control orders you get introduced to an SDB
• Jumping into a wilderness system well you better be good at astrogation and piloting. Though a good astrogator may reduce the dangers faced by a pilot.

All of that is somewhat plausible. You just need to bear two (or I guess three things in mind).

The first is that there is no radioing ahead. When a ship precipitates that's the first warning traffic control has that it's coming and that's completely normal. The only way for that not to happen would be if a messenger ship were to leave at a regularly scheduled time before the departing ship. It could relay information that the departing ship is going to be coming and traffic control would now be aware. This is not, however, something that appears to be done in the Traveller Universe most likely because it would only really be of use if people filed flight plans two weeks before departure (1 week for traffic control to receive the the message and another week for their reply). Otherwise the only impact of the messenger ship would be to alert traffic control the ship was coming so they wouldn't be surprised. They would still not be able to do anything about it.

Secondly, the number of stars that are within 6 jumps of a system are pretty small (measured in the dozens). That means that it would actually be possible for traffic control to predict (somewhat) what the arrival points would be. If you're in system A then someone from system B would most likely be jumping in somewhere along the vector differential. It's possible (perhaps even likely) that if the starport is regimented enough (high enough population, proper government types, high law levels) that such arrival points would be required in some systems (so if you aren't departing from the main planet in a neighboring system there might be some additional work that needs to be done to match its vector before you jump). I would expect an astrogator to know about such systems from their computer (if not experience) and they would plot their jumps accordingly, again pretty much behind the scenes unless the plot for some reason called for it.

It is also possible that a system might just require all ships to jump in at certain predesignated points and our earliest example ship would then spend 16 hours matching vectors before it makes its jump, rather than spending 8 hours before and 8 hours after. I would kind of doubt that happens very often, however, because the purpose of traffic control isn't to make the astrogator's job harder and requiring jumps to arbitrary points like that would do exactly that (and before you go off into impersonal bureaucracies not caring about making things harder for the astrogator this is a situation where making things harder would probably cause an increase in accidents).

And of course the third thing as has been pointed out is that jumps are not exact and there is unavoidable scatter.

 

[HG_B]

Given that today we can do "back of the envelop" calculations that couldn't be done even with computer help in the 60's,

Umm, no. People haven't improved at hand calculating since the 60's. Where did you come up with that?

 

[arentol]

Vectors are maintained when entering and leaving J-Space.
You can change vector in J-Space.
An M or G drive works at about 1 percent efficiency when away from gravity sources.
1% of 1G acceleration is about 0.1 m/s^2.
A jump lasts 168 hours, or about 600,000 seconds.
600,000*0.1 m/s = 60,000 m/s
So for ever 1G of M or G drive a ship has it can adjust its exit velocity by 60k m/s.
So in the case of the Wolf 424 example a 9G drive could reduce the vector difference to an entirely manageable 15k m/s, and a Scout with a 2G drive could reduce the vector difference by 120k and a 4G drive would let it drop the difference by 240k.

So combined with the OP's pre-jump vector correction a 4G drive would reduce the lost time on our "worst case scenario" to about an hour.

 

[GrayPennell]

All of that is somewhat plausible. You just need to bear two (or I guess three things in mind).

Secondly, the number of stars that are within 6 jumps of a system are pretty small (measured in the dozens). That means that it would actually be possible for traffic control to predict (somewhat) what the arrival points would be. If you're in system A then someone from system B would most likely be jumping in somewhere along the vector differential. It's possible (perhaps even likely) that if the starport is regimented enough (high enough population, proper government types, high law levels) that such arrival points would be required in some systems (so if you aren't departing from the main planet in a neighboring system there might be some additional work that needs to be done to match its vector before you jump). I would expect an astrogator to know about such systems from their computer (if not experience) and they would plot their jumps accordingly, again pretty much behind the scenes unless the plot for some reason called for it.

It is also possible that a system might just require all ships to jump in at certain predesignated points and our earliest example ship would then spend 16 hours matching vectors before it makes its jump, rather than spending 8 hours before and 8 hours after. I would kind of doubt that happens very often, however, because the purpose of traffic control isn't to make the astrogator's job harder and requiring jumps to arbitrary points like that would do exactly that (and before you go off into impersonal bureaucracies not caring about making things harder for the astrogator this is a situation where making things harder would probably cause an increase in accidents).

And of course the third thing as has been pointed out is that jumps are not exact and there is unavoidable scatter.

I am imagining most things linked to number two. The randoms of jump is due to the astrogation rolls etc. You can still get a pretty good idea where there scattering will occur. The traffic control will handle the burn issue etc and you can hand wave or roll depending how important the player interaction is. I usually say things like "Jump into to system roll your astrogation oh ok your X off from your plan point. Traffic control coms you and gives you vector instructions for you to follow. Make a pilot check ok this is easy for you."

The players may need a faster vector so they either break traffic control or convince traffic control to give them a faster vector. SDBs are standing by to watch for breakers. In a wilderness situation the pilot will face a lot more rolling.

 

[arentol]

Given that the calculations would be more complex than those for the Apollo moon shot. Unaided by a computer, it should only take the lone Astrogator a few weeks... :rofl:

I am assuming the manual confirmation process doesn't require the Astrogater to do the calculations by hand, for the very reason you have stated. It should be more of a step by step recreation and confirmation of the computers process to ensure all inputs were correct and all intermediate calculations are as expected.

 

[HG_B]

I am assuming the manual confirmation process doesn't require the Astrogater to do the calculations by hand, for the very reason you have stated. It should be more of a step by step recreation and confirmation of the computers process to ensure all inputs were correct and all intermediate calculations are as expected.

Which would take pulling out a calculator. It would take a LONG time. DAYS at least.

 

[SpaceBadger]

Which would take pulling out a calculator. It would take a LONG time. DAYS at least.

Maybe something more along the lines of checking the steps that the computer went through, with review of critical assumptions or branches in the process.

First the astrogator just lets the computer run it to final result.

Next, the astrogator runs individual steps of the process on the computer and compares it to the computer's prior result (maybe side by side windows comparing each critical step to what choices or assumptions the computer made at that step); if the astrogator disagrees at some point, he can tell the computer to do something different at that point and run it again from that point forward.

Not so much recalculating it all by hand, as just rechecking how the computer got the result that it got.

I believe in one of the ship design sequences it mentioned that the "ship's computer" is actually three computers that check each others' results. Maybe when the astrogator rechecks, he could use a different configuration (BCA instead of ABC) to make sure the same results come out.


EDIT: And lazy astrogators just go tap-tap-tap-tap-DONE and trust what the computer gave, without really rechecking to confirm anything!

 

[HG_B]

I believe in one of the ship design sequences it mentioned that the "ship's computer" is actually three computers that check each others' results.

Sounds like T5 used something I've had in my ship design sequence for years. (I originally saw this in action at Ma Bells West U.S. main switching center in the 70s)