Jumping at velocity?

[nats]

When a ship jumps does it do so at velocity or standing still? I ask because in Book2 it states that a ship accelerates, turns around mid point in the journey, and then decelerates. But surely if it was jumping at the 100 dia point it wouldnt need to decelerate it could just keep accelerating and then jump which would make the initial journey much shorter.

But then when the ship enters a new system after jumping would it retain its initial velocity or would it start off still, if it had an initial velocity before it jumped? If it had retained its initial velocity it would almost certainly be going the wrong direction and have to turn around which would make this part of the journey far longer than if it was still after it had jumped in. But if it was always still after it had jumped it would be easy to point to the correct vector and start accelerating to the main world.

So in summary the questions is:
Does a ship retain its inital velocity after a jump or is it completely still after it jumps no matter what its initial velocity was?

I suppose it might be simpler to always assume that a ship normally accelerates, turns around, and then decelerates, no matter what the journey end is. But if you were being chased it might be worth while not bothering with the turn around and deceleration phase before the jump, and taking a risk jumping at velocity. Could incur some increased risk of a misjump possibly?

 

[dean]

Don't happen to have my books here at work with me, but a ship may and usually does jump with velocity, and the ship retains the velocity and vecotr that it had when leaving one system and entering the next and j space exit.

The jump calculation takes into account the relative positions of the moving bodies and can place you in the system beyond the 100 D limit on reentry so your vector is appropriate for plantary approach.

The accelerate-flip-negative accelerate process is used for point to point travel within a system.

Of couse, at jump exit the ship would typically have to slow down to arrive at the intended destination with zero relative velocity, so it actually applies regardless, with a visit to jump space in between.

 

[D. Foxx]

The accelerate-flip-negative accelerate process is used for point to point travel within a system.

Isn't travel to a 100d jump point considered point to point travel within a system?

Since the rules don't provide the formulas for straight on acceleration, with no turnover for negative acceleration, I would think you would have to assume 0 velocity to 0 velocity travel to the Jump point...enter jump...exit jump...0 velocity to 0 velocity travel to planet.

The the formulas in LBB2 are derivied from the acceleration formula -

T = sqrt(D/.5A)

It is modified for the 0 velocity to 0 velocity travel by halfing the distance then doubling the result which gives you the formula -

T= 2*sqrt(D/A)

Now this is just my interpretation of the rules as presented in LBB2.

In MTU I use:

On entering jump - zero relative velocity to the primary you are departing.
On leaving jump - zero relative velocity to the primary you are arriving at.

It's all part of the astrogation/ploting required, the jump software for executing the jump, and a function of Jump Space in which the ships travels

 

[rancke]

I assume that it's a simplification for game purposes. What the ship actually does is accelerate and then decelerate until it achieves a neutral vector vis-a-vis the destination world. However, for ease of game play, the rules make it the departure world instead.


Hans

 

[BytePro]

The rules really don't cover it.

'Point to point' for in system objects is even silly, since the destination would almost never be at the same 'speed' as the departure...

Traveller ironically, has very little mechanics to actually cover inner system space travel.

CT had basically the mid-point turnaround formula - though I recall MT/DGP had some orbital stuffs - I had my own back in CT days (when I also create my first 3D TU...).

 

[D. Foxx]

Like Rancke2 said,

I assume that it's a simplification for game purposes.

To try to compute just in system where everything is, how fast everything is moving, and how long it would take to get there! o:
Then compound that by tracking the same items for a system 2 parsecs away.:rofl:
LBB2 rule are greatly simplified for game mechanics. The story should be the key for the players not whether or not the game mechanics are close enough to real science to be believable.

 

[whartung]

Like Rancke2 said,



To try to compute just in system where everything is, how fast everything is moving, and how long it would take to get there! o:
Then compound that by tracking the same items for a system 2 parsecs away.:rofl:
LBB2 rule are greatly simplified for game mechanics. The story should be the key for the players not whether or not the game mechanics are close enough to real science to be believable.

It's not as if any of this is actually difficult.

