#61 Minimum warp to try (autopilot)

[Turbo Beholder]

So that autopilot won't turn the shield off for no gain at all, now it checks how much SPEC can actually help at the moment and doesn't try it until the achievable warp rate reaches the threshold.
Confvar added: AI/"min_warp_to_try"[float] = "1.25"

Also, cleaned up some directly related mess.

[Turbo Beholder]

(2.0) oopsie, that was relative to vegastrike/src/ - this one is relative to vegastrike/
(3.0) Another improvement.
ASAP tend to miss the destination because it predicted travel time based on non-warp speed and didn't consider rampdown time at all. Here's a pessimistic estimation.
Also, bumped the default minimum of warpfield to 1.5 because this at least allows to get better warp noticeably faster, so 2 may be mixed blessing and 1.25x speed usually is still not worth discarding the shield.

[Klauss++]

So it's like it's a shield-eating overdrive. Will test a bit.

[Klauss++]

Seems to work very nicely. Although it does make approaching places slower (rampdown is quite slower). Was this intentional?

I'm OK with it if it was. It's in line with all the stuff we've been talking about SPEC, and we can make it faster later.

[Turbo Beholder]

I forgot to mention the important part: this makes autopilot handle warp better assuming it works correctly in the first place. Now that [patches:#63] is accepted, should be fine.

Although it does make approaching places slower (rampdown is quite slower).

Rampdown starts where we should do it if we want to avoid skipping the target (i.e. not too late to drop from current warp-adjusted speed)... except with afterburner speed instead of basic and it doesn't consider finer points of deceleration (fixed). This may need more fine tuning, too.

Also, in most situations min_warp_to_try shouldn't stop warp due to interdiction by the target because either rampdown time condition or distance to target will kick in first, but this also may be triggered by 3rd-party interdiction (chase, etc). Do we need separate "min_warp_to_try" and "min_warp_to_keep"?

Edit: "AI" is cluttered and also covers AI things; perhaps autopilot-behaviour-specific things need moving into to "auto_physics" namespace (together with blastoff set speed adjustment from AutoLongHaul::MakeLinearVelocityOrder)?

[Klauss++]

Alright, so I'll commit, since it does work well, and the fine-tuning can happen later.

[Turbo Beholder]

Sorry, that one still makes SPEC uunusable in some conditions. Here's a good one - tested with different values of relevant confvar. Added one more, too.

Also, now that rampdown actually works, setting warprampdowntime to a greater value (at least 1.5 seconds) actually reduces SPEC jitter somewhat. :]

[Klauss++]

Please don't add extern prototypes directly in .cpp files. That's an anti-pattern. Add them to a relevant header file if they're useful outside their definint module, and without an extern directive (since it makes it exportable, which we don't want, we just want the prototype defined for internal linking).

[Turbo Beholder]

Edit: Oops, forgot to include changed headers. And then my net was down. Great.
See the correct version plus some cleanup on the next page.

[Klauss++]

Is that patch made pre-commit of the MinWarp_03_1.patch?

If so... can you svn up and make it relative to HEAD? (so I can see what's actually different, I see lots of stuff that I think was on the 03_1 so I can't tell what's new).

And, since we're at it, don't put comments at the beginning of the line. That's a bug of the auto-formatter used at some time to tidy up all of VS code, it should be fixes as opportunities arise, but certainly new comments should be flush with the paragraph they're in.

[Turbo Beholder]

P.S.: I recommend to set warprampuptime to at least 10 sec (like computerwarprampuptime is now), since warp ramping itself works correctly now. Generally, the slower it changes parameters, the later it runs into some border condition... which may well go away at some point (ongoing maneuvers, changing warp interdiction) before that.

[Turbo Beholder]

This one also cuts down on panic speed prediction, but leaves room for performance stutters.
Also, some more procedural-izing to keep controls in one place: we may want to add more FXs, other setting-dependent checks like my "wait, SPEC shuts down right now" on physics/warp_activate_during_rampdown, etc, thus autopilot, togglewarpdrive, Python and everything should all use common "turn SPEC on"/"turn SPEC off" functions, right?

vegastrike$ svn diff -r HEAD src/cmd/ai/firekeyboard.cpp src/cmd/ai/flykeyboard.cpp src/cmd/ai/navigation.h src/cmd/ai/navigation.cpp src/cmd/ai/warpto.h src/cmd/ai/warpto.cpp

[Klauss++]

InterdictionWarransWrap, WarpOffRamp, WarpOnRampCautious, are defined both in navigation.h and warpto.h, sometimes with conflicting signatures.

They should be define only in one place. Which will it be? (I'd say navigation, and I'd put their code also in navigation.cpp).

If you agree, I might do it myself.

[Turbo Beholder]

They are used in warpto itself... so it's down to which (navigation or warpto) uses which, and currently navigation includes warpto.
So, here's the next version, also -r HEAD.

---

1. Headers are cleaned a little.
2. Prediction for deactivating warp is changed into less annoying form - now understands deceleration.
3. Autopilot sets VelocityReference to the current obstacle when it tries to avoid something, otherwise to the destination entity.
   • This improves compatibility with proper orbital mechanics simulation, when it will be added.
   • This leaves fixing [bugs:#539] trivial, by providing a more correct implementation of the buggy feature in question.
   • This gives an implicit "chase mode", since the pursuer eventually falls under "the closest interdicting obstacle".
     • Which partially fixes [bugs:#631] - in that the pursued ship doesn't hang in crosshairs, but accelerates away. May want to copy this to AI.
4. Autopilot controls computer data's "set speed" field - it's not used otherwise at the time, and since it's displayed via gauge, the player can see what really goes on.
   • Try e.g. to toggle Travel mode on a ship with afterburner while autopilot is active and see how the gauge responds, in a gravity well and out. This was included in conditions before my changes, BTW. I just separated it into a function.

[Klauss++]

Reopened, needs a review of the latest patch