Down the AFCS rabbit hole

In a few weeks, the Quasar v1.2 changelog will mention, somewhere between two larger bullet points, the words "New custom AFCS". Four letters in a changelog. A couple of lines on a website.

Behind those four letters lies one of the most ambitious software efforts I have ever put into a Flying Fries product. I want to take a moment to tell that story, because the gap between "four letters" and the actual work that produced them is interesting in itself. And because the way we built this thing says something about how Flying Fries works now, and where it is going.

Why I even started

The Quasar is a strange beast. It flies from sea level at 250 knots (but you have to be brave and fly really straight at this speed!), up into space, at Mach 7.8. That is an absurd flight envelope, and it creates an equally absurd problem for the pilot at the controls: the same stick that feels heavy and twitchy at low altitude becomes mushy and unresponsive at very high altitude. Dynamic pressure changes the feel of the aircraft so dramatically that flying the Quasar gracefully across its envelope is, frankly, exhausting.

Taking a short break in my climb... FL400, at the edge of night and day, accelerating to Mach 3.3...

I knew this from day one. The previous version shipped with a very basic "auto aileron trim" assist, which helped a little, but it was a band-aid more than a solution. I always wanted to do something better. I just did not realize, when I started, how deep the rabbit hole would go.

An AFCS (Automatic Flight Control System) is not a button you tick. It is a continuous conversation between the pilot, the aircraft, the atmosphere, and the simulator's flight model. You have to decide what the system reads, what it writes, when it should act, when it should stay out of the way, and how it should feel. Every decision opens three new questions. After a while you realize you are not just writing code, you are designing a piece of philosophy.

Becoming my own test pilot, and my own chief engineer

From day one of this project, the question was not "how do I tune this thing?" but "how do I tune this thing from factual data?". Solo development on a system this complex has a known failure mode: you fly, you feel, you tweak, you fly again, and after a few sessions you cannot tell anymore whether the difference you feel between two versions is real or imagined. You forget which gain value you used last night. Two test flights an hour apart feel inconsistent because you, the pilot, are not exactly in the same state of mind. Gut feeling is a great compass to start with. It is a terrible ruler.

The analogy that kept coming back to me was Formula 1. A race team has a driver who runs laps on the track. The car is wired with hundreds of sensors that record everything: steering angle, throttle position, suspension travel, tire temperatures, aerodynamic loads. After the run, the driver debriefs. The engineers correlate his feedback with the telemetry. They adjust the setup, and the driver goes back out. That loop is how a Formula 1 car is tuned.

For the Quasar's AFCS, I am both the driver and the chief engineer. I fly the test, I describe what I felt, and then I sit at my desk to analyse what actually happened.

For the telemetry side, I built my own tool before I started serious tuning. A custom flight recorder that connects to MSFS, samples a curated list of variables at 30 Hz, and writes them to a clean CSV file: pilot inputs, attitudes, rotation rates, trims, air data, AFCS state, even afterburner activity. Everything I might want to look at after the flight. It is an internal tool, it will never ship to anyone, but its existence matters: Flying Fries has reached the point where we build the tools that shape our products. We are no longer just a hobbyist working only with whatever is provided by Asobo.

Flying Fries Recorder in all its glory!


The AI is a colleague, not a magician

I worked on this project hand in hand with Claude, by Anthropic. It helped me think through the architecture of the system, write the TypeScript code that powers the AFCS, analyse the telemetry CSVs my recorder produces, and propose mathematical fixes when a control loop misbehaves. There were days where two or three hours of dense pair-programming with Claude moved the project further than a full week of solo work would have.

But I want to be honest about what AI can and cannot do, because I think too many people have a wrong picture of it, in both directions.

To make this AFCS work, I had to sit down and properly learn how a PID controller actually behaves. What the Proportional term does. What the Integral term adds, and what kind of mess it causes when it accumulates wrong. What the Derivative term reacts to, and why too much of it amplifies noise. I had to internalise these concepts, not just read about them, because the moment a tuning session goes wrong, I need to understand what I am looking at. I cannot wave at the screen and ask the AI to magically fix things, because the AI does not feel the aircraft. I do. And without my understanding to guide the decisions, or my calls to completely change the way we looked at a problem and try new ideas, the AI is just a very fast pattern-matcher proposing plausible-looking answers.

Great PID lessons on YouTube. Links below!

The way I think about it is simpler: AI is a brilliant colleague who happens to be a phenomenal mathematician, a tireless coder, and a relentless analyst, but who has never sat in a cockpit and never will. The human has to bring the lived experience, the intent, and the judgement. The AI brings the horsepower to act on it. Used that way, it is an extraordinary force multiplier.

Where do we draw the line between helping and protecting?

The hardest decisions in designing an AFCS are not technical. They are philosophical.

There is a real tension between two values. On one side, respect for the pilot: you bought this aircraft, it is yours, do whatever you want with it, including getting yourself in trouble. On the other side, protection from yourself: the system knows what is reasonable and refuses to let you exit the safe envelope.

