Jump accuracy in ANY Traveller System

[esampson]

I didn't say that the orbit would change. I said the relative vector would change. At any given instant the vector of an orbiting body is equal to the tangent of the orbit at its current location.

As an example, if the Earth had a perfectly circular orbit then in one week its vector would change by just under 7 degrees. That may not seem like a lot but that would be about 3.5 kilometers per second that needs to be compensated for. For planets closer in to their primary the combination of higher orbital speed and a greater vector change could cause a much larger amount of compensation to be needed.

 

[LeperColony]

Isn't this the sort of thing properly functioning computers would essentially eliminate?

 

[Hal]

Isn't this the sort of thing properly functioning computers would essentially eliminate?

What is being missed is the fact that these "compensations" as you call it, require time in normal space. There is no getting around the fact that in order to dampen or increase velocity in any given vector - it takes TIME and the use of Manuever drives.

The reason I brought this thread into being was to find a way to keep the game from devolving into "Manuever to 100 diameter limit, jump. Exit 100 diameters away, land. Repeat as necessary."

Having a temporal component used in conjunction with a moving universe - results in having to spend time catching up with planets that aren't where you planned on them being when you exit jump space. Result? You have to spend time maneuvering to get to them.

Having a spatial error in "aim" results in... yup - time spent in maneuver drive mode in normal space to get to where you want to be and when.

Overall, adding in those factors results in the "flavor" I'm trying to achieve.

Best of all? Using vector movement - you can generate the motions of star systems sort of using the rules for planetary movement around a central mass - treating stars as "planets" and the center of the galaxy as the central mass of a single sun.

Something to think about.

 

[LeperColony]

Pretty sure that wasn't a response to me...

For what it's worth, I like the idea of making skills useful, though I think vectored movement of the entire system is probably more involved than I'd want to get for my own games.

 

[esampson]

Isn't this the sort of thing properly functioning computers would essentially eliminate?

Yes and no.

In the example I gave a computer could certainly handle those calculations. However, that's a text book problem and not a 'real' problem. There are quite a few things I've left out that might need consideration.

For one thing you will rarely jump from 100D of one planet right to 100D from another. You have to make sure that the line that is drawn doesn't intersect either sphere so in the case where you are jumping to a planet that has a relative vector of 300 km/s to the 'west' which also happens to be 'west' you have a problem. The ideal jump arrival is located far to the 'western' side of the 100D sphere which places it in the planet's own jump shadow.

Similarly, if the departing planet is far to the 'east' in its system or the destination planet is far to the 'west' of its system their own stars will provide jump shadows. What you have to do now is consider a lot of sub-optimal possibilities and figure out the 'best' option and that's not something computers are always really good at doing.

When you take a lateral vector to get around the star do you arrive with a more optimal vector that requires you to fly further to clear the star's shadow before you jump or do you jump sooner and then 'turn around' as it were? Can you perhaps use a body at either arrival or departure to alter course?

This isn't to say that a computer can't plot a course. It seems like that should certainly be possible even in the worst cases. It simply means that the course that a computer plots may not be a very efficient course because it lacks the insights of a human navigator.

 

[flykiller]

Isn't this the sort of thing properly functioning computers would essentially eliminate?

presuming accurate navigation data, sure. in fact, the entire process could be automated.

"computer, take me to regina, wake me when we get there."

"acknowledged."

climb into the lowberth ....

There is no getting around the fact that in order to dampen or increase velocity in any given vector - it takes TIME and the use of Manuever drives.

sure. but the amount of time is not great and may safely be ignored in a role-playing game. unless of course the adventure concerns some rogue extra-galactic system plowing through at .1c vd. who knows what strange non-galactic-native species are in such a system ....

 

[mike wightman]

This is one of the reasons the authors of TNE went with HEPlaR. They wanted to return to a reaction drive model where tracking fuel could become an interesting part of the adventure. To put some of the danger back into insystem travel rather than the point and click maneuver drive of HG/MT.

 

[whartung]

The reason I brought this thread into being was to find a way to keep the game from devolving into "Manuever to 100 diameter limit, jump. Exit 100 diameters away, land. Repeat as necessary."

That's all fine and good if you want to go in to that detail.

