There are just a few functional changes:
New Pitching Behavior
The plane doesn’t pitch as abruptly as before. It seems to me like this was a bug in ADF/TAW: the proportional gain for handling pitch demand was set ~20× too high. It moves a lot smoother now.
Notice that there were two additional mechanisms in place for making pitch less abrupt: First, key input was smoothed out to give a nice slope over time when pressing a key. Then, the FCS has internal limiters to prevent sudden demand changes and smooth roll/pitch/yaw demand over time. These are now probably useless, but I’ll conduct more testing before I disable them. (If I get this wrong, the plane will explode during high-speed turns.)
Small Bugfixes
Several coefficients were computed incorrectly. This included typos (confused axes or variables); off-by-one errors in lookup tables; confusing wings for elevators. The effects are very minor.
A nice example: A term was written out as 1/8 * cos(phi). In C/C++, all constants are integer by default. Dividing the integer 1 by the integer 8 yields zero, thus the expression always resulted in zero. It was clearly meant to be 1./8. * cos(phi), i.e. the constants being floating-point numbers.
Testing Workarounds
There are at least two workarounds in the flight model: Resistance to AoA and resistance to sideslip.
The flight model uses a somewhat scientifically accurate formula to derive the air resistance of rudders from their geometric description. But then it just throws it all away and replaces it with the constant -2. before using it to compensate for sideslip.
Luckily, their compiler didn’t optimize away the original function, so I re-enabled it. I found, however, that it hardly works. The plane yaws left/right just fine, but it keeps flying straight no matter what. The flight path just doesn’t change. So they hard-coded the -2, which makes the rudder response way to hard at low speeds, but at least it makes the rudders usable at all.
There is a similar situation for the AoA compensation. When I re-enabled the scientifically correct formula, the F-22 reached much higher AoA during curves, but had a tendency to stall. It did feel much more realistic, but much less fun.
I kept the workarounds but I also left the original functions in the code for later re-evaluation.
… but there are more important changes under the hood:
Full Refactoring
The flight model code has been 100% refactored. Almost everything has been renamed or commented. It is finally somewhat maintainable.
Autopilot Preparations
I’ve prepared an autopilot. It’s not yet usable because it lacks infrastructure: There is no GUI to configure it. There is no mission system to provide waypoints. There is no airport system to provide correct waypoints for taxiing on ground. There is no radio system to coordinate air refueling. There is no terrain-following radar to provide elevation data along the path.
With a few hard-coded waypoints, however, I can make the F-22 autopilot
- get the plane rolling from a parked position;
- follow the road to the runway;
- take off;
- reach a specific altitude and/or heading;
- target a specific waypoint at a specific speed and altitude;
- perform negative G rolls to descent to waypoints at lower altitude.
Other Flight Models
The flight model has been modified to support other planes in the future, just like ADF/TAW’s does. The ejection seat would be a first candidate, though I’m not yet so far.