Fix aircraft jittering

[PunkPun]

Closes #4824

For context, the fact the facing can jitter is expected and intentional. What we want to prevent is visual jitter, and here we fix it by not acting on facing discrepancy if the difference between the current and desired facing is below angle 2

[pchote]

I'm not a huge fan of this approach. It would be a lot cleaner if Fly did this instead.

[PunkPun]

How would that work? Fly is functioning as intended, do you want to hardcode Fly in SpriteSequences?

[pchote]

There is no need to have the underlying facing (with a 1/1024 resolution) varying by +/- 1 between ticks. The hysteresis can be applied there and/or hook up with BodyOrientation.QuantizedFacings

[PunkPun]

Badger.mp4

That doesn't eliminate jitter completely. There's a reason why it needs to jitter, and applying hysteresis at that level won't fix it

[pchote]

I'm personally not convinced (and what about the mismatch between the sprite and contrail/weapon positions which are controlled by BodyOrientation?), but if you do want to push forward with this approach please at least encapsulate it within a WithAircraftFacingSpriteBody so its not forced on all actors and mods.

[penev92]

Those sound like major issues.

[PunkPun]

Contrail works correctly, as for weapon offsets it seems they are using the raw IFacing interface

[PunkPun]

I localised the jitter prevention inside Fly activity. With a deadzone of 2 there's very little jitter, to a point that if you aren't playing attention you are not likely to notice.

[pchote]

IMO it would make sense to expose the 2 value on AircraftInfo rather than having it hardcoded as a magic value?

[PunkPun]

What's the benefit to exposing it? I could make the range a const

[Mailaender]

What's the benefit to exposing it?

Mods have different amounts of facings for their aircraft. I would welcome a configuration option for @OpenHV. It also avoids a magic number.

[Mailaender]

Changelog

[Mailaender]

cfc026a