Jumping while underway

[phavoc]

I was thinking about this (again) the other day. Some of the aspects of jump in it's various forms has always bugged me. Sometimes it's too detailed,other times not enough. And with the various jump technologies that subtly change the different aspects of the act of jumping, I've always been on the lookout to make what's in the rules work, while also trying to put the natural pro's and con's of any act into this.

As it stands, you are supposed to retain your heading and velocity going into jump and out of it. So if you spent the last 12hrs boosting to your jump point at 1G you've got a lot of velocity built up. Being intercepted by pirates anywhere should be nigh impossible since they have no idea where or when you may emerge - and for them to retain their own velocity they've got to be underway as well - which means they'll always have to stop and turn around since they've cruised through potential areas to intercept someone. The rules say toss that out the window for intercepts because we'll just ignore the other rules we put in on another page. That, too, is annoying.

So to keep the system without breaking the system, I've come up with two ideas - the first is that ships CAN jump while underway with the downside that for every hour you've been under 1G thrush, your emergence point is 1million km off it's mark (it's a nice round number and high enough that any merchie is going to want to jump and emerge at rest so they don't incur a steep penalty in their arrival system). And, to make matters worse, not are off that distance, your angular entry point is random (meaning you could emerge heading away from your destination as well). The 100D rule remains in effect, so there's only a downside to all this. A by-product of this rule also means that any military ships would suffer the same penalty, so no making high-G sneak attacks by emerging at the 100D limit to blow past any defenders.

The second thing is space traffic control. Any planet with significant traffic has pre-defined emergence zones, say 50,000km by 50,000km cubes that navigators should be able to emerge within, but at zero transit velocity. There's 10km 'lane' between each zone to allow for ships to transit (like a taxiway) to larger lanes. The departing planet is assigned X number of slots that can be adjusted based on traffic patterns, and each departing ship is given the next available zone. Travel times remain no different than current rules.

Neither set of rules breaks any of the canon rules regarding velocity/heading or jump travel times. What it does break though is the rule that your ship velocity is reset to zero when encountering a pirate or some other interaction in space. That's a dumb rule that exists because they didn't think the encounter rules through and nobody has been willing to actually fix them in the many versions. It also brings a little order to the chaos I've always thought of with ships just randomly entering realspace. Sure, space is big at the 100D limit, but humans like to have accidents with each other whenever possible, and two starships slamming into one another due to surprise and inattention seems like a terrible way to end your day. Plus, the Imperium loves standardization and rules (plus bureaucracies) so it gives inbound and outbound systems something to do.

Somewhere I've got notes for the space traffic control that I might post if I can find them.

 

[rinku]

I think the space traffic control idea has a lot of merit. The convention is to jump in without excessive vector. That would just be a matter of common sense if jumping in to a small world anyway. Asteroid ports may in fact impose a legal jump limit.

With any jump, there's a practical incoming vector limit of the ship's ability to reduce it to allow interception of the destination. In simple terms, you would allow a ship to freely accelerate to a distance of 100D of the destination, then decelerate by that amount after jump.

Although it's a little more complex than that; when you want is to end up with that vector; you would accelerate to a midpoint closer to jump than the origin world. You could work out a table for origin and destination world sizes for each G rating and cross reference to get the times. Or spreadsheet it.

Or, space traffic control authorities, having had far too many cases of hotshot pilots misjudging it all, might simply impose "Jump at relative zero".

 

[phavoc]

I think the space traffic control idea has a lot of merit. The convention is to jump in without excessive vector. That would just be a matter of common sense if jumping in to a small world anyway. Asteroid ports may in fact impose a legal jump limit.

With any jump, there's a practical incoming vector limit of the ship's ability to reduce it to allow interception of the destination. In simple terms, you would allow a ship to freely accelerate to a distance of 100D of the destination, then decelerate by that amount after jump.

