Acceleration times

[Leitz]

The question comes from a few scenes for stories and games.

In one, a non-jump capable old Merchant Marine ship was tasked to move to where a belter distress call came from. No data besides "belter called for help, and then got cut off." How fast could the ship get to within scanning range?

Ship gets there and there's a huge warship ship of unknown origin. The system defense fleet is enroute, but they have no data to plan around. They stay in realspace while the merchant scans and sends back data. The fleet wouldn't want to jump close because they don't know what weapons and defenses the warship has, and they lose comms during jump so can't plan their attack.

A small pirate fleet attacks a merchant. The first pirate or two does a fly-by and engages quickly, trying to disable and dishearten the merchant. The rest of the pirate fleet comes in controlled, and takes the merchant ship while the fly-bys decelerate and return.

Taking that a step further, you could do a fly-by and likely engage with long range weapons multiple times as you flew by. You could also dump guided missiles and be out of the danger zone before they hit. Even if the enemy did hit your ship, velocity would soon take you out of range.

Different scenario when a ship is crossing your path and you need to accelerate to match velocities as you try to follow them.

So, the assumption that you need zero velocity at the destination is an assumption.

 

[whartung]

How is this typically done in practice in most games?

Well, first, there's no Calculus in any of my gaming...

Second I was using 12,000km as Earth diameter.

But my base assumption is that these are travel times from orbit, where the planets force is effectively nullified. It's certainly nowhere near enough to counter a 1G drive. Given everything else, it's mostly noise in the equation. If you're worried about getting in to orbit, then the games already over. The intruder can make your ascent very, very difficult. Not only are you a sitting duck in a gravity well, you also now have dense, high velocity atmosphere to tear off those irregular shapes pieces of hull the intruder is going to start turning you in to.

In the end, you're looking for rough numbers that in the end are represented by either hexes moved, or game turns, depending on your system (1000s for B2, 100 minutes/6000s for Mayday, 30m/1800s for Brilliant Lances).

This is why I suggest Mayday for Merchants, intruders get far fewer shots in.

 

[AnotherDilbert]

How is this typically done in practice in most games?

Not at all, of course. Neither is jump masking usually considered when calculating a course.

But you are correct: Gravity should be considered when accelerating from/to a gravity source.

 

[mike wightman]

This is why I suggest Mayday for Merchants, intruders get far fewer shots in.

Each hit in Mayday is the equivalent of a LBB2 critical hit, and if you take 4 or more hits in a single turn you are destroyed.

A laser causes 1 hit, a proximity missile 2 hits, and a contact detonation is 3.

 

[whartung]

Each hit in Mayday is the equivalent of a LBB2 critical hit, and if you take 4 or more hits in a single turn you are destroyed.

A laser causes 1 hit, a proximity missile 2 hits, and a contact detonation is 3.

Well, in the end, it's either fait accompli, or it's not.

I've not gamed it, obviously it depends on the intruders ship.

But if the result is borderline, then the fewer turns give more chance for a spiky outcome and the dice set you free. With more turns, the curve is smoother and that may well doom you.

I mean, look at Mayday.

The "game" is to get the ship 4-5 hexes away from the planet. The hex sizes are pretty big. You'd have Earth in one hex, and the Moon on another. Interlunar space is "pretty big".

The intruder is most likely going to be parked in that interlunar space, not 10 hexes away in deep space.

If there's a patrol there, then the patrol is going to fire on the intruder that's firing on the trader. The trader is running to jump, and either wins or dies, but the intruder and the patrol are in for the long term, so that's a fight to the death.

If the intruder prevails, then there's no more patrols, so they'd be parked in interlunar space before chasing and making 2 hex range pot shots at the trader until it jumps or surrenders.

If there are patrols, then the intruder may just think twice about it. He pretty much has to disable the patrol to take on the trader. In that case, there's likely no combat at all.

So, either way, it's a brief contact, at close range.

 

[sudnadja]

Not at all, of course. Neither is jump masking usually considered when calculating a course.

