General Conservation of Momentum and Astrogation

[RogerD]

As I understand the canon, conservation of momentum is maintained even with jump. Therefore with the right data and enough math you can set the frame of reference to be the destination (as it will be in about a week) and plot your course.

Ignoring jump shadows, the math is a lot like that presented in Book 2, except that you would need to account for the initial velocity as well. In fact, the maneuver time would be strictly that needed to match velocities. t = v/a.

To take jump shadows into account is tougher math since you then have to choose the entry and exit points for jump. I think that the safest approach is to match velocities as best you can for the destination jump point so that you minimize risk and damage of impacting something on the other end of the jump. I can see other approaches like trying to minimize maneuver time or deliberately jumping in to a system with a high velocity in the new system for tactical reasons, but those would be riskier moves.

I was wondering if anyone has come up with rules to compute the relative velocities between two planets? I don't think I've seen that in anything official.

It's likely you really need computer support if you want this level of detail. Perhaps someone has already written such software?

 

[whartung]

The relative velocities between two planets is relatively simple. Just need their orbital speed, and their orbital position (i.e. what time of year they are). The orbital speed is determined by the primary and the distance from it. Once you have that, the velocity vector is essentially the tangent to the orbit at the orbital velocity.

The nit is the differential vector between the system primaries. Each primary has their own vector (they're orbiting something as well), and those differences would indeed need to be taken into account. But, for simplicity, you can toss them away.

Other than that you're correct.

Once given the to vectors (the origin and destination vectors), the navigator could plot their course as a single straight line burn and decel that's, in theory, no different than going from, say, Earth to Jupiter. Full burn accel plus full burn decel is the fastest path. At some point you have your mid point turn over. With Jump you can decide where you want that turnover to be, whether it's in the origin system or the destination system.

For example, perhaps the destination system is infested with pirates and you really want to minimize your time in space there, so you plot your course to do all of the acceleration, the mid point turn, and part of the deceleration in the origin system so as when you arrive, you have just the last leg of the deceleration to get you into orbit.

Similarly, you may want to get out of Dodge at 100D as fast as you can, but theres a Corsair in the way on the most optimal vector. No matter, just go the other way, hit 100D and jump. When you arrive, you have to do all that extra maneuvering to make planetfall but now you're in a quiet, secure system and its safer to spend time there.

The only other nit is the dynamics of the jump window with its +/- 10% arrival time. That's just something you have to accommodate for leaving margin in the flight plan. Also your arrival point isn't necessarily fixed as well, but its only a few thousand kilometers, not a big deal in the overall sense of things.

All that said, while determining the destination vectors of the planets is straight forward, actually calculating the course is a real pain in the neck. We're talking differential equations stuff going on there. Even for the simplest straight line case, much less the less perfect scenarios.

 

[RogerD]

All that said, while determining the destination vectors of the planets is straight forward, actually calculating the course is a real pain in the neck. We're talking differential equations stuff going on there. Even for the simplest straight line case, much less the less perfect scenarios.

For sure we don’t want to try to solve the N-body problem for a game. With constant accelerations of 1-6g though, approximating as a simple straight line course is simple enough. You would predict your destination to be wherever it will be in a week or so and set course for there. Blasting directly to the destination’s current position is likely to be close enough, though not optimal.

The real hassle as a game mechanic is working out what the final relative vector should be. It’s all calculations you learn in your Dynamics class in Engineering, but you also have to have the orbital data.

I suppose the simplest solution on the fly might be to simply make up a vector number that has to be compensated for somewhere during the journey.

 

[AnotherDilbert]

Relative motion of planets and star systems are fairly small factors, that can easily be ignored for simplicity.

IIRC, relative star motion in our neighbourhood is generally in the 20 km/s range, compensated by accelerating by 2 G for 1000 s. Not a biggie.


The big factor is the jump shadow of the stars. For red giants the 100D limit is much further out than the habitable zone, requiring days or even weeks of acceleration.

The jump shadow of the local star also limits the directions in which you can jump from the primary planet. To jump to the other side of the star, you have to clear the 100D limit of the star first, and vice versa when arriving. Again this can add days of accelerating to the journey. Which jump routes are blocked by the star varies by time as the planet orbits the star.

Something like this:

This is of course way to much trouble keeping track of, so everyone ignores it...
Perhaps it can be used as a plot device?

 

[Condottiere]

Monsoon winds.

 

[kilemall]

Monsoon winds.

Variable star ‘winds’?

 

[RogerD]

The jump shadow of the local star also limits the directions in which you can jump from the primary planet. To jump to the other side of the star, you have to clear the 100D limit of the star first, and vice versa when arriving. Again this can add days of accelerating to the journey. Which jump routes are blocked by the star varies by time as the planet orbits the star.

I love this concept, I hadn't quite put that bit together yet. You could potentially have seasonal trade between certain worlds or even use multiple jumps to get to your destination faster. Too bad it is hard to track (again, without computer support)

One idea this sparked is that a high population or otherwise important world might have a Farport stationed at the L3 Lagrange point (on the other side of the star) with non-jump ferries to handle the in-system transport. The bigger the jump bubble, the more important that farport would be for keeping up year-round transporation.

 

[rlmercad069]

Some of us just call it hot jumps, since you don't slow down but instead speed up to a point that the ship can slow down at the destination. There has been some discussion about this in some story lines. All one needs are the proper NAV tables loaded in the ships computer to workout the jumps. Commercial shipping doesn't do it due to risk, wear & tear on their ships plus the cost of upgraded NAV computers and their tables for example MOD 1 bis vs MOD 2 computer for jump 2s. On the other hand the Navy has the budget and the need to be able to make such jumps as required to do their missions.

 

[Condottiere]

Actually, jump streams is an option.

But, large jump shadows would tend to alter over the year the jump entry and exit points, at both ends, so optimization to shortest time spent pre and post transitional travel could depend on the season.

 

[mike wightman]

Hmm, a mark on the hex grid to show which half hex side is favoured this couple of months, The adjacent faces adda couple of time periods to the jump (hours to days based on star).

 

[whulorigan]

Some of us just call it hot jumps, since you don't slow down but instead speed up to a point that the ship can slow down at the destination. There has been some discussion about this in some story lines. All one needs are the proper NAV tables loaded in the ships computer to workout the jumps. Commercial shipping doesn't do it due to risk, wear & tear on their ships plus the cost of upgraded NAV computers and their tables for example MOD 1 bis vs MOD 2 computer for jump 2s. On the other hand the Navy has the budget and the need to be able to make such jumps as required to do their missions.

IIRC, the terms "running jump" and "standing jump" have also been used for these ideas.

 

[whulorigan]

The big factor is the jump shadow of the stars. For red giants the 100D limit is much further out than the habitable zone, requiring days or even weeks of acceleration.

The jump shadow of the local star also limits the directions in which you can jump from the primary planet. To jump to the other side of the star, you have to clear the 100D limit of the star first, and vice versa when arriving. Again this can add days of accelerating to the journey. Which jump routes are blocked by the star varies by time as the planet orbits the star.

...

This is of course way to much trouble keeping track of, so everyone ignores it...
Perhaps it can be used as a plot device?

I love this concept, I hadn't quite put that bit together yet. You could potentially have seasonal trade between certain worlds or even use multiple jumps to get to your destination faster. Too bad it is hard to track (again, without computer support)

One idea this sparked is that a high population or otherwise important world might have a Farport stationed at the L3 Lagrange point (on the other side of the star) with non-jump ferries to handle the in-system transport. The bigger the jump bubble, the more important that farport would be for keeping up year-round transporation.

For the GM willing to do the extra work, I think this adds a lot of local color and background-setting possibilities to a campaign. The seasonal routes, and especially the red-giant jump-shadow situation create a lot of setting considerations (i.e. who would find it profitable to trade with a red giant system, or what would be an important enough commodity to be profitable. If the system sees a lot of trade, why? More than likely it doesn't see much trade unless it is subsidized. What kind of job might someone be hired to do (and at what payment) to get something (or someone) transported there?, etc. . . .

 

[rlmercad069]

To take jump shadows into account is tougher math since you then have to choose the entry and exit points for jump. I think that the safest approach is to match velocities as best you can for the destination jump point so that you minimize risk and damage of impacting something on the other end of the jump. I can see other approaches like trying to minimize maneuver time or deliberately jumping in to a system with a high velocity in the new system for tactical reasons, but those would be riskier moves.

That's what the NAV skill is for.

 

[Grav_Moped]

That's what the NAV skill is for.

My take on nav skill is that you can fairly easily (as such things go) compute a jump originating from a specific point at a specific time -- hence, jump tapes. The task then is to get the ship to that point at that time.

It's harder to do that math "on the fly" so to speak. Extra variables.

On the other hand, once you shift the frame of reference to the galaxy or the universe as a whole, the ship's vector becomes a relatively minor variable, so maybe not.

 

[rlmercad069]

My take on nav skill is that you can fairly easily (as such things go) compute a jump originating from a specific point at a specific time -- hence, jump tapes. The task then is to get the ship to that point at that time.

It's harder to do that math "on the fly" so to speak. Extra variables.

On the other hand, once you shift the frame of reference to the galaxy or the universe as a whole, the ship's vector becomes a relatively minor variable, so maybe not.

Jump tables in the generate program is what is used to calculate jumps are for known routes and systems. One of the main jobs for scouts is to jump into systems to conduct surveys of less traveled ones to provide updates to the tables. The Scouts use task force fleets to roam the territory, near territories scanning for gravitic anomalies, plus remapping pulsars for jump table updates.

 

[mike wightman]

IMTU navigators carry a jump rutter. It is their journal of all the tricks and routes they learn about during their travels off the well mapped jump routes.
Things like calibration points, Lagrange jump entry points, strange anomalies, that sort of thing.

 

[Condottiere]

The difference being, they tend to drift in space, though maybe remaining relative to their system sun.

 

[rlmercad069]

navigators carry a jump rutter. It is their journal of all the tricks and routes they learn about during their travels off the well mapped jump routes.

I would think that should be standard. In one of the game settings private navigators can get a small stipend for access to their logs and up to 50KCr for detailed surveys from merchants but detached scouts in type S ships get the full 50KCr. I think I read it in T4, could have been T20, but not T5 or TG. But the money is only for area's not well travelled.