Although it's a little more complex than that; when you want is to end up with that vector; you would accelerate to a midpoint closer to jump than the origin world. You could work out a table for origin and destination world sizes for each G rating and cross reference to get the times. Or spreadsheet it.

Or, space traffic control authorities, having had far too many cases of hotshot pilots misjudging it all, might simply impose "Jump at relative zero".

I was trying to figure out a way to still have some interesting encounters. Jumping from a rest means slowing down (chance encounter in departure system), and arriving at rest means another chance for an encounter. It also means you could, in theory, stooge around in the dark knowing that ships from system A arrive in a general area, and ships from system B are usually not worth it (or, in reverse, target the lowly tramp freighters and not the bigger regular ones since pirates have a better shot at smaller, less defended ships - with a similar reduction in loot).

Piracy, or at least conflict, is a big aspect of the game. Otherwise you'd never be able to justify so many ships running around armed. At least in the outer portions of the Imperium. Core systems would be a bit different I think.

 

[boggo2300]

The way I've always looked at it it that Jump space has no momentum, so regardless of your vector going in it cannot exist in Jump Space, so when you re-enter normal space you have a vector of nothing.

 

[Condottiere]

1. I've always assumed that jump tapes allowed enough of a leeway, so that you have a window in time and space that allows jumping without penalty.

2. It just occurred to me, that when you do a turnover with some residual deceleration, that when facing ass backwards, exactly where that space rift is positioned.

 

[rinku]