But you are correct: Gravity should be considered when accelerating from/to a gravity source.

Book 2 as written actually doesn't do an awful job of approximating gravity. Here's a flyby of a size A world across 4 turns with dots-and-arrows representing traveller rules and the blue line representing continuous gravity. The ship starts with a relative velocity but does not accelerate other than by gravity in these turns.



I think the intention as of Book 2 was that gravity should be considered.

(edit: though I suppose orbits aren't particularly stable given what is effectively a fixed time step integrator with no error control:

 

[AnotherDilbert]

Book 2 as written actually doesn't do an awful job of approximating gravity.

But as your previous example showed, over a long time, especially in a low gravity field that LBB2 ignores, the discrepancy is quite noticeable.

I think the intention as of Book 2 was that gravity should be considered.

Absolutely, but we can hardly expect the normal gamer to integrate gravity acceleration over a course.

(edit: though I suppose orbits aren't particularly stable given what is effectively a fixed time step integrator with no error control:

I suspect we can get a stable orbit, at least if the gravity bands allow, but it will be at a different height/speed.

 

[sudnadja]

I suspect we can get a stable orbit, at least if the gravity bands allow, but it will be at a different height/speed.

I can't immediately come up with one.

with a fixed timestep integrator like the LBB rules are, you'll want the lowest speed possible to give the least distance between position updates possible. To be in orbit at all in LBB, the ship would have to be inside the 0.25 gravity band and it can't be too close to the edge of it, because the rules say that gravity is computed at the midpoint of the vector to the next turn. If the turns were shorter than 1000 seconds or gravity bands had more granularity than 0.25g, or both, it might be possible.

 

[aramis]

Note that one can go to subscale maps... if you make each hex 1/5 the distance, and a turn's allowed accelleration to be broken into 0.2 G-Burns, a 15-hex subscale map covers the planet and its surrounding 6 full-scale hexes. Note that you need to NOT change the time increment for this to work. Change the time increment, and you have to recompute a lot more.

Subscale maps are only needed for near planet operations, and to not rotate the grain, need to be an odd number of hexes. (Even numbers rotate the grain 30°, and thus require even more jiggery-pokery.)

 

[sudnadja]

I suspect we can get a stable orbit, at least if the gravity bands allow, but it will be at a different height/speed.

Only from curiosity at this point, for 100 second turns it is possible to place an object into orbit with otherwise unmodified LBB 2 rules - however, the orbit is not stable and does not conserve momentum. This with 400 turns executed:

 

[sudnadja]

Note that one can go to subscale maps... if you make each hex 1/5 the distance, and a turn's allowed accelleration to be broken into 0.2 G-Burns, a 15-hex subscale map covers the planet and its surrounding 6 full-scale hexes. Note that you need to NOT change the time increment for this to work. Change the time increment, and you have to recompute a lot more.

Subscale maps are only needed for near planet operations, and to not rotate the grain, need to be an odd number of hexes. (Even numbers rotate the grain 30°, and thus require even more jiggery-pokery.)

I'm not sure if this was in reference to my comment and example, but LBB2 does not use hexes at all for starship combat, it is a "flat surface and ruler" setup, so scaling hexes won't be useful as there are no hexes to scale.

 

[AnotherDilbert]

I can't immediately come up with one.

Since LBB2 reduces it to simple geometry, can't we find a geometric solution?

We want a vector such that a, say, 0.25 g acceleration will only turn the vector, but not change the length or radial angle from the planet.

We seek the angle and length of the orbital vector, and we know the angle and length of the gravity acceleration vector; two constraints for two variables, this seems doable.

I'll see if I have time to solve this tonight.

 

[sudnadja]

Since LBB2 reduces it to simple geometry, can't we find a geometric solution?

We want a vector such that a, say, 0.25 g acceleration will only turn the vector, but not change the length or radial angle from the planet.

We seek the angle and length of the orbital vector, and we know the angle and length of the gravity acceleration vector; two constraints for two variables, this seems doable.

I'll see if I have time to solve this tonight.

I know you're trying to reduce the vectors to those perpendicular with each other, but keep in mind that the gravity vector is determined at the midpoint of the (non-gravity) vector, not at the end, and in the direction toward the gravity source at the midpoint. The length of the vector is determined by the band it is in.

 

[whartung]

Since LBB2 reduces it to simple geometry, can't we find a geometric solution?

That's not the problem.

The problem is simply one of resolution.

At a 1000 second time scale, you "can't" do a proper orbit capture. The net effects on the vectors are too gross.

When the higher resolution effect was demonstrated, you got a much better orbit display, though, still, the coarseness of it was its downfall.

That math is all fine, it's how often it is applied that's the problem.

The game resolves this by having the player say "this is in orbit" and voila, "orbit".

 

[sudnadja]

When the higher resolution effect was demonstrated, you got a much better orbit display, though, still, the coarseness of it was its downfall.

The variable time step RK integrator generally uses around 150-200 seconds between timesteps in this situation, but it is also "smarter" than straightforward Euler integration.

There is another problem, in that the gravity range bands have the effect of quantizing gravity, effectively making the planet that is being orbited around variable mass, but energy of the ship isn't scaled appropriately to account for that.

I think the game solution of "it's in orbit" is the only real compromise available unless you presume computer support. Even the question of "which orbit" is not obvious, I think the naive approach would be to compute kepler elements based on the position and velocity (state vectors) at the time that the player says the thrust stops, but then do you use the gravity band-based mass for the world or what the mass really would be? I don't remember and don't see in Book 2 how ships should move once they are declared to be in orbit.

 

[AnotherDilbert]

I know you're trying to reduce the vectors to those perpendicular with each other, but keep in mind that the gravity vector is determined at the midpoint of the (non-gravity) vector, not at the end, and in the direction toward the gravity source at the midpoint.

The grav vector is not added AT the mid-point, it's added IF the mid-point falls in the grav band. But, yes parallel to the radius at the mid-point, so my sketch above is incorrect.

Btw, no two vectors in my sketch are perpendicular.

 

[AnotherDilbert]

I think the game solution of "it's in orbit" is the only real compromise available unless you presume computer support.

Yes, of course.

Even the question of "which orbit" is not obvious, I think the naive approach would be to compute kepler elements based on the position and velocity (state vectors) at the time that the player says the thrust stops, but then do you use the gravity band-based mass for the world or what the mass really would be?

Way to much work to actually use. Just say "low" orbit or "high" orbit, if even that is necessary.

With Traveller drives, going to orbit is fairly trivial, at least with 2+ G drives.

Within a turn just say "I park in orbit" or "I land", if you can achieve close to matching the position and velocity of the planet..

 

[AnotherDilbert]

At a 1000 second time scale, you "can't" do a proper orbit capture. The net effects on the vectors are too gross.

I think we can find AN orbit with the LBB2 system, but it won't be the correct orbit.

The game resolves this by having the player say "this is in orbit" and voila, "orbit".

Agreed.

 

[sudnadja]

I think we can find AN orbit with the LBB2 system, but it won't be the correct orbit.

It isn't guaranteed that we can. We would never be able to find an orbit around Earth if we were integrating with a million year timestep, for example, if we are limited to 0.25g as the outer band. At what point does the timestep become small enough that an orbit is possible with Euler integration? I think it's going to be smaller than 1000 seconds, but I'm not sure how to go about proving that.

 

[AnotherDilbert]

It isn't guaranteed that we can. We would never be able to find an orbit around Earth if we were integrating with a million year timestep, for example, if we are limited to 0.25g as the outer band.

For any reasonable scenario, yes, obviously, but then we have left LBB2 far behind...

At what point does the timestep become small enough that an orbit is possible with Euler integration? I think it's going to be smaller than 1000 seconds, but I'm not sure how to go about proving that.

A positive example would be an easy proof. It wouldn't find the exact cut-off.