✔️ FIXED BUG: Oscillation in F-22 Flight Model

[Krishty]

At 600 kt and faster, using the keyboard for pitch control causes slight bumps. It’s as if the plane overshoots, then jumps back to intended pitch.

It’s not very strong, but it does give me sort of nausea.

It likely has to do with me fixing the pitch control, which was 100 times too fast in original ADF/TAW.

[Krishty]

Quick observation: DID fixed this for Typhoon. The EF2000 flight model there feels much more natural in every regard, even though it simulates an F-22 internally.

I should compare the pitch handling routines in the disassembly.

[Krishty]

Found it, fixed it.

A Tale About Quick Hacks

I just reached Mach 6 in my F-22 by artificially increasing thrust tenfold:

image.png (42.85 KiB) Viewed 150 times

This is something special because in ADF/TAW, you cannot reach Mach 6 by messing with thrust. At Mach 4, severe oscillations start. Your plane moves up and down several miles. This eventually becomes so strong that the flight model breaks.

(The screenshot shows the moment I ran out of fuel, because due to TFXplorer’s immersive simulation, increasing thrust also increases fuel consumption.)

The Pitch Bug

ADF/TAW shipped with a strange problem in the flight model. Time is not taken into account when moving control surfaces; they move instantly. When you pull up, the flight control system would decide that it wants 9 g NOW, and sets control surfaces to full deflection. They would act on the plane with incredible force, pushing it into position several thousand times harder than in other simulations.

DID was aware of the problem, but not of the root cause. So they added low-pass filtering to keyboard/joystick input. If you press a key, pitch demand slowly builds up. The flight control system still tries to fulfil every demand immediately, and the flight model still forces the plane into submission with millions of Newtons in a split second, but you don’t normally notice. It is possible that developers at DID did not notice either – physics in ADF/TAW runs at 50 fps; many hard oscillations just slip between frames. (But if you look carefully, you can sometimes spot acceleration of 60 g and above for a single frame on the HUD.)

But TFXplorer runs at 240 fps and there is no input low-pass filtering (I want a responsive game). And so funny things happened: Sometimes, upon letting go the stick, your plane would explode due to excessive g force.

I fixed the bug for TFXplorer some time in 2020. I changed the PID controller in the flight control system to react slower (40 times lower proportional gain, in fact). Control surfaces still move immediately, but the FCS is much softer in placing them. Not only makes it oscillations and sudden explosions go away; I find that this feels much more natural.

New Oscillations

All was well until you reached speeds in excess of Mach 1.4. When you let go of the stick at this speeds, the plane “pushes back” – and it makes you feel a bit sea sick if you use the keyboard.

image.png (82.53 KiB) Viewed 150 times

A quick look revealed that in the split second you let go, your flight path indicator is above the nose – the plane has negative angle of attack. The plane still pulls up with its nose pointing down! Extremely odd – this would require flaps fully engaged for a very short time?! I checked flaps code but it looked good. I postponed the investigation.

Eurofighter Typhoon – The Better Flight Model

We know Typhoon was built on TAW code, and I already found that Typhoon’s flight model is 90 % identical to ADF’s/TAW’s. In fact, even though Typhoon shows you a Eurofighter, that’s just visuals – the flight model still operates on an F-22. In fact, even the span/area/geometry of wings and elevators is exactly TAW’s!

But the other 10 % are quite different. I re-played Typhoon this weekend and noticed how its flight model feels much more smooth.

I haven’t decompiled the whole flight model, and I probably won’t do. But it occurred to me immediately that the functions for computing wing lift look drastically different.

And so I found a tiny formula that had disappeared:

  if(not isOnGround())
    liftDemand += dbl_DA8F20 * Δpitch;

It turns out that dbl_DA8F20 always evalutes to -0.5. But why? What does the code do?

This formula slows down pitch reaction. When pitch changes drastically to a positive value, it makes the wings produce negative lift, thus delaying the pitch response. And when you let go of the stick and pitch changes to the negative … it generates lift. Lots of it!

I set this mysterious coefficient to zero and … the oscillation is gone. But not just the oscillation when you let go of the stick.

Remember the catastrophic vertical oscillation in the flight model of ADF/TAW at hypersonic speeds? It’s also gone!

The factor in that formula doesn’t take speed into account. It nicely delays pitch at low speeds. But at high speeds, it induces a feedback loop (upwards pitch causes negative lift causes downward pitch causes positive lift causes …) and destroys the plane.

Hacks and Workarounds

Why didn’t the developers of ADF/TAW fix it?

Because the flight control system hammers the plane into position with absurd force. It oscillates like crazy, but every tiny amount of error causes the FCS to counter with full force.

So I assume this had happened:

• Someone missed two zeros when programming pitch control.
   
• This made the F-22 react too drastic to pitch changes. So they introduced this magic factor to counter pitch changes with lift in the opposite direction.
   
• They noticed how crazy their FCS oscillates but had no time to analyze the bug, so they just added a low-pass filter to keyboard/joystick input. It was enough for low speeds, so it was shipped.
   
• When the flight model was refactored for Eurofighter Typhoon, someone corrected the error – knowingly or not, I can’t tell.

Pitch response in TFXplorer finally feels soft and the oscillations are gone for good. And since I could throw away the low-pass filter on the input, controls have become more responsive, too!

[mikew]

Awesome work!!!

[Krishty]

Fix has landed.

[Krishty]

Two more fixes to come:

1. invalid plane mass due to out-of-bounds access
2. fuel mass was not correctly processed by flight control system

Both were introduced by me when I implemented the model into TFXplorer; they are not present in the original game.

[Krishty]

Fixes have landed.