Anyone can Referee it how they choose, but CT and TNE explicitly state that the realspace vector is preserved during Jump (in TNE it's even a feature, as manuever drive fuel use is not trivial). Haven't checked MegaTraveller proper, but I couldn't find any reference one way or another in SOM. But it's probably safe to assume that it's also the same.

SOM mentions that a jump plot needs to be for a very precise time and place, and the more that varies the greater the exit error is going to be, which makes total sense. So, yeah... a window, but a very narrow one.

Potentially a commercial jump tape, which could be generated using very large scale computing, could contain a range of plots wider than what a ship Astrogator using a ship's computer can manage on the day.

 

[Galadrion]

I would think that, since you retain your previous vector on emerging from Jump space, jumping with a significant velocity would be an unacceptable risk to most people. Sure, you're not going to emerge within a hundred diameters of a significantly sized object... but if you're moving at about 432 kilometers/second (roughly 12 hours at 1 G acceleration) when you come out of Jump and there's a hundred-kilogram rock too close to evade, that's going to hurt. Certainly, the chances of that happening are lottery odds, but unless you have a reason to be travelling that fast when you jump, why take the risk?

 

[MonsterX]

This has been discussed a lot on this board.

The issue is that all movement, all velocity, is relative to something. There is no universal frame of reference - all the stars you see are moving at an average of 100km/s, kind of generally mostly spinward (which is why it is called that) but not entirely. This is the kind of velocity that takes a ship some days to build up to. And their velocities and headings do vary, though they are kind of going the same way. The Milky Way itself is moving, as is the local cluster.

If you could somehow calculate a 0 velocity relative to the average speed of everything in the universe, you'd probably have a very large vector relative to whatever star you are jumping to - and therefore relative to its planets, which will likely be moving in orbit at 10s of km/s in orbit, but still following along with their start as well.

Therefore, you have a vector when exiting jump space relative to the star and its planets. There is no way around this problem, because if you try to solve it by saying zero vector - it only means you have to decide zero relative to what, since everything is always moving relative to everything else.

The only question is: what is that vector? What factors influence it? To summarize the discussions' conclusions there are the possibilities:

1. a new vector somehow derived from the new location you are in (i.e. from the objects there - such as the object whose 100d limit you hit). This is closest to the assumption of zero vector - since you start with the same vector as the object you are heading toward. It also raises the question of: what if there is no local object, like if you jump into the outer system? But it does solve a lot of game problems. It also means there is no reason to slow down (or speed up) when entering jump, since the vector will be nullified anyways.
2. it the same vector you had when entering jump space. This is an elegant solution which however makes it so that ships can and should manipulate their exit vector to their advantage - whether tactical, if going for combat, or commercial, in terms of saving time to destination. It however raises the problem of variable stellar velocities, which we don't know (this is fixable, as we can find out or make them up, but it is a thing to keep track of for not much added value to the game unless it is a plot point), which as mentioned are really significant.

Safety for collisions is not really a concern given the size of space outside the 100d limit (it would be closer in), and would not really be solvable by zero vector if it were since there is no such thing as zero vector. Terrorism is a concern for solution #2.

For my money, solution #2 is better and I resolving the stellar velocities problem just by not thinking about it - it is all abstracted most of the time into the Astrogation roll which determines the time to destination in the target system; I figure most of the time most of the stars are going in more or less the same direction at the same speed, kinda, ish, and like with planetary orbits etc. they just take a little more or less time based on the die roll. This is unless it is needed for a plot point, such as PCs using it for strategic advantage or PCs will having to reckon with large stellar velocities for a fast star: there are some really fast moving stars out there. But solution #1 does solve the terrorism question, which, if you have nasty players, might crop up.

 

[Condottiere]

If you're moving, and the universe is moving, then the exit point is likely a moving target.

 

[Nelphine]

I like to do "you keep the relative velocity that you had compared to the star you left, but now applied to the star you come out near"

So I don't need to bother figuring out any relative velocities between the two stars - they never get compared. If I was going 100kph spinward of the star I was leaving (even if that's 200kph compared to say, the galactic center), then when I leave jumpspace, I am now going 100kph spinward of the star I am arriving at (even if I'm in the new stars oort cloud, and even if this makes me going 700kph core ward compared to the galactic core.)

If there are multiple stars,it doesn't matter - I was still aiming at a given star, so its relative to that star. If there are no stars (edit: and only if there are no stars) within a parsec, then it's relative to either the nearest large body (planet, comet, whatever I aimed at), or an arbitrary patch of space (if it was a mistake like a misjump or I otherwise wasn't aiming at anything.)

 

[rinku]

Your exit vector will still be relative to the origin system, but in practice you can treat the origin and destination system as one frame of reference anyway. They're gravitationally linked and quite close in interstellar terms.

In almost all cases the nearby star you're jumping to only has a relatively small delta vee to the star you jumped from. They may even be close to net zero, since most likely they are orbiting the centre of their galaxy and headed in roughly the same direction, at roughly the same speed. As a concrete example, Alpha Centauri has a relative velocity to Sol of about 22 km/s.

The relative velocities of the origin and destination planets are likely to be a much bigger consideration, but again, the velocities are manageable even with a 1G drive. Earth has an orbital velocity of roughly 30 km/s. It takes a 1G ship less than an hour to match that, even if started at relative zero.

If an Astrogator can line things up well and the jump goes where it's meant to, the ship vector on entry will be a useful exit vector. But it also makes sense that there would be regulation regarding maximum velocity, at least in civilised space, and that that might vary from port to port.

As a point, I've seen nowhere that the realspace vector has to match the jumpspace one. Your ship might set up a final departure vector heading away from the destination system, in order to be heading in the same direction as the destination planet, but have a jumpspace vector going in the opposite direction.

 

[Geir]

You could just say when you come out at 100D, you "bounce" ("crunch?") off the gravitational handwavium and come to a complete stop relative to the object you "hit". In most cases this will be the planet you're heading to and you can do the standard turn-over calculation (that the chart is based on) and call it good.

If you're dealing with 100D from the star and have to drive into the system over the course of days, then whatever turn-over velocity you reach is going to be so large relative to the orbital motion of the world that it will be a rounding error (well... maybe not in the habitable zone around a white dwarf, but that's an outlier and if you use 100D for the star and not something related to its mass, then the planet is likely bigger than the star and the 100D of the planet is still the answer).

Since all FTL is 'cheating' then it doesn't really matter what you do, as long as its consistent. But coming out a zero velocity compared to the planet makes it a lot simpler and prevents any version of the relativistic kinetic jumpship planetkiller from being a thing.

 

[rinku]

Further thought... in many cases jumping at zero will still result in a closing vector relative to the destination world, if you emerge at 100D ahead of its orbit.

For the most part, this is all just colour detail anyway, like how many seconds it actually takes to dock or what the actual vectors are in 3-Space terms. It's sufficient to discuss and acknowledge that they exist, maybe browse a text on basic space stuff, and then get on with the game. In other words:

There's a bunch of things that need to be accounted for with jumping from world to world, but the Astrogation roll takes them all into account.

For the vast majority of cases, it's sufficient to calculate 100D travel as arriving at zero velocity from origin world, then calculate 100D to destination world the same, by default. That closely emulates what might need to be done to fly more efficiently, meet local speed limits etc.

If players really, really want to jump with an excessive vector, let 'em. Then explore the consequences of that decision with them

 

[rinku]

You could just say when you come out at 100D, you "bounce" ("crunch?") off the gravitational handwavium and come to a complete stop relative to the object you "hit". In most cases this will be the planet you're heading to and you can do the standard turn-over calculation (that the chart is based on) and call it good.

If you're dealing with 100D from the star and have to drive into the system over the course of days, then whatever turn-over velocity you reach is going to be so large relative to the orbital motion of the world that it will be a rounding error (well... maybe not in the habitable zone around a white dwarf, but that's an outlier and if you use 100D for the star and not something related to its mass, then the planet is likely bigger than the star and the 100D of the planet is still the answer).

