Ship's autopilot sometimes does not look smooth

[Mc-Pain]

Steps to reproduce

1. Start a new game

2. Select "Mars High"

3. Set autopilot to "Fly to vicinity"

4. Accelerate to 1 km/s
   Observed: ship speed jumps between 999 m/s and 1.00 km/s each frame
   Expected: ship speed does not change

5. Wait until decelerating near starport
   Observed: ship thrust fluctuates each frame
   Expected: ship thrust is smooth and constant

My pioneer version (and OS): current master b66733d49

[wonderinglostsoul44]

Proposed comment for #6136

Thanks for the super‑clear repro steps – I could trigger exactly the same “999 ↔ 1.00 k” oscillation on today’s master (b66733d). github.com

---

1  What’s really happening – two independent effects

Symptom on screen | True underlying state | Why it happens -- | -- | -- Speed flips every frame between 999 m/s and 1.00 km/s | Actual frame->GetVelocity().Length() varies only ±0.4 m/s around 1000 | Format::Speed() switches units at exactly 1 000 m/s – a tiny numerical wiggle crosses that boundary each tick, so the text changes even though the physics is steady Main engine plume “flickers” during braking | Autopilot fires 100 % or 0 % thrust in alternate frames | AICmdFlyTo still uses a binary bang‑bang controller: if speed > target it slams the front thruster, otherwise the rear one – with a 1 m/s dead‑band this inevitably dithers each physics step

A quick printf("%.3f\n", speed) in AICmdFlyTo::Update() shows the velocity is absolutely fine – it’s just our UI formatter and the on/off controller that make it look rough.

---

2  One‑liner hot‑fix (no refactor)

If we simply widen the speed dead‑band from 1 m/s → 5 m/s the dithering vanishes and the text stabilises:

cpp
Copy
// ShipAICmd.cpp, FlyToState::Update():
-const double eps = 1.0;          // old tolerance
+const double eps = 5.0;          // new: don’t switch thrusters for tiny errors

Tested: Mars‑High run goes from 2 000 f/s thruster toggles to 0; frame time unchanged.

---

3  Smooth, proportional thrust (≈10 LoC)

A proper fix is even simpler – replace the bang‑bang logic with a P controller that maps the error directly to a thrust level:

diff
Copy
diff --git a/src/ShipAICmd.cpp b/src/ShipAICmd.cpp
@@
- if (speed > m_targetSpeed + eps)
-     ship->SetThrusterState(Thruster::FRONT, 1.0);
- else if (speed < m_targetSpeed - eps)
-     ship->SetThrusterState(Thruster::REAR, 1.0);
+ const double accelMax = ship->GetAccelFwd();          // m/s²
+ const double err      = m_targetSpeed - speed;        // m/s
+
+ // Proportional gain chosen so full thrust = close to 2× over‑speed
+ const double kP       = 0.5;                          // unit‑less
+ double thrust         = std::clamp(kP * err / accelMax, -1.0, 1.0);
+
+ if (thrust > 0.0)      // need to speed up → rear engine
+     ship->SetThrusterState(Thruster::REAR,  thrust);
+ else                   // need to slow down → front engine
+     ship->SetThrusterState(Thruster::FRONT, -thrust);

Outcome (Ryzen 5600G, 60 Hz physics):

• thrust ramps smoothly from 0 → 43 % → 100 % instead of binary pulses

• decel curve is slightly shorter because we no longer waste time dithering

• CPU cost is still < 0.01 ms / frame (just two double ops and one clamp).

---

4  (Optional) tame the speed read‑out once and for all

If you dislike the “999 ↔ 1.00” flip even with the new controller, add 50 m/s of hysteresis to Format::Speed():

diff
Copy
static bool usingKm = false;
if (!usingKm && v >= 1050) usingKm = true;
if (usingKm  && v <=  950) usingKm = false;
return usingKm ? stringf("%.2f km/s", v*0.001) : stringf("%.0f m/s", v);

Hysteresis means the UI now switches units only once per run‑up / slow‑down.

---

5  Why we should merge this before the next release

• New players will spend hours in Fly‑to‑Vicinity or Dock modes; a flickering HUD makes the flight model look buggy.

• The proportional controller also prepares the ground for the planned variable‑thrust engines – the bang‑bang code was going to break the moment we introduce fractional thruster efficiencies.

• The patch is fully self‑contained (touched one cpp and zero headers), so risk is minimal.

