Landing with reverse thruster installed results in rapid thruster switching

[XessWaffle]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

I was playing around with the Emerald Sword and I noticed that when the ship's AI is engaged and moving to land on a planet (by pressing the L key), when it gets close to the planet the reverse and forward thrusters rapidly switch. I assume this is because the ship is trying to reach a certain speed by a certain distance, but it causes a very prevalent flickering which may not reflect how the ship would behave in more real conditions.

This happens with other ships as well, like the Remnant ones where the forward thrusters flicker before the ship descends.

Steps to Reproduce

1. Obtain the Emerald Sword (or any ship with reverse thrusters installed)
2. Launch from a planet
3. Fly out a bit
4. Engage the autopilot to land (by pressing L)

Expected Behavior

I would expect to see the Emerald Sword (and other ships with reverse thrusters) deactivate its forward thrusters entirely once it is close enough to the planet and use its reverse thrusters to slow down enough to land.

Screenshots

https://user-images.githubusercontent.com/24532725/189533561-190da8be-e414-4d10-aa0c-499b74e6757c.mov

Link to save file

No response

Operating System

macOS Monterey 12.5.1

Game Source

ESLauncher2

Game Version

continuous

Additional Information

No response

[vitalchip]

This one has been about for a long time, the short answer is that it's caused by drag.

Drag retards acceleration and enhances deceleration but by doing so it makes both non-linear. When a ship is landing the stopping point is calculated based on linear deceleration, so in effect the reverse thrust is applied too early and the ship enters a cycle of chasing the point.

In a reverse thrust landing this manifests as alternating forward and reverse thrust as the point moves in front of and then behind the centreline of the ship, in a 'normal' landing the same thing happens but the ship is instructed to turn towards the point, the act of cutting thrust and beginning to turn is enough to move the point in front of the ship again, so what you see here is the wiggly arse dance as it repeatedly begins to turn and then straightens almost immediately.

So what can be done? Well, better approximations of the stopping point would reduce the effect but won't stop it altogether. Removing drag will get rid of it but that would have profound effects on many other aspects of the game..

It might be an idea to re-write landings as it's own method, rather than using Move To , we could have the landing type pre committed with each type having its own code rather than sharing the same method as it does now, that might yield results or we could flag something like 'wasReversing' so that when the ship overcooks the reverse thrust on frame 1 it cuts thrust on frame 2 (no forward thrust) and then we re-evaluate on frame 3. It won't have properly solved the problem but an on/off reverse thruster is a lot less jarring than the alternating forward/reverse.

Ideally we'd give the Ai proportional control of the thrust, like we have with turn and let it modulate the thrust to keep the point within a radius of the ship centre, rather than the current on/off and in front / behind which by its very nature can only produce harsh changes.

[XessWaffle]

If the issue is a "chase the point" type issue, then maybe it could be possible to add some sort of delta to the "point" so that there is a range in which the requirement is satisfied. So instead of chasing an exact velocity based on the distance the ship is from the target, maybe add a +/- to the velocity so that the thrusters don't need to chase an exact velocity each frame. That +/- could also vary based on the mass or other properties of the ship.

Not sure if something like this is already implemented in the code, but it might be another valid avenue to consider which would prevent changing the forward and reverse thruster mechanics too much.

[wjp]

For some unclear reason I had missed this issue when submitting #7577 yesterday, sorry. I have posted some work-in-progress code there that takes into account drag when computing the stopping point and tries to handle inaccuracies in computing the stopping point more robustly (hopefully), potentially reducing forward-reverse switching a lot as a consequence.

[jwmh]

If the issue is a "chase the point" type issue, then maybe it could be possible to add some sort of delta to the "point" so that there is a range in which the requirement is satisfied

Just wanted to add:

Q1: Move-to-exact-point vs move-to-any-point-within-this-shape (i.e. a circle, square, or polygon)

Does the code currently provide a "range" of X/Y coordinates for "acceptable landing" (i.e., "move-to-target: anywhere within this circle/polygon" vs "move-to-target: this exact point") ? Seems IMO for Landing* that providing a shape of acceptable coordinates would be better. *and maybe Boarding, too? (I'm unfamiliar w the boarding coordinate-system requirements)
(for Landing, I'd imagine a circle; for ships, who knows)

and

Q2:

Math function used: Are y'all using

• linear,
• or algebraic...
• ... or, Calculus / Derivatives (taking the Limit of X)

to calculate the necessary autopilot // AI engine/thrust behaviour ?

(this goes for NPCs, as well; not just the player's own ship. I remember a lot of really dumb AI behavior in the original EV series, watching ships, especially fighters, trying to land/dock, and just being really terrible at it lol. But y'all've obviously fixed that specific bug in this game ;D )

P.S. Forgive me if this is wholly redundant & unhelpful. I noticed some discussion earlier re: Linear calculation, so I was wondering about if the exact issue could be resolved (i mean duh, author basically pointed straight at it??) by switching the math function to:

1. use a Calculus function (ie.. derivatives & take the Limit) based on current-position, current-velocity-vectors, & arrival-coordinates and
2. (based within a specified landing-region, vs an exact point) instead.

and use that to PRE_DETERMINE HOW TO USE & APPLY THRUSTERS FOR THE NEXT E.G. 10 SECONDS OF FLYING-TIME.

Trivial or easy-to-implement? Redundant or Irrelevant?