Sidney posted a detailed write-up a few days ago as to why developing an add-on by modifying our shaders is not a good idea. The short version is that, like art controls, the shaders are an internal part of X-Plane that we don’t lock up so you can see them and muck around with them. But there is no stability, documentation, or any attempt to make them useful the way the plugin system is.

This confused a number of commenters. Do we want you to use them or not?

To resolve the mixed messages, Sidney created this fantastic flow-chart.

Hopefully that clarifies where the line in the sand is between “I was poking around” and “I made a serious add-on”. Pretty much everything here goes for the shaders as well as the art controls, only more so.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

24 comments on “Art Controls Are For Hacking”

  1. Amusing, accurate and on point. It’s great to see some of the genius stuff some people have come up with to get around the simplicity of the graphics configuration page and to make X-Plane look substantially different. “Better” is in the eye of the beholder. But this is the sort of thing that I realize is going to be part of the game if I choose to play with their creations. And why I would never touch an art control in my own payware products. Thanks for the breakdown. Needs to be a sticky over on X-Plane.org!

  2. Good one!

    Probably another point that you surely want to mention:
    Should I contact X-Plane support or development team regarding changed art controls or shaders -> NO!!!

    😉

  5. I suspect about half of all bug posts on the .org are about addons (free & paid for) that rely heavily on hacking art controls. And those users have no clue what they are in for and why.

    Maybe X-plane needs some warning popup “Addon xyz modfies art controls – make sure you have a version of this addon that was specifically created for this version of x-plane – as art controls change WITH EVERY XP VERSION”

    1. I have some free FlyWithLua plugins on the .org that fiddle with some art controls. (Running that wonderful flow-chart I end up at the green box, good luck… : )

      Since the “RTH disaster” when users got crazy for months (widespread RTH stopped working and crashed FWL, after an art control was renamed in a minor update), I make these precautions to at least minimise the trouble:

      1. A red coloured disclaimer on the download page with a short explanation about art controls and that the plugin can be broke after any update. And a strong advice not to blame LR or FWL (or me) in that case.
      (Yes, as every one who has something published on the .org, I am aware of that some kind of users refuse to read anything…)

      2. Let the plugin check the existence of every art control it uses at start-up. If one is missing, display a pop-up explaining what happend (clearly stating that this is no bug and nobody is to blame for it).

      3. In that case, stop the plugin, so that FWL will not be crashed and other scripts will still work.

      If all developers would implement this as good practice, I believe it would make the use of art controls a little less dangerous.

      1. Don’t let the user decide wether its safe to run or not – they *really* don’t know.
        How about keep a list of know-to-work XP releases and pop up a disclaimer and NOT run your plugin by default if its some new/unkown version.

        1. Yes, to make it clear, I don’t let the user decide:

          When one (ore more) art control is missing, my plugins stop and show a detailed pop up message saying “Plugin XYZ is not compatible with the current version of XP, that is no bug, please remove the plugin, etc…”

          A list of versions and a disclaimer after every update doesn’t seem necessary to me, because I believe when all art controls are still there, it is very likely the plugin will work properly and it definitely will not crash FWL.

  7. I was wondering one thing: If customers are keen to use addons that touch shaders and art controls in order to get a more realistic look of the world in XP (basically modifying the colors the world is depicted), why Lamina Research doesn’t do anything to chance the way colors are represented so that the scenery colors would look more realistic to the customers? That way I bet people will not look to use X-vision or reshade plugins cause they won’t feel the necessity for that. Honestly, colors in XP are too cartoonish and therefore people are looking for a way to correct it. If LR corrects it in the first place, then noone will look for alternative ways, therefore noone will touch the shaders or the art controls. I think it is justy easy as that! 🙂 If LR will have a look at screenshots of the way the scenery looks default and using for example xvision, will understand what I mean. There are plenty of screenshots on the internet that can show that… XPlane is great, but I think the colors of the scenery are a bit off… Keep up the good work…

    1. I agree it is completely valid to approach this question from this perspective. I don’t have that much hours in airplane or on the top of the mountain, but when I do I always look outside and in my mind compare what I see to what I see in X-Plane. I find that X-Plane matches what I see in reality quite good. That doesn’t mean though there is no space for improvement. I personally do not want ANY customization to be available in X-Plane. What I want is X-Plane to match as close as possible its visual representation to various atmospheric and time conditions and be it adjusted to calibrated monitor with wide color space gamut.

      With introduction of all those shader and art assets modifying add-ons, especially those that have ability to have profiles, although in few instances they manage to bring some improvements, it is usually not in all conditions and with some of their profiles they create completely unrealistic or utopia worlds, where everything is so green, blue, colorful and nice like you wouldn’t want to look outside of real window ever again. I don’t get it that people say it is in the eye of the beholder, since there is only one base line in real world and there are no sliders to tinker with. I assume people think that that or that looks more real because of their lack of real experience (time spent in real aircraft or mountain) or their perception is based on sources they used in the past and consider them as representation of baseline (like FSX/P3D or Youtube videos from cockpit views recorded with non professional camcorders). And finally, X-Plane is professional simulation software, it should simulate environment as closely as possible and not turn into cartoon fairy tale flight experience or sepia color movie flight.

      So the question arise, with substitutional and questionable improvements to the look of the simulator from the community being limited, will LR take the responsibility to bring in some improvements to the look of the simulator? As there is space for improvement, do you have plans to improve things on your side? One quick example that comes to my mind are dawn/dusk skycolors in X-Plane as I did not see purple ones in real-life yet.

  9. As stated above, it is overwhelmingly obvious that xvision has made a vast positive impact on the colors , and lighting in xplane to the point that here we all are arguing one side or the other.

    So then to the devs, I ask why not take a look at the xvision plugin and code it into the Vulcan engine and include it ? I’m not a coding person which is why I’m asking is this possible?

    It seems to be the same thing that the dev’s went through with diablo 3 and the colors were all wrong and lighting was wrong and they ignored the fan base and it took until almost half the base left the game..

    Is pride getting in the way? Or is it technical issues that stymie progress? What’s going to happen is you will see people dump xplane in masses to go back to p3d which is not as good flight mechanics but visuals are almost on par with xvision and if p3d sees an opportunity by following this discussion , they will do so..

    What is really at the heart of this decision ?

    1. I don’t think there is malicious intent here, nor do I think people will simply dump X-Plane over xVision. The work with the shaders in 11.30 is necessary to progress the sim forward.

      What’s really needed is simplified and non-invasive “post-processing” settings from which we can control the sim and some artwork. Photographic features such as exposure, contrast, ambient light etc. It makes more sense to address something like this after Vulkan (the entire atmosphere and environment of X-Plane needs a re-write imo, to accommodate new seasons, weather/clouds, trees, lighting.) Lets get Vulkan first and 11.50, and then Laminar will have the overhead to decide on the new features and eyecandy.

    2. There’s a lot to unpack here. There are two separate “decisions” and also some luck.

      First, pretty much all of the _timing_ of this is just random luck. Sidney has been working on the new shader compilation strategy for quite a few months now and we’ve known we were going to go this way for a very long time. The decision to do this was totally not related to any third parties – basically we found the best engineering solution. Since we never intended to “keep shader hacks working” we did not say “we can’t do this best solution because of the third party shader hackers”. Indeed, the decision to NOT support shader-edit compatibility is strongly motivated by the need to make these kinds of major shader changes.

      Second, my communication with Yuri has been _very_ poor on my end, and this is not an isolated incident. My in-box is just a flood of emails, some of which get under-answered or never-answered. I don’t feel good about that at all, but I haven’t had a great solution…I can’t stop my regular job of coding to just answer email, and the number of developers just grows as X-Plane grows. For what it’s worth, we are looking at creating better channels of communication to try to avoid devs being left in the dark, potentially with other LR people helping to unload me.

      In the case of shaders, there is at least one third party (I think _not_ X-Vision) who emailed to ask about getting shaders reloaded and I think I replied with “you shouldn’t even be editing our shaders”. I gave myself a TODO to write a post like this one, and then (see above about time constraints) didn’t get to it or months..finally Sidney took it off my plate. So this is a case of me not communicating enough with third parties and not getting the info out widely enough, all due to time constraints – see above about having other LR people help out.

      Settings.txt has a massive disclaimer saying “this file is for hacking, not add-ons”. We never clearly labeled the shaders…I think we assumed that the total lack of documentation or public mentioning in any way would disqualify them from being considered “an SDK” but in hindsight maybe our wording needs to be stronger. This is a bit tricky because there’s a lot of private stuff in Resources and labeling it all would be tedious.

      The decision to _not_ support third party shader hacking is simply an inevitable one. We can’t have a rendering engine that gets better in major ways _and_ third party shader hacking. Vulkan is sort of the poster-child for why this is the case. We literally have to rewrite the shaders or they won’t run on Vulkan and Metal – there was no way compatibility was going to be maintained. But we also saw this with FlyInside, which (from what I can tell) hacks up our shaders; when we shipped 11.10 and 11.20 (and shipped changes that moved us toward native VR) we saw their add-on crash X-Plane during beta as they modified shaders that were already changed. LR can’t reasonably be expected to have no native VR support to maintain add-on shader compatibility.

      Could X-Vision be built into X-Plane? I have no idea, but I can say this: I would _never ever ever_ expect any third party to simply _give_ us their work. Third parties owe us _nothing_ in terms of contributing to the core sim*. If you’re a third party and you make something, it’s yours! So there isn’t really an active _decision_ to “not include X-Vision in X-Plane” — it’s _not our code_. I can email Yuri and ask him nicely but given that he put a lot of time in, apparently didn’t understand that the shaders would change, and that I didn’t reliably email him in the past, if his response was “you can shove your email up your ass” I would not blame him _at all_ or hold that against him in any way.

      Finally, it should be noted that all product discussions we have with third parties are held in confidence for the benefit of the third parties, so _if_ we ever have a constructive opinion with a third party shader hacker about integrating their work with X-Plane (and I’m not hopeful – see above that it’s their work and their add-on), it would not be something I could talk about here.

      It should also hopefully be clear from everything I’ve said about our communication, timing, intent, and expectations about third parties that there is _no_ financial incentive or win here for us breaking third party shader-based add-ons. It is just the inevitable consequence of us moving to Vulkan and third parties building add-ons on parts of the sim that are not stabilized APIs.

      * There is one exception: sometimes when a third party wants to use our art _directly_ to make an add-on, we strike up a deal where they use our stuff and later we can use theirs. But this is a very intentional quid-pro-quo that’s designed to be fair to everyone, and we agree to this privately up-front.

      1. Ben, thank you for such a detailed post, appreciate your openness and honest!
        Please feel free if you think you have contact us. We hope to be of services to you and your company.

  10. Hi developers. I was hoping if you could address the question once and for all regarding many people’s confusion on how exactly to define X-Plane. There are too many people who consider it a game, and there is no “game like” feature in X-Plane, so I was hoping if you could make a statement on that.

    Thanks!

    1. X-Plane is not a game, it is a highly complex numeric simulation!! That’s why it’s okay to fly it in the office during work hours. 😉

      I think the real issue when it comes to shaders and art controls is NOT whether it’s a game or not. It’s that X-Plane is a platform for content.

      In a traditional game-engine based game, there is ONE version of the engine used to make the game, and thus the content authors know everything about it and it never changes out from under them. This in turn means the game engine can expose all sorts of controls and tweaks because there is never any attempt to have the game keep working across major changes to the engine. The game can simply choose to not take new engine updates past a certain level of complexity.

      In X-Plane’s case, the content and the engine are totally decoupled and the content isn’t even all packed at once. This eliminates a number of tricks and optimizations that game engines can take.

      1. Thanks a lot! This definitely settles the argument that’s been flooding the internet regarding X-Plane!

  12. I know the blog is not meant for bug reports, but I have no other way to communicate that the dedicated form doesn’t work for me. All I get is “There was a problem filing the bug”. I swear my report was complete, I spent all the afternoon preparing it. No file was bigger than 6megs (compressed as .7zip).
    Thanks.
    Pascal

Comments are closed.