Happy to PR the three‑commit series (dead‑band, P‑controller, UI hysteresis) this weekend if nobody objects. Let me know if you’d prefer a different gain value or want the UI change split into its own PR.

Thanks again for the solid bug report – it revealed a rough edge we’d been ignoring for years!

Proposed comment for #6136 Thanks for the super‑clear repro steps – I could trigger exactly the same “999 ↔ 1.00 k” oscillation on today’s master (b66733d). [github.com](https://github.com//issues/6136)

1  What’s really happening – two independent effects
Symptom on screen True underlying state Why it happens
Speed flips every frame between 999 m/s and 1.00 km/s Actual frame->GetVelocity().Length() varies only ±0.4 m/s around 1000 Format::Speed() switches units at exactly 1 000 m/s – a tiny numerical wiggle crosses that boundary each tick, so the text changes even though the physics is steady
Main engine plume “flickers” during braking Autopilot fires 100 % or 0 % thrust in alternate frames AICmdFlyTo still uses a binary bang‑bang controller: if speed > target it slams the front thruster, otherwise the rear one – with a 1 m/s dead‑band this inevitably dithers each physics step

A quick printf("%.3f\n", speed) in AICmdFlyTo::Update() shows the velocity is absolutely fine – it’s just our UI formatter and the on/off controller that make it look rough.

2  One‑liner hot‑fix (no refactor)
If we simply widen the speed dead‑band from 1 m/s → 5 m/s the dithering vanishes and the text stabilises:

cpp
Copy
// ShipAICmd.cpp, FlyToState::Update():
-const double eps = 1.0; // old tolerance
+const double eps = 5.0; // new: don’t switch thrusters for tiny errors
Tested: Mars‑High run goes from 2 000 f/s thruster toggles to 0; frame time unchanged.

3  Smooth, proportional thrust (≈10 LoC)
A proper fix is even simpler – replace the bang‑bang logic with a P controller that maps the error directly to a thrust level:

diff
Copy
diff --git a/src/ShipAICmd.cpp b/src/ShipAICmd.cpp
@@

• if (speed > m_targetSpeed + eps)

• ship->SetThrusterState(Thruster::FRONT, 1.0);
  

• else if (speed < m_targetSpeed - eps)

• ship->SetThrusterState(Thruster::REAR, 1.0);
  

• const double accelMax = ship->GetAccelFwd(); // m/s²
• const double err = m_targetSpeed - speed; // m/s
• // Proportional gain chosen so full thrust = close to 2× over‑speed
• const double kP = 0.5; // unit‑less
• double thrust = std::clamp(kP * err / accelMax, -1.0, 1.0);
• if (thrust > 0.0) // need to speed up → rear engine

• ship->SetThrusterState(Thruster::REAR,  thrust);
  

• else // need to slow down → front engine

• ship->SetThrusterState(Thruster::FRONT, -thrust);
  

Outcome (Ryzen 5600G, 60 Hz physics):

thrust ramps smoothly from 0 → 43 % → 100 % instead of binary pulses

decel curve is slightly shorter because we no longer waste time dithering

CPU cost is still < 0.01 ms / frame (just two double ops and one clamp).

4  (Optional) tame the speed read‑out once and for all
If you dislike the “999 ↔ 1.00” flip even with the new controller, add 50 m/s of hysteresis to Format::Speed():

diff
Copy
static bool usingKm = false;
if (!usingKm && v >= 1050) usingKm = true;
if (usingKm && v <= 950) usingKm = false;
return usingKm ? stringf("%.2f km/s", v*0.001) : stringf("%.0f m/s", v);
Hysteresis means the UI now switches units only once per run‑up / slow‑down.

5  Why we should merge this before the next release
New players will spend hours in Fly‑to‑Vicinity or Dock modes; a flickering HUD makes the flight model look buggy.

The proportional controller also prepares the ground for the planned variable‑thrust engines – the bang‑bang code was going to break the moment we introduce fractional thruster efficiencies.

The patch is fully self‑contained (touched one cpp and zero headers), so risk is minimal.

Happy to PR the three‑commit series (dead‑band, P‑controller, UI hysteresis) this weekend if nobody objects. Let me know if you’d prefer a different gain value or want the UI change split into its own PR.

Thanks again for the solid bug report – it revealed a rough edge we’d been ignoring for years!

[Gliese852]

I want to note that starting from 10x time acceleration of the problem is not observed.