If you assume that all of the star systems have some basic trajectory tied to an external reference point (perhaps the galactic core), then it's straight forward to compute a differential vector that a ship would need to have to achieve whatever vector it desired in the destination system.

Just like the navigational charts and survey can tell the ships navigator the orbital dynamics of all the charted systems. That way it's pretty easy to know where all of the main bodies of a system are now, where they will be "in a week", and using that information to decide where you want the ship to arrive, and what vector it should have once it arrives in system.

Ideally you want to pop in to the system close to the 100D mark in a leading orbit position of the destination world. That way you can leverage the orbital velocity of the planet to have a shorter trip inward (since the planet will be heading toward the ship).

Obviously you don't want to subject the players to this, but assuming that an astrogator and a computer can't readily plot this doesn't seem to make sense. It's pretty simple math easily corrected with a 1G drive.

 

[far-trader]

It's not as if any of this is actually difficult...

Except that canon states jump precipitation is random in both time (+/- many hours) and coordinates (x/y/z presumably by 1 thousand(?) km per parsec) which means all your careful plotting and calculations are pointless if not dangerous.

And misjump can be even worse for time effects.

I can live with misjumps being random and really screwing up your carefully plotted vector of economy or speed. I don't accept that successful jumps are at all random.

The random rolls for time and distance imo is a meta-game simplification to express the variability of each jump. And I usually ignore the distance one as pointless and insignificant.

As well imo the travel time tables are a meta-game simplification of the time it takes to chase down another planet in a normal space trip, or the time it takes to reach safe distance and compatible vector prior to jumping.

It works for me, much better imo than the official version.

 

[rancke]

If you assume that all of the star systems have some basic trajectory tied to an external reference point (perhaps the galactic core), then it's straight forward to compute a differential vector that a ship would need to have to achieve whatever vector it desired in the destination system.

Just like the navigational charts and survey can tell the ships navigator the orbital dynamics of all the charted systems. That way it's pretty easy to know where all of the main bodies of a system are now, where they will be "in a week", and using that information to decide where you want the ship to arrive, and what vector it should have once it arrives in system.

This is what the astrogator would do in "reality". But we're not astrogators. We're gamers playing at being astrogators. As such, there's a really low limit to how much tedious calculation up with which we're prepared to put.

Ideally you want to pop in to the system close to the 100D mark in a leading orbit position of the destination world. That way you can leverage the orbital velocity of the planet to have a shorter trip inward (since the planet will be heading toward the ship).

But since the jump uncertainty can place you anywhere from in front of the planet to the back of it, your optimal arrival vector is neutral with respect to the destination world.

Obviously you don't want to subject the players to this, but assuming that an astrogator and a computer can't readily plot this doesn't seem to make sense. It's pretty simple math easily corrected with a 1G drive.

