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.
As someone who had modded the sky shader to hack how x-plane renders the night sky: Listen to Sid. If anyone try to sell you a hack, don’t. Hard no no. I know that my hack changes stuff and bring odd artifacts. And is something that I was ok, I keep track of it, and often, test my shit properly. And I know it will break, and often, remove to confirm it isn’t what I done that messed the product.
If you decide to use a hack, don’t cry when your stuff breaks. Not even to who created. it will break, as the nature of it. And the most important, don’t buy or run code that was vibecoded without a human looking through it. If any of these “hacks” are not clear that they will break x-plane at any given moment, or break add-ons, it’s a big red flag and no no. And if it is charging you money for that, run to the other side of th room.
Makes sense in theory! Would LOVE to see more linux VR support though – some Vulkan trickery (read only in our case, so won’t break XPlane but still prone to breaking in updates) is kind of the only way to get Linux VR to cooperate with certain things like giving us depth data without having proper OpenXR wired up – being stuck with with SteamVR & a translation layer isn’t ideal! Still, across all tests we’ve done performance in VR is almost double in Linux vs Windows, so we’d REALLY love to see OpenXR supported on Linux even if it’s not official support – let me know if there’s any way to help!
I should make my stance clear – I AGREE with Sidney, especially on the grounds of not SELLING a plugin that uses any unofficial manipulation, and generally agree on not using other people’s plugins that do. What I think this post fails to identify is that some people aren’t messing with things because they want a new feature or to have it break later, but because a stop-gap is the only available solution. For context:
We run a commercial simulator company. We LOVE XPlane, it’s by far the best option, and Laminar does a fantastic job maintaining & updating it. For realistic visual flight training, nothing beats it. We’ve tried deploying Windows + XPlane to our offsite setups, and it was a disaster. Not because of Laminar, but because Microsoft is unable to avoid breaking things every second week. Half our setup on Windows is workarounds on top of workarounds, and they don’t usually work. Our Linux + XPlane deployments on the other hand work flawlessly. Linux doesn’t randomly break on us, it’s easily customisable how we need, and on top of that XPlane runs WAY better on Linux – No random stutters, generally higher framerates, etc. Mixed reality is the next step in the journey, and while we’ve had prototypes working with Windows for quite some time, they simply aren’t deployable due to Microsoft. In the meantime, XPlane on Linux for VR works reasonably well (performance is FAR better than on Windows), but is missing quite a lot, like OpenXR support & depth buffers, not to mention even though XPlane is running in Vulkan mode, it’s submitting OpenGL to SteamVR.
So you can see our options:
A) Change simulator for VR
B) Use XRizer + some Vulkan wizardry to make it work in the meantime
To be clear: Laminar has limited time and unlimited things to work on! We don’t expect them to drop everything to make Linux VR fully operational! That being said, I think my point stands that sometimes it’s not that we want to make unsupported things that break, but it’s that we love XPlane and want to use it everywhere we can, even if support for what we need isn’t quite there yet.
Keep up the good work Sidney & Laminar, we can’t wait to keep using XPlane long into the future!
How many more years should we wait for proper anti-aliasing? I’m thankful for the modders who are trying to fix it, since you apparently can’t.