Since all FTL is 'cheating' then it doesn't really matter what you do, as long as its consistent. But coming out a zero velocity compared to the planet makes it a lot simpler and prevents any version of the relativistic kinetic jumpship planetkiller from being a thing.

Yeah, I don't mind that idea. I'm already in the camp that arriving at a planet with any real precision is unlikely, so making it that you can only aim at a significant gravity well in order to arrive anywhere near it works for me.

In regard to stars, either hit the 100D or arrive roughly at the outer orbit range you chose.

If you come in too hot, you'll wave goodbye to the destination world in the rearview mirror...

 

[Condottiere]

Styles of calculating jumping may actually vary.

The two that I can think of is:

1. Dead reckoning - you know exactly where you want to exit, and you calculate backwards to the point you want to jump from.

2. Yardstick - you're not quite sure where you'll end up, except in a spherical error of probability, but dial in an absolute distance to be travelled before exit.

 

[rinku]

Sounds good. Most of the above can happily live together too. If you're not fussed about precise location and just need to jump to roughly between Mars and Earth somewhere, that's where you go, without margin of error being a major factor. If you need to be at 100D, aim at centre of object and use the jump shadow to pop you out.

 

[MasterGwydion]

Sounds good. Most of the above can happily live together too. If you're not fussed about precise location and just need to jump to roughly between Mars and Earth somewhere, that's where you go, without margin of error being a major factor. If you need to be at 100D, aim at centre of object and use the jump shadow to pop you out.

That has always been My idea of how to always hit at exactly 100D. Aim center mass and then you automatically pop out at 100D, no muss, no fuss.

 

[Condottiere]

When in doubt.

Though, I would think that may shake loose some nuts and bolts.

 

[Fluffy Bunny Feet]

I think if I ever get to GM Traveller I'll if asked why velocity 0 on jump that it is less likely to introduce errors by relativistic effects when moving at high velocities causing a mis-jump and if they insist on doing so they WILL have that mis-jump to keep it from being a regular thing. Don't want them to cut their travel time too much by figuring the total distance at each end and jumping at the halfway mark. Not to say it would fail the roll every time but at least once early on they would find the dice definitely go against them just to break the habit early.

 

[Condottiere]

With fleet astrogation, you can send a picket (star) ship ahead of your more important units, so they hit oncoming traffic first, like a snow plough.