In this latest post, Sidney outlines the warnings of plugin 3D rendering, and best practices…
I really didn’t want to write this post, but I fear it’s time to bring this evergreen topic back up, since the rise of AI has made it incredibly easy to do: I’m talking about hacking our engine, either by modifying our shaders or by injecting a custom Vulkan layer that alters X-Plane’s command stream or by just hijacking X-Plane’s address space altogether. To sum the rest of this post up: If you are a developer, please do not do this. If you are a user, please do not use these add-ons and especially don’t pay for them. It pains me to say this, I truly believe the extensibility of X-Plane is one of its greatest features and I really don’t want to tell anyone what they should and shouldn’t do. So let me lay out my case for why this is a bad idea and why I think you should stay away from such add-ons. Note that this is not an argument for or against AI, all of this is just as relevant for a human coded add-on, it just seems that AI has enabled quite a few of these in the last few weeks.
The Problem
To start with, let me also say that some of the hacks are very impressive. I also fully understand why users want to install these add-ons, especially for long requested and wanted features. “Third party dev does what Laminought” has a good ring to it. It’s still not a good idea though. The thing that makes X-Plane quite unique compared to traditional video games is that our engine is developed together with X-Plane and just like X-Plane, it gets updated frequently. Over the past few years, there’s been very few updates that didn’t tweak at least some parts of the core engine in one way or another. Sometimes we rewrite whole subsystems or drastically restructure how the frame is rendered, sometimes its just a small tweak or improvement here or there. We have no plans of stopping this, in fact, we have a long internal planning document with all of the changes we want to make to the engine. That engine will look almost nothing like the current engine which looks almost nothing like the engine of 12.00. But things are also always changing and new goals are added, we are nowhere near out of ideas of what we want the engine to do.
This, right there, is the crux with these hacks. We maintain our official SDK and we commit to keeping plugins that use our SDK working. If you hack our engine and work outside of the SDK, we give no such guarantee. If you develop a Vulkan layer that tries to reason about what X-Plane does to inject what it needs, we make no guarantee that X-Plane’s command stream isn’t going to be drastically different with a random update. The same goes for our shaders, our internal shader compiler is called gfx-cc and it too has seen many iterations since we first started using it. Just like with the engine itself, there are many ideas of things that we want to implement in gfx-cc that will change the generated shaders.
All of that is to say that neither our core engine nor our shaders are stable in any way. We don’t make any guarantees about where things are in our address space, what shape our shaders have and how, when and where we generate commands for the GPU. This is also why we don’t want to provide hooks for third party add-ons to “legally” inject these things, something that gets often requested when talking about this topic. The v11 engine provided many more drawing hooks and capabilities to inject custom drawing into the frame, but this ended up painting us in a very awkward corner where we had to intentionally hold off on making certain changes because it would’ve broken add-ons. Having the freedom to change the engine and shaders as needed for v12 has been a huge boon for us and by extension for our users. We really want to keep this freedom to be able to iterate on the engine and change it as needed. There isn’t and won’t be a stable interface to hook into X-Plane’s drawing or modify its shaders.
Here Be Dragons…
So here is my plea: If you are a developer, please do not create add-ons that modify X-Plane outside of the SDK. If you are user, please don’t install these add-ons and especially don’t buy them. There is a very good chance that these add-ons will break in the future, where breaking can mean anything from random crashes to visual artifacts and just simply not working at all anymore. Now, the usual argument that gets made here is something along the lines of “I know what I’m doing and I accept the risks”. That might be true for you, but experience over the years tells me that even then people often forget that they have installed add-ons. If X-Plane randomly crashes, do you really know what caused it? Will you be able to triage visual artifacts? There’s also a lot of cargoculting in flightsim where it might start with users who know and understand the risks and then tell others that they have no problems, which encourages them to install add-ons without really understanding the risks involved. We know this happens because we see the support requests that are generated by it. It is incredibly frustrating to have the “I accept the risks and I know what I’m doing” crowd be very vocally upset in the support queue when these things do inevitably break and demand that we undo changes that we have made very clear that we were going to do. It’s even more frustrating when it comes to paid add-ons when users feel like they were conned out of their money.
I want to be clear, we don’t go out of our way to intentionally break add-ons. What I’m saying is that we are not going to intentionally hold the engine back to not break add-ons that don’t play by the rules. However, if it turns out that rampant shader modification and command sniffing and injection is a problem in terms of either stability and/or support burden, we also reserve the right to close off this part of the engine much tighter.