Modern fly-by-wire airliners sit firmly on the protective side. Aerobatic warbirds sit on the respectful side. Where should the Quasar sit?

For the Quasar, I chose the respectful side, deliberately. The Quasar is, in the Flying Fries lore, a technology demonstrator: a hypersonic prototype built to prove what is possible with nuclear-powered electrolysers and hydrogen fueled jet engines. It is meant to push limits, including being pushed past them. If you stall it, it will stall. If you over-G it, it will protest. The AFCS will assist you, smooth your inputs, and stabilise the aircraft when you release the stick, but it will not save you from your own ambitions.

That is a value choice, not a technical one. And it is the kind of choice that defines what an aircraft is.

How it works, from your seat

From the cockpit, the AFCS is a single three-position switch. That is it. Three positions, three modes:

  • Cautious — The default, nominal mode. The AFCS is fully active. When you let go of the stick, the aircraft holds its attitude. When you push the controls, the system shapes your input to feel uniform across the entire flight envelope. The civilised setting, the one you will want for cruise, for navigation, for relaxed flying at any altitude or speed.
  • Unleashed — The AFCS is fully active here too, but with a more permissive personality. Roll rates are higher, pitch responses are crisper, the aircraft feels sportier. Lighter. The same stabilisation, the same envelope compensation, but everything is dialled toward agility rather than serenity.
  • Direct (OFF)— The AFCS is fully disengaged. You get Steiny's raw flight model, with all its character and physical limitations: the stick gets heavy at high dynamic pressure, soft at altitude, and the Quasar will pitch up on its own when you accelerate, just like the laws of physics demand. This is the"I want to feel the aircraft"mode. Bring your skills!

The HUD , the Crew Alerting System, and even K.A.R.A. will tell you when you are in Unleashed or Direct, because those are the modes you should be aware of. Cautious is nominal, so it stays silent. We do not want to clutter your view with information that just says "everything is normal".

What sits behind that switch

Two cooperating layers, modulated by what the aircraft feels in real time.

The stabilisation layer is what holds the attitude when you release the stick. It watches the rotation rates of the aircraft on all three axes, as well as your pitch and bank angles. And it gently uses the trims to bring those rates back to zero and your pitch/roll angles back to where they were before you let go of the controls. Think of it as 60+ corrections per second, based on complex and intricated calculations. All of that keeps the Quasar pointing where you left it.

The shaping layer is the part that fixes the feel of the controls. Dynamic pressure changes everything: at low altitude and high speed, in a "vanilla Quasar", the stick becomes really heavy and you can barely move the aircraft; at very high altitude in a thin atmosphere, the same deflection makes you spin out of control. The shaping layer modulates the trim contribution to compensate for that, so the aircraft answers you with the same character whether you are at 5,000 feet at 400 knots or at 200,000 feet at Mach 6. Cautious and Unleashed are two distinct shaping curves, not one with a multiplier on top: each has its own personality across the envelope.

Both layers act exclusively through the elevator, aileron, and rudder trims. We never intercept your stick inputs, never override what you ask for. The AFCS works with the aircraft, never against it.

When the AFCS gets out of the way

The AFCS knows when it should not interfere.

It stays in standby when the autopilot master is engaged, because the G3000 is doing its job and there is no reason for two systems to fight over the trims. It stays in standby when the aircraft is on the ground, and when the landing gear is deployed. Those are the phases of flight, takeoff, approach, landing and taxi, where you want the raw, honest behavior of Steiny's flight model under your hands. The model is excellent in those regimes. It does not need help.

What this changes for the rest of Flying Fries

This AFCS is a Quasar feature, but the way we built it, the recorder, the analysis loop, the discipline of measuring before tweaking, will become part of how Flying Fries develops anything that involves flight model behavior from now on.

The most obvious beneficiary is the MI-24P Hind, our next product. The Hind is an attack helicopter from another era, and a faithful Hind will absolutely deserve to feel like the analog, mechanical beast it was. But a Hind is also a notoriously tricky aircraft to fly, and we want this product to be enjoyable not just for veteran rotary pilots, but for casual and console players too, who deserve a chance to experience that machine without it punishing them for being new to it. A modern retrofit layer, an optional AFCS that lets you release the stick and have the Hind hold its attitude like a contemporary helicopter, is exactly the kind of bridge that can make that possible. The Quasar AFCS is the foundation that proves we can deliver that bridge.

This Mi-24P is going to be SOOOOO epic!

Four letters

Soon, the Quasar v1.2 patch notes will read "New custom AFCS" and most people will scroll right past it. That is fine. That is what the changelog is for.

But this AFCS is also the moment Flying Fries crossed a line. The line where we no longer make aircraft only by feel and craft, but where we now also measure, analyse, iterate, and converge on solutions with the rigour of a real engineering shop. Built by a very small team, supported by AI, equipped with tools we made ourselves, and validated against telemetry instead of intuition.

Four letters in a changelog. Around two hundred hours of work behind them. And the next product will be even better for it.