If you’ve flown in MSFS for any length of time you’ve probably tried one of the existing landing-rate add-ons. They tell you your touchdown FPM and call it a day. Some give you a little color-coded label — “smooth”, “firm”, “hard” — but that’s about it.
That was fine when “did the wheels stay on the ground” was the goal. It stops being fine the moment you actually start trying to improve.
What we wanted
We’re sim flyers who also fly real GA — and we wanted a tool that:
- Graded the whole landing, not just touchdown — a 200-fpm grease that floats 2,000 ft past the touchdown zone is not actually a good landing. A 250-fpm “firm” touchdown on centerline at the 1,000-ft markers is. The number that matters is composite, not isolated.
- Used real airline criteria — the FAA Practical Test Standards, FCOM Vref tolerances, and FOM hard-landing thresholds are all public. There was no reason to invent custom rules when the industry already has them.
- Knew the difference between a 737 and a Cessna — telling a 152 pilot that 250 fpm is a hard landing is wrong. So is letting a 777 pilot get away with 700 fpm. Per-aircraft thresholds aren’t a nice-to-have, they’re the whole point.
- Was honest about what it couldn’t measure — if MSFS doesn’t share runway data, we don’t want to silently award a 100% on centerline. We want the grade to reflect what we actually saw.
None of the existing tools did all four. So we built FLARE.
Why MSFS 2024 specifically
We focused on MSFS 2024 because it’s the active platform, the SimConnect SDK is the cleanest it’s ever been, and the world model (especially with the bundled OurAirports data) gives us enough to do real runway analysis instead of guesswork.
X-Plane has its own ecosystem and its own conventions, and a port would mean rebuilding most of the SimConnect-equivalent layer. P3D / FSX are in maintenance mode. MSFS 2020 still has a user base but the SimConnect variables we lean on (touchdown lat/lon, the ATC RUNWAY series, plane touchdown pitch) all behave more consistently in 2024.
That’s a deliberate scope decision. Doing one platform well beats doing four platforms poorly.
The design principles
Three rules from day one:
1. Run as a standalone window, not as a sim add-on. FLARE is a Windows app that talks to MSFS over SimConnect. We don’t ship anything into the Community folder. We don’t ship a Marketplace package. We don’t hook into the sim’s panel system. The reason is simple: every Community-folder add-on is one more thing that can break across MSFS updates. A standalone window with a documented SDK boundary is robust.
2. The grade has to be defensible. Every score on every landing has to trace to a documented criterion. If you ask “why did I get a D on centerline?”, FLARE can show you: 14 metres lateral offset at touchdown, which maps to a 35-point score on the published per-aircraft curve. No black box. The methodology page documents every formula.
3. Local data is yours.
Your landing logbook lives in a SQLite file under %LOCALAPPDATA%\FLARE. We don’t delete it. Uninstalling FLARE leaves it intact. You can export to CSV or JSON. If the cloud sync to the customer portal is something you don’t want, you turn it off in one toggle and FLARE keeps working entirely offline. That principle predates the product — we don’t want to be the kind of tool that takes your data hostage.
What’s been hard
The honest answer: calibration.
Building the scoring engine wasn’t really an engineering problem. The hard part was deciding where to put each threshold. Too lenient and an A+ becomes meaningless. Too strict and even good landings grade as B. We’re now on the third major revision of the per-aircraft profiles after testing against hundreds of real landings across 25 aircraft categories.
The other hard one: figuring out what to do when MSFS doesn’t tell us everything. The pre-v1.2 behavior of awarding default 100s on missing runway data felt nice but was silently inflating scores by ~30% in third-party scenery. The v1.2 NaN-skip + GPS-lookup fix (covered in the methodology post) was the right answer but took a few iterations to land cleanly.
Where we’re going
The roadmap, in roughly the order we’re working on it:
- Per-aircraft pages on the portal. Drill into your performance by aircraft type — Vref accuracy trend, average touchdown FPM, your personal best. The data’s all there; just needs the UI.
- Approach replay. A second-by-second chart of the last 1,000 ft already exists in the popup, but on the portal it deserves a bigger interactive view with annotations (“you went above glideslope here”, “speed dropped below Vref −10 here”).
- Coaching mode improvements. Multi-pilot debrief sessions are live (Portal → Debrief), but the per-landing comment thread is bare-bones. We want richer review tooling for flight instructors who use FLARE with students.
- More aircraft profiles. 25 categories cover most of what’s in the default and major-payware MSFS catalog. We’d like to get to 35 — adding tilt-rotors, more bizjets, more GA tailwheels.
We won’t promise dates, but everything above is in active design or development.
What you can do
If you fly MSFS 2024 and you care about how well you fly: buy a license, install FLARE, fly the way you’d fly anyway, and look at the data. The point isn’t the score on a single landing — it’s watching the trend across a hundred landings and seeing what’s actually getting better.
If FLARE produces a number you don’t agree with, tell us. Our contact form feeds the same support queue that handles billing — we read every message. Calibration is an ongoing conversation.
And if you’ve got an MSFS YouTube channel or a flight-sim Discord and FLARE is useful in your flying, mention us. We’re not running ads. Word of mouth is how this kind of thing grows.
For the deep technical walkthrough of how the composite score is computed, see How FLARE grades a landing. For the runway-detection methodology and the OurAirports navdata work, the help page on runway detection has the full picture.