I received an email yesterday that I found a little bit concerning; an author wrote this:
I hope 10.30 is not going to change any of the datarefs we as a community have identified and are using to make the sim better and if it does I will work to modify the scripts to make them work again.
Here’s the problem: his add-on is one of the new Lua scripts that changes the internal art controls for atmospheric scattering – it is almost certainly not built on public x-Plane SDK datarefs, it is built upon finding, locating, and hacking the internal art controls in the sim.
So I hope the author isn’t going to mind working to modify his scripts again, because those art controls will change.
Simply put, building an add-on based on art controls is like building a house next to an active volcano – it might be a nice place to live, but you’re going to have to rebuild your house from time to time. Be prepared to do your work over, because art controls will change – it’s a matter of when, not if. The rest of this post is some warnings, scare tactics, and an explanation of why the art controls change.
Scary Warnings, Etc.
In my past comments, both public and private, I have tried to be clear that the art controls are not a stable interface, they are subject to change, and that you can’t build an add-on that will keep working while we patch if you use them. (I’d also hope that the fact that every art control starts with sim/private would get people’s attention.) But I apparently never wrote one big public global “no warranty” message*, so…um…here we go.
The art controls are not a public interface to make X-Plane add-ons. They are an internal development tool. They are unsupported, undocumented, unsafe, and most importantly subject to change with every patch of X-Plane. If you create an add-on that requires reading or writing the art controls, you can expect that your add-on will stop working when X-Plane is updated. When your add-on breaks, please do not complain or file a bug.
So hopefully that makes things clear. Art controls will change,you’ll have to do your work over, and we’re telling (and have been telling) you that since people first figured out how to access them. If you learned about art controls from someone other than me and weren’t aware of this, the person who taught you forgot to tell you the most important thing.
What Is An Art Control
An art control is an internal hook into our engine that we use to tune and calibrate algorithms, measure performance, and debug problems. I started adding art controls so that:
- Our art team could “tune” X-Plane without having to have the source code or recompile the sim and
- So I could see the results of changes to the engine without having to quit and restart X-Plane.
They are a critical part of X-Plane development.
They are not, however, some kind of public interface for third party development. We have public datarefs, listed on the X-Plane SDK website, that let you replace the flight model, customize the control surfaces, etc. Those datarefs are a real “interface” to the sim – even when we modify X-Plane, we try to keep that interface working. Many of the public datarefs are over ten years old now.
By comparison, the art controls aren’t an interface – they are deeply tied to the how of the engine, e.g. the specific algorithm we are using today. If we come up with a better algorithm, those tuning controls lose relevance and the art control goes away.
Why Don’t You Make the Art Controls Public
The immediate question that most developers have when they hear my
rantexplanation of art controls is: why don’t you make the art controls public so we can use them?
It’s a good question, particularly when the art controls are useful. The answer is that the art controls don’t represent a specification for what the sim does, they represent side-effects of the algorithm we are currently using. Let me use atmospheric scattering as an example.
Atmospheric scattering is essentially a mathematical formula (run on the GPU) that makes the color of pixels “more blue” when they are farther away. The art controls for scattering become constants in that formula – thus you can change the constants (but not the overall shape) of the formula via art controls.
But here’s the problem: the formula I use isn’t very good.** The result is that when the constants are high (for “heavy” scattering) the far view turns a really rich, electric blue that just doesn’t look anything like the planet we actually live on.
As long as we keep this formula, we’re stuck with two options, neither of which are much fun:
- Keep scattering turned way down. This is what we ship with; clearly users want more scattering – you can see that by all of the positive reactions to add-ons that crank the art controls up.
- Turn up the scattering and try to ignore the blue. This is what most of the scripts that hack the scattering art controls do, and I would say it’s clearly a trade-off.
So I am working now on a better formula, one that won’t produce incorrect colors at high scattering levels. But when that formula is done, it will be a different formula, with different constants in different places in the equations.
And that is why art controls change. The very code that gave birth to them changes, and they get deleted and replaced with new art controls. The only way to keep the scattering controls forever is to never fix the flaws in the current formulas.
What Art Controls Will Change, and When
First, I hope that if I’ve made one thing clear, it’s this: if you want your add-on to keep working with future X-Plane patches, you need to avoid the art controls.
Realistically, the art controls tend to change when there is major development in the sub-system that they are part of. So the shadow art controls will change any time we try to make the shadows better; the scattering art controls will change any time we try to make scattering better.
So if you are just tinkering with X-Plane, the good news is: if your art controls have changed, there’s a chance that you may be able to achieve a better effect using the new code.
One final note: if you want to build an add-on that needs to work past version updates (e.g. a payware add-on where having to follow our patch schedule is not a good idea) and the only way you can accomplish your goals is with art controls, send me an email. We may be able to add a real interface to replace art control hacking. This won’t always be possible, but sometimes it is, and the results will be a lot less work for your add-on in the long term and happier customers.
* See Resources/settings.txt for the warranty on hacking settings.txt.
** In my defense, the real look of the sky comes from a huge number of photons crashing into a huge number of molecules a huge number of times – we’re not even remotely close to having enough computing power to solve that honestly, so all scattering code is based on gross simplifications of gross simplifications.