Who is assuming that?`I was explicitly assuming the opposite.


Hans

 

[aramis]

CT had basically the mid-point turnaround formula - though I recall MT/DGP had some orbital stuffs - I had my own back in CT days (when I also create my first 3D TU...).

The Hohman Transfer Orbit was mentioned in SSOM by DGP, not actually in the GDW MT rules themselves... tho' most MT players consider DGP to be canon for MT anyway. (I sure do.)

 

[Icosahedron]

It's not canon, but I make all arrivals zero velocity with respect to the local gravitational field. If you arrive near a planet you're zero wrt the planet, if you arrive way out between worlds you're zero wrt the star. Maybe Jump Space absorbs residual velocity. It's a handwave that stops a lot of messing about. There's a thread somewhere around here where I argued it all through.

 

[samuelvss]

IIRC, there are a few threads that touch on this.

The possibilities, as I reckon:
1. First, the vector could be the same entering and exitting jumpspace, relative to the entrance gravity well; this could still provide HUGE differences on exit, as the destination/exit gravity well would likely have a significant delta-v from the entrance gravity well.

2. As per Icosahedron, above, the exitting velocities must be zero relative to the gravity well.

3. As 2, but the entering velocity must be zero relative to the entrance gravity well.

4. As per 1, but anything above .2 c adds a chance of misjump.

5. A large vector is possible entering, and maneuver can be had / adjusted within, jumpspace, and this is a major astrogathional function, to get a safe (and legal?) approach vector on exitting jump.

6. As per 5, but anything above .2 c adds a chance of misjump.

7. As per 5., but the delta-v of the entrance and destination/exit gravity well must be compensated for, within or without jump space.

8. As per 7, but anything above .2 c adds a chance of misjump.


Note that the difference between maneuver prior to entering jumpspace and after exitting is doubled in 2 and 3 is a doubling of travel time to/from the 100diameter limit over 5. Possibility 1 would, potentially, have the largest travel times, because maneuver would have to not only have to reach to/from the 100d limit, but in the process also makeup for the delta-v of the entance gravity well and destination/exit gravity well. Option 5 allows some neigh-unto insane tactical maneuvers.

IMTU I use option 8; I used to use 5, until a previous thread on Coti got me thinking a few years ago. For game purposes, under 8 one just figures the one-way travel to the 100d limit, but the Navigator can have an important function, especially if there is one ship "chasing" another into / through jumpspace. Here, the pursuer has to guess, as the Hood did about the Bismark's route out, where the destination is going to be, but the navigation makes for some more variables, as diverse exit vectors are possible.

 

[Xerxeskingofking]

I always understood that a ship moving though jumpspace conserved any momentum. you enter jump travelling at X meters a second, then you leave traveling at the same X meters a second. if pressed for a direction, I'd say in the direction directly away form the jump entry system, whichever that direction is relitive to the exit system.


The "slowing to (near) stop" before a jump thing is, to me, a safty feature, as you didn't know what was at the far end, and entering system with a large inbound velocity was a quick way to suffer a collision with something not on the charts.

 

[mike wightman]

Now that's made me think.

I don't recall any rule that your vector on entering jump space has to be pointing at the destination system.

You could, IIRC, burn away from your destination system and still make the jump.

Some interesting possibilities there

 

[whartung]

Except that canon states jump precipitation is random in both time (+/- many hours) and coordinates (x/y/z presumably by 1 thousand(?) km per parsec) which means all your careful plotting and calculations are pointless if not dangerous.

So? These affects are simply considered in plotting your destination. Consider such discrepancies as "Minutes of Jump" when "aiming" for your target. A few thousand kilometers and a potential window of 30ish hours is not really a big window all things considered. A 1G drive is REALLY fast, and makes compensating on arrival not that much of a big deal. The window can offer exciting opportunities when some countdown is happening, but that's not a normal event.

Consider the jump window the same as the security line at the airport, you simply have to plan around it. It's routine and no big deal.

And misjump can be even worse for time effects.

I can live with misjumps being random and really screwing up your carefully plotted vector of economy or speed. I don't accept that successful jumps are at all random.

Pretty hard to plan anything around a misjump or its consequences.

 

[whartung]

This is what the astrogator would do in "reality". But we're not astrogators. We're gamers playing at being astrogators. As such, there's a really low limit to how much tedious calculation up with which we're prepared to put.

No, we're not astrogators, but that doesn't mean we can't simply say "make it so" and have it happen, because that's what an astrogator and the computer can do.

But since the jump uncertainty can place you anywhere from in front of the planet to the back of it, your optimal arrival vector is neutral with respect to the destination world.

It only puts you on opposite side of the planet if you happen to plot it that way. If you're plotting that way you're just as likely to "land" within the 100D limit, which would possibly be a Bad Thing.

So, Don't Do That. You need to pick a vector to get away from your current station in order to reach the 100D. If you simply want to get out of the 100D as quick as possible, you aim towards a trailing position of the planet orbit so that you race away from each other and reach the 100D just that much faster.

My assumption is that Jump lets you put your ship at any 3D coordinate in space. Wherever you want to end up, that's where you end up. Your vector stays constant. If you're heading "north" when you jump, you're heading "north" when you exit. Where you exit is up to you. The jump window affects when you exit and where all of the other little floaty bits in space are in relation to you (like planets). The Jump changes your coordinates, not your vector.

It's the astrogators job to optimally balance that exit point, the time factor, that vector, the destination they're ultimately heading for, and ship resources (fuel notably) to make the trip as efficient as practical. They have to take in to account the random jump window. But that's a probability game.

A wiley astrogator may be to able to adjust that vector so that when they arrive from jump they just so happen to be pointing at their destination so they can conserve that acceleration and fuel from the exit rather having to do it all from scratch again.

A "zero" vector relative to the originating systems primary may likely not be a zero vector in the destination system. You leave System A at "velocity 0" but arrive at System B at velocity X, direction Q because of the relative differences between the systems.

Again, wiley navigators should be able to manage all of that for you. In fact, the computers should make this exercise trivial for your navigator and propose optimal vectors, because the computers and the star charts know all of these details and take in to account all of the variables (including the jump window).

So, the best option is to buy a better computer, or hire a better navigator and let those provide a better chance on have everything happen "just right" to make the trip as efficient as possible.

Meanwhile Captain Player says "make it so" or points his mouse at the "Regina" icon, right clicks and selects "Jump Now" on the bridge control panel, and lets magic happen.

 

[rancke]

It only puts you on opposite side of the planet if you happen to plot it that way. If you're plotting that way you're just as likely to "land" within the 100D limit, which would possibly be a Bad Thing.

It's not a bad thing. The ship just precipitates out safely at the jump limit, the closest it is possible to arrive to a destination world.

So, Don't Do That. You need to pick a vector to get away from your current station in order to reach the 100D. If you simply want to get out of the 100D as quick as possible, you aim towards a trailing position of the planet orbit so that you race away from each other and reach the 100D just that much faster.

Say that you're aiming for a world that moves 200 plantetary diameters in 30 hours. So you aim for where the world will be in 168 hours. If you arrive in 153 hours, you'll be at the jump limit right in front of the world, right where it will be in 15 hours. If you arrive in 183 hours, you'll be at the jump limit right behind the world, where it was 15 hours ago. If you arrive at any time between 153 and 183 hours, you'll hit the jump limit and be precipitated out, somewhere along a semi-circle with a 100D radius around the world.

In all these cases you arrive somewhere along the jump limit. Only if you arrive more than 15 hours early or more than 15 hours late will you be further away than 100D. Assuming jump variation follows a bell curve (as I do), you'll arrive at the jump limit most of the time -- often enough to have the game rules simplify it saying that you always arrive at the jump limit.

But you can't know exactly where along that semi-circle you will arrive, so any vector you have relative to the destination may be taking you in the wrong direction.

My assumption is that Jump lets you put your ship at any 3D coordinate in space.

With an accuracy of +/- 1000 km per parsec, yes. And provided you don't get precipitated out at an intervening jump limit.


Hans

 

[mike wightman]

I wonder if the jump time is actually a known quantity that the jump program generates when it plots the jump.

It could just be our misinterpretation of the wording in the rules?

 

[far-trader]

I wonder if the jump time is actually a known quantity that the jump program generates when it plots the jump.

It could just be our misinterpretation of the wording in the rules?

I'm gaining! I knew if I repeated my lies often enough someone was bound to start questioning the truth :devil:

...but seriously I seem to recall a Q&A or some such where Marc Miller clarified that it was a random effect in the reality of the game. Ships really do drop out of jump with only a vague idea of where they are and enter jump with the same vagueness of when they'll get there. Though it is contrary to at least one bit of (semi-)canon lore, from SOM (and istr some elsewhere) about knowing you've misjumped when the countdown clock passes the anticipated time of jump precipitation, or you drop out before the anticipated time.

 

[BytePro]

IMTU vector does not change, but also is indicative of the actual destination system... so it 'points' to where you are going. This makes jump 'tracing' pretty easy - something I prefer for RP.

You can choose to arrive in-system to destination, or out-system, above or below ecliptic, etc.

However, I have a 3D version - my systems have a +/- Z axis

This also determines the actual time (I have a formula). All systems have essentially zero relative velocity to each other (handwave that removes that big glaring issue), but I do handle orbits - since they are, like 3D, a must for 'believability', IMO and add a lot to the RP ambiance.

Since jump space seems to interact with gravity, I do have random arrival diameters which skill can influence.