But, arguably, as a game play mechanic, it's not really that interesting.

Let's consider the basic premise that Jump takes 7 days, 168 hours +/- 10%. +/- 10% is a spread of over 33 hours, and the spread is random.

It seems that this discrepancy is part and parcel to the nature of jump space. There are some "tuning" capabilities to make the arrival POINT more or less accurate, but the arrival time -- that's just dumb luck.

Now, consider one of the original tenets of the game -- communication is speed of travel, similar to the Age of Sail.

Well, during the Age of Sail, the timing of a journey could only be estimated, as it relied solely on the force of the winds to the destination, and the winds varied. So while "usually" a trip took X days, no doubt there was an unsaid "give or take a several days or hours".

Trains can keep a schedule. Stage coaches can keep a schedule. Buses can keep a schedule. But large sailing vessels on the open sea? Not so much, not with any precision.

So, right away there is uncertainty in the trip planning that is used to set expectations (and it's all about expectations).

I've discussed in detail elsewhere what I feel are the mechanics of Jump, of preserved ship vectors, of compensating for planetary position and time and the idea of an "optimal" jump. Leveraging the travel to 100D to set up the exit vector, etc. etc.

But in the end, while there are all of these aspects of the Jump, in the end, they're not remarkable. They're routine.

Here in Orange County, we get strong, warm winds from inland toward the sea. Our airport is essentially perpendicular to the coast, and like most coastal airports, the planes take off over the sea, leveraging the on shore air flow, and of course the safety of a vast ocean in case of problems. But on the windy days, the plane take off inland, the winds are strong enough to warrant turning air traffic completely around.

When that happens, everything compensates. The flight routes, the controllers, the pilots in flight pushing a little to try and make the schedule (since they typically have to fly a little bit farther to get in to the pattern, the pilots will speed up a during the flight to make up the time).

But, this is routine for the airport, the airlines, traffic control, and the pilots. They do this all the time. Most passengers are completely unaware of it. They get on the plane, get their drinks, read their handhelds, land, and get off. For the passengers, this has essentially zero affect to their travel experience save getting a different view of the airport -- whee.

Similarly with the "Optimal jump vectors", etc. Now, obviously there can be gross impacts. It can be demonstrated, perhaps, that for 1/2 the year, the systems main star is "in the way" when traveling to another specific system because the planet is on the wrong half of the orbit. And during this part of the season, travel takes an extra couple of days as the ship accelerate to get out from behind the star. Obviously this can be an adventure hook similarly to how a "bridge is out" can be.

But, at that level, it can be hand waved in or out without having to deal with the actual detail or the mechanics, or even the timing. Making the event more a dramatic element than a technical one.

So, again, you can go in to all that detail of getting the ship pointed in the right direction to save a couple hours off of the trip, but, in the end, it's potential to have any real impact I feel is low given the imprecision intrinsic in the jump process anyway.

 

[LeperColony]

presuming accurate navigation data, sure. in fact, the entire process could be automated.

"computer, take me to regina, wake me when we get there."

"acknowledged."

climb into the lowberth ....

It would seem like all navigation checks assume accurate navigation data, don't they? I mean, you have to have an idea of where the sun is, whether you're doing the math, or the computer is.

 

[Hal]

That's all fine and good if you want to go in to that detail.

But, arguably, as a game play mechanic, it's not really that interesting.

In the end, if when I put together the tables for how accurate the jump is, how long it takes - all dependent upon the pilot, navigator, and engineer die rolls - the hope is that the reasons for my decisions will be more readily understood.

The rest of the details can go into some sort of coding in VB.NET.

I keep meaning to resume work on the vector addition coding that I had started, but until I recently resumed my Traveller campaign, I had no incentive. Hell - even if I were to finish it, I suspect no one would even want to use it for their own use.

As a vector movement game, it would be game system agnostic - usable for Classic Traveller right on down to T5. That it would give distances between ships and worlds etc - would be its only selling point.

But, who would want to use it at the table unless they had a laptop? If I could figure out how to program it for say, a tablet (such as Kindle), it might be interesting, but I can't.

 

[BlackBat242]

Having a temporal component used in conjunction with a moving universe - results in having to spend time catching up with planets that aren't where you planned on them being when you exit jump space. Result? You have to spend time maneuvering to get to them.

If you are jumping from a charted known system to a charted known system, and don't know where your target planet will be, and what its vector will be, BEFORE you enter jump, then either you have an incompetent navigator (or none at all), your computer is defective, or you were given false data at the starport.

Planets don't change directions, velocities, or orbits at random - they move in stable predictable orbits, and those orbits (including where in the orbit the planet is at any given time) are part of the standard navigational data about that system, and is part of the normal astro-nav data publicly available at any starport within a dozen parsecs or so.

Unless you decide that there are no starports, or that the PCs have been banned from access to that data - or that the PCs are jumping into a system that has never been properly surveyed, but only observed from at least a parsec away.

 

[Hal]

If you are jumping from a charted known system to a charted known system, and don't know where your target planet will be, and what its vector will be, BEFORE you enter jump, then either you have an incompetent navigator (or none at all), your computer is defective, or you were given false data at the starport.

Planets don't change directions, velocities, or orbits at random - they move in stable predictable orbits, and those orbits (including where in the orbit the planet is at any given time) are part of the standard navigational data about that system, and is part of the normal astro-nav data publicly available at any starport within a dozen parsecs or so.

Unless you decide that there are no starports, or that the PCs have been banned from access to that data - or that the PCs are jumping into a system that has never been properly surveyed, but only observed from at least a parsec away.

Agreed. Now, let's try a thought experiment:

You have a gun. You have a really FAST moving target (ie something moving at planetary speeds). Now, you know how fast the planet is moving, and you know where YOU are pointing the gun. Now, put on a blindfold. We're going to give you an electronically fired pistol (ie instead of a hammer hitting on the shell to ignite the propellant, you press a stud, and the electrical charge ignites the combustion process). Fire at your target - but you don't know what the delay in firing will be when you fire. Ah, almost forgot... just prior to firing your gun - you have to put on a blindfold.

Because you don't know WHEN you will come out of Jump space, only WHERE - and planets MOVE, the net effect is that you may exit precisely where you expect and want to come out. If you're a mere 2 hours late, the planet will be past where you expected it to be WHEN you expected to exit jump space. So, taking earth as an example, moving through space at a speed of 18 miles per second, a difference of 2 hours means that the earth will be someplace other than where aimed at, by a factor of 3600 (seconds per hour) x 2 (hours) x 18 (18 miles per second) or 129,600.

Now, based on the fact that jump duration is variable - we could be between -10% to + 10% in time duration, or 16.8 hours too early, or 16.8 hours too late. Max separation distance between where earth might be when you planned on an exit from jump space will be: between -1,088,640 miles (too early) to +1,088,640 miles (too late).

So - that's the hard question. Where on that "arc" of planetary motion, will you find your target main world when you pop out? If you aim for the place where the planet will be if you are 16.8 hours early, then you don't have to race to catch up to it. If you set your vector for best intercept at the earliest you come out - you will have no problem reaching the planet in a short time. But if you aim for where the planet will be when you come out 16.8 hours early, and you instead, arrive only 5 hours earlier than the "average time spent in jump space", you will be 8.4 hours OFF from the point you aimed for when you aimed for. Being off by 5 hours means you have a half million miles of space to move through - and that is with 100% knowledge of what the system is like.

Being off by a total of 33.6 hours (the maximum spread between the earliest you can exit jump space and the latest you can exit jump space under the older CT rules) means you have a total of about 2.18 million miles to play "Catch up" with a planet moving 18 miles per second.

So, where do you aim for the planet at in your scenario? At the earliest you can pop out? At about the most average time you pop out? At the latest time you can pop out?

try this on for size...

Make 10 predictions of what you will roll on 2d6-7. Each time you miss your prediction of what you predicted you'd be wrong by, multiply 1.68 hours times 18 (miles per second) x 3600 (seconds per hour) times what you rolled.

THAT is how much your navigator, using perfect knowledge of where he's at, and where his target is at, will miss placing his ship at the exit point of the main world he's trying to hit.

Now for the really NASTY part of this. In my traveller universe - if you hit a 100 diameter limit upon exit from jump space, your ship takes minor damage and can cause jump sickness due to the turbulence of exiting from jump space too early. *THIS* is not the norm for Traveller. In the original traveller, you could hit the 100 diameter limit and come out within 100 diameters of the world.

With that thought in mind? Try to estimate when your ship exits, whether it is within 100 diameters of the planet at the "When" you exit and see if it helps or not.

 

[Condottiere]

I think I'll try and figure out a new algorithm that makes transitioning through more populated parsecs will make the jump more inaccurate and take longer.

 

[Hal]

I think I'll try and figure out a new algorithm that makes transitioning through more populated parsecs will make the jump more inaccurate and take longer.

In GURPS, rolling a 12 or less results in a 74% chance of success. But GURPS also utilizes the concepts of making it by a given amount might produce better results (as in the sensor rules for example).

So, for example:

Making it by 5+ means you are close - within inner system close
Making it by 2-4+ means you are moderately close
Making it by 1 or 0, means that you're in the right star system at least!
Crit success means bang on exactly where you want to go.

Mind you, that's just an off the cuff example. But if I go that route? Then I'm GOING to have to go back and re-examine the effects of longer time in normal space as far as earning power.

If I know how much a ship costs brand new, and the ship has a 20% down payment made, how many jumps per year can the ship make on average? Then, I have to make it so that the freight income BARELY covers that monthly payment, expenses paid, etc...

Then? After that, it really boils down to how well the player characters "Adventure" in building up a bankroll (not easy if freight only is barely paying the bills!) and then see how perhaps "cargo trade" might help make the difference.

In all, I'm not going to worry TOO much about this per se, but I wanted to at least show work and why I'm doing what I'm doing. Eventually, it would be nice if I (or someone else for that matter!) finished the coding on how to do vector math using Polar Coordinates. The test code I wrote that converted Polar to rectangular and rectangular back to polar seems to work.

Next thing to do is to add the built up velocity vector from the ship to its current location to determine its future position. The step after that, would be a duplication of the second step (which means I can create a subroutine that has old location (Degrees1,LengthOfVector1, Degrees1, Degrees2, LengthOfVector2, ResultantDegrees,ResultantVector) for the new location that is the addition of the two vectors.

If/when I get that done and it works consistently (ie I've playtested it a LOT), then the final step would be to determine the new location based on acceleration and direction. That one will be tricky because the new "distance" travelled is 1/2 Accelleration x time x time. The built up velcotiy will be a function of a Acceleration x time. So that produces two different results - final location, and final built up velocity.

Now, why am I doing that?

Think about it:

Current location is current location. This is relative to the star system's center of mass. Built up velocity is a vector with a direction and magnitude. No problem. Acceleration is a vector with a direction and magnitude determined by the fact that all "turns" are 20 minutes long. Stellar Velocity is a vector with a direction and magnitude. Planetary motion is a bit more tricky - but it should be possible to emulate it to some extent even if I can't emulate the "eccentricity" aspect perfectly.

In all? This is something that CAN be coded for. Toss in duration in jump space relative to the frame of reference "Center of the Galaxy" and toss in inaccuracies of jump at a spatial level, and the variable nature of jump...

well, then you have a functioning program to emulate the Traveller Universe.

As for at the gaming table? Anyone who bothers to determine the star system's attributes as far as planets in what orbital radius etc, stellar mass etc - can easily determine mean orbital velocity of a planet and simply determine how fast it moves relative to the ship. A relatively *cough* minor addition to the aspects that players face at the table. Even Book 2 has formulas easily enough utilized via a pocket calculator that adding one more step can add a little extra detail. Having a navigator who gets you closer to the main world consistently, is going to be worth more than someone who has navigator 0 or navigator 1.

*shrug*

Or for that matter - an Engineer or Pilot!

 

[Condottiere]

Well, I'm actually thinking more about it being more predictable that crossing or avoiding large gravitic sinkholes in hyperspace adds time to the journey, making it more likely that you'll end up at the far end of the temporal scale, whereas a monojump is likely to be at the lower end of the temporal scale.

 

[whartung]

Where on that "arc" of planetary motion, will you find your target main world when you pop out?

This really isn't that difficult.

You target your ship to arrive "in front of" the target planet, ahead of the planets orbital path, with enough margin to miss the 100D limit give the time vagaries. Then, you get the "free" velocity of the planet moving "toward" the ship, reducing overall travel time once you arrive.

Worst case, arriving "super early", 33.8hrs, taking in to account the planets velocity, you have just over 9hr trip at 1G.

Mind, if you did it "wrong" and ended up "chasing the planet, it's a 12 hr trip. That's worst case.

Best case, arriving leading the planet at the 100D marker, you're looking at 3.5hr trip.

(These are all with an "Earth"-ish planet)

So, ideally this demonstrates the "magnitude" of the issue involved, a difference of up to 9 hrs of flight time.

 

[Hal]

I agree that jumping ahead of where the planet will be at a conservative estimate of jump transmit time will be optimal, and trying to avoid the possibility of jump precipitation means building in a safety margin. Question is, how much extra transit time are we talking?

 

[whartung]

I agree that jumping ahead of where the planet will be at a conservative estimate of jump transmit time will be optimal, and trying to avoid the possibility of jump precipitation means building in a safety margin. Question is, how much extra transit time are we talking?

Worst case, arriving "super early", 33.8hrs, taking in to account the planets velocity, you have just over 9hr trip at 1G.

Mind, if you did it "wrong" and ended up "chasing the planet, it's a 12 hr trip. That's worst case.

Best case, arriving leading the planet at the 100D marker, you're looking at 3.5hr trip.

(These are all with an "Earth"-ish planet)

So, I'd say between 3.5 and 9 hrs.

The 33.8 hrs above is the distance you have to be leading the planet, since you can arrive anywhere between 16.8 hrs early to late, giving you the 33.6 (oops) hr window of arrival.

 

[esampson]

This really isn't that difficult.

You target your ship to arrive "in front of" the target planet, ahead of the planets orbital path, with enough margin to miss the 100D limit give the time vagaries. Then, you get the "free" velocity of the planet moving "toward" the ship, reducing overall travel time once you arrive.

Worst case, arriving "super early", 33.8hrs, taking in to account the planets velocity, you have just over 9hr trip at 1G.

Mind, if you did it "wrong" and ended up "chasing the planet, it's a 12 hr trip. That's worst case.

Best case, arriving leading the planet at the 100D marker, you're looking at 3.5hr trip.

(These are all with an "Earth"-ish planet)

So, ideally this demonstrates the "magnitude" of the issue involved, a difference of up to 9 hrs of flight time.

This is only really true for a given value of 'in front of'. In my earlier example I was able to cancel out a difference of 100 km/s pretty easily with a ship only capable of 1G of acceleration. It required me to be 18.5 degrees past the 'midline' of the planet. If I jump further ahead then that I will have a lower 'closing velocity' on the planet (assuming I precipitate right on schedule). That means it would actually take me longer to land assuming everything works out perfectly. Yes, I would gain a benefit if my ship precipitates out late but I also have a penalty if it precipitates early, and the odds for either one of those is the same.

A clearer example to show that capturing 'free' velocity doesn't do you any good is this. We will take my earlier example but now instead of taking off at a heading of 341.5 degrees we will take a heading of 90 degrees. After all, this will maximize the amount of free velocity that we gain. We now burn for 3 hours, 21 minutes, and 45 seconds before we flip around 180 degrees. We burn for an additional 1 hour, 43 minutes and 50 seconds before we reach the 100D limit and jump. We emerge directly in front of out target and burn our engines for 4 hours, 27 minutes, and 59 seconds and touch down on the planet's surface.

Total flight time: 9 hours, 33 minutes, and 34 seconds. That is 37 minutes and 35 seconds longer than our earlier trip.

You could try delaying your turn around so you arrive with a higher velocity and simply land further ahead than 100D but that doesn't work either. In the most extreme case were you don't turn around at all until after you leave jump you will need to precipitate 267D ahead of the planet in order to slow down in time and that will take you an extra 2 hours, 50 minutes, and 4 seconds.

I suspect that instead a big influencing factor is simply where the spaceport is expected to be. In all likelihood the best vector is one where, if everything goes right, the spaceport will have rotated under your ship just as you touch down. While it may take a little bit longer for you to 'chase' a point on the receding half of the planet I suspect that the extra time is less than it will take you to fly around the planet and reach the same point.