State of the MSFS Developer Experience

(“Developer” may encompass many aspects, but this post focuses specifically on the programming/coding side of things)

Since the early days of Flight Sim, Asobo and Microsoft have done a good job of expanding the flight sim dev scene to beyond niche c++ and gdi plus hobbyists, thanks in no small part to using CoherentGT and allowing people with webdev and experience in common technologies to play their part in developing products and open source software for MSFS.

With products like FlyByWire, IniBuilds, Fenix, and more, flight simulator development has evolved beyond just reading sim data into to some crafted screens pretending to be the real thing. Developers are now working hard to create real, authentic experiences with the advice of irl engineers and pilots, going as deep as using bits to emulate the actual ARINC 429 protocol used by some commercial airliners. To call these people hobbyists now doesn’t do it justice. They are translating code, complex mathematics, and computer science into real-life behaviors and systems we see on the same real-life aircraft. They are professionals, and professionals need a good experience if they are to continue developing long term.

That being said, as it stands today, the MSFS developer experience leaves a lot to be desired and we have yet to hear from the team how it will improve, if at all for MSFS 2024. So I want this post to serve as a collection of thoughts, wishes, and frustrations we as developers have on the current state of MSFS development, and how it can improve in the future.

We want to foster a good relationship with Asobo and Microsoft. Many of the 3rd party addons on the marketplace and elsewhere play a role in generating gamepass revenue and direct sales revenue from the platform. When 3rd party devs are productive and churning out better aircraft faster, everyone benefits. The developers save time, Asobo and Microsoft make more money, and the customers have more options.

Here are some of the biggest pain points (at least for me) when developing for the sim, in no particular order.

The Aircraft Editor

Building times are long, and can result in crashes with no error log explaining why. It would be nice if Asobo could separate the build process from the simulation main thread, so a) the entire screen isn’t frozen during aircraft build (maybe a progress bar?) and b) we can get an error modal explaining what went wrong.

The Debug Tool

There are countless errors I have simply begin to ignore now because they either don’t exist, or point me in the wrong direction when an issue arises. Even perfectly functioning aircraft will be riddled with errors when you open the debug tool. I am not quite sure how this can be addressed, but I think either the threshold for errors needs to be set higher, the checker needs to be refactored, or we need a detailed guide on every error, and how to fix it, because the current state of debugging is simply chaotic, and confusing.

Since SU14, I have also noticed the debug tool truncating the beginning of error messages. This often isn’t a problem, as it’s usually the ghost errors, but it shouldn’t be happening regardless.

Lack of transparency with 3rd party devs

(Will post dev update pic showing this once I find it)
Some time ago Asobo promised in a dev update they would begin working on a weather API and have it ready in 2023. We’ve received no update about it since then, and it’s honestly confusing as to why they are dragging their feet on this. Perhaps it’s harder than they realized. Ok, just tell us that and give a new estimate. But many of the current aircraft lack significant features without being able to interact with the weather elements of the simulator

Lack of development options outside the sim

Running the simulator isn’t an easy feat. You need a decent GPU, and CPU to boot. It takes time to start, time to build, time to load etc. etc. The main culprits are the massive texture and 3d binaries that need to be loaded before any programming work can even be done. As devs, we are not interested most of the time in these 3d assets, as those are left to 3d modelers/texture artists/etc. It would be nice if Asobo could separate the sim into an “engine” with an api, and the actual graphical elements (3d models, UI, menus, etc.). This way, developers can run automated tests of their code and configuration updates, without needing to wait for visual assets like textures, 3d models, etc. to load. Often, I just want to see how a value changes over time based on some tweaks, and experiment with different configurations.

Tight dependency on Windows libraries

I get this is a Microsoft product, I do. But developers aren’t paying Microsoft here, the users are. And the better the Dev experience is, the more aircraft you can get, thus the more users. I mean, Microsoft already has the developer market cornered with GitHub copilot, GitHub, vscode, typescript, etc. There is really no advantage in forcing devs to use Windows and VisualStudio to compile the default C++ libraries provided for developing wasm gauges, or run tests of their code on a windows machine. I’d like to see libraries like the C++ wasm one be better supported with OS agnostic build tools like CMake, and better support for testing and developing aircraft without the simulator on Linux and MacOS.

Too much boilerplate setup that should just be automated

If I want to create a new asset, gauge, etc. I need to go through a delicate process of setting up the correct files, using the correct strings, all without a single typo or mistake. One tiny issue, and the entire thing comes collapsing down. I have spent way too much time trying to figure out these issues, instead of just focusing on business logic. These sorts of things need to be automated. Let’s say for example I want to add a new panel to my aircraft. There should be some sort of CLI command in the avionics framework or sim that generates the necessary changes to panel.cfg, the html_ui, the textures, and any other .cfg file such that it just works, right then and there.

This is all I have for now. If there’s something I missed, please feel free to voice it down in the comments. I sincerely hope we can look forward to a better developer experience in MSFS2024.