In this blog post, Ben reflects on the SDK enforcement in 12.4.0 and 12.4.1, and an update going forward…
The X-Plane 12.4.0 and 12.4.1 updates have been disruptive to plugin developers, and the main reason why is that starting with 12.4.0 (and ending in 12.4.1) we have added checks inside X-Plane for erroneous plugin behavior. To use an analogy, the speed limit has always been 30 mph, but now we have a police officer pulling cars over and sending people to jail.
What Were Y’all Thinking??
There were a few things that went into our decision to increase enforcement:
First, we saw some bugs that were the result of really astonishing plugin behavior. The buggy behavior was bad, and it was really hard to catch because we weren’t checking for the erroneous behavior earlier. This is the equivalent of finding a Porsche lodged in someone’s second-storey bedroom and going “huh…I wonder how fast that guy was driving?”
Second, we did a lot of code restructuring for multi-core in X-Plane 12.4.0, and we needed to be able to tell when a plugin was breaking the rules and when we had broken the rules. A big thank-you to all of the plugin developers who tested their aircraft early before the public beta – that original alpha contained a lot of rule violations by us. But to really get to a final version of the sim, we needed to know who had crashed because they were speeding and who had crashed because we had left a brick wall in the middle of the road.
Third, not having rule enforcement for plugins makes things hard for developers. We see this ourselves all the time. Vulkan comes with an opt-in “validation layer” that (at the cost of FPS) checks our use of the driver and tells us when we screw up. This is great because it helps us fix X-Plane, and when there are things we do wrong that aren’t caught by this layer, it makes our lives a lot harder. Plugin development for X-Plane has been like this: there were lots of things that were inadequately documented and unclear, that would “appear” to work, and then the sim would mysteriously crash 20 minutes later.
And this brings us to our final reason: rule enforcement will take erroneous plugin behavior out of the sim and that will result in a more stable experience for our users. Sure, if a plugin violates an SDK rule that is the author’s responsibility, but if you are flying and the sim crashes on final approach, that’s a bad flight regardless of where the bug is. And I think this effect will compound: the more plugin-related crashes are removed, the easier it will be for us to see our own crashes in the crash reporter and fix them.
Plugin Developer Pain
While I would assert that every plugin that started crashing due to rule enforcement that needs an update represents a plugin bug to be fixed, I want to be clear: I am absolutely not here to blame plugin authors. The truth is, with the SDK before 12.4.1, with almost no rule enforcement (and often unclear, missing or ambiguous documentation), it was very hard to write correct plugin code.
Retroactive rule enforcement is not appealing. And for our third-party developers, I feel your pain. We’re putting them in now because it is the earliest time we can do so without a time machine.
In addition, it is definitely our future intent to provide more road map guidance and forewarning going forward, as well as rule enforcement for new features when they first ship. I appreciate the community’s fast response in jumping on these issues and fixing bugs – having had to fix issues in X-Plane due to OS updates, I know what it’s like to be on the receiving end of this kind of thing. And I think this effort is worth it – the result will be a more stable X-Plane experience for everyone, almost immediately.
just to say thank you for this, the whole plugin ecosystem is now an order of magnitude stronger because of it, absolutely spot on.