Thomas P.

1.8 had the same behaviour, but I tried to do a lot of it within Kopernicus, without changing the settings value. But that code was full of bugs, and since the behaviour was the same anyways, I changed it in preparation for 1.9. This included adding the warning message. If you only display a warning, instead of locking the value, you don't gain much, if not nothing at all. People just ignore warnings. As a maintainer, you want to prevent people from relying on different behaviours outside of their or your control. For example one planet pack that is based on the values from "Medium", and one that is based on "Ultra". Supporting that is a complete mess. The only reliably way is to expose the same behaviour to everyone, no matter the game settings. And in this case it means you choose one quality level for them. Since the people who can run the ultra shader probably vastly outnumbers those who can't, the choice was easy.

The issue that is prevented by forcing the shader quality is editing an already existing Material. You rely on values on the template, which can change at random without the forced quality setting. You as the planet author have no control over it, and no way to detect it with just a config. Changing the shader requires you to provide the entire material config yourself. You dont rely on the material that is copied from the template, so you dont care if it changes. The only issues you can get are mod integration issues (when a mod already edits the material and you overwrite that). But because it happens through a config, mods could detect it, and adapt to it. Both are different things, so one is not a factor for the decision to force the shader quality, while the other one is.

It would be, for all the planet authors who would suddenly have to write and balance four material configs instead of one, to prevent their stuff from breaking. And yes, not everyone can run the ultra shader. But nothing stops you from writing a Kopernicus config that replaces the ultra quality materials with their lower quality equivalents from earlier versions.

Most Kopernicus configs are overlays over a stock body template. You want them to consistently produce the same result on every installation, no matter the game settings. With the new shader quality setting, it is impossible for the planet author to know, which material their changes will be applied to. Since the values are different, one config might work fine on one installation, and fail horribly on another one, just because the shader quality is set to a different value. Thats why Kopernicus forces the highest shader quality (and thus the ultra shader on Kerbin). It's the only sane way to solve this problem. There is another option, but it requires removing the current Material node, adding four new nodes for the different shader qualities, and then forcing every planet author to implement this because it would break every config, on every install.

The example for a gas giant that doesn't use a template is old and outdated. It should include the normal map. I think noone except me ever touched it, and I probably just forgot it when I wrote the config back then. Or KSP didn't require it. If a planet author decides to not use a template, they need to provide the missing data themselves, so also the normal map. Thats how it has always been. It is a feature, not a bug. By adding fallbacks to catch this you are making your life harder than it needs to be. I was just trying to give a more in-depth explanation to the issue. I didn't knew that you used my old example for a gas giant without a template, so I didn't know where the issue on 1.8 and 1.9 came from. So I just assumed it was because of your change, because on 1.10 it actually does have that effect (with every body). I wasn't trying to attack you or anything like that, sorry if it came over that way. I just want to try to help where I can. I looked into this a little bit before, but I don't want to well, actually... you, and let you find your own ways. But I have an idea: The most important thing that I noticed in regards to the new shader is that Kopernicus doesn't fail. This is important, because Kopernicus will deliberately stop loading and report an error if it encounters a shader type that it can't parse. I added that to make it easier for me to detect if new shaders were used after KSP updates. Earlier in this thread, and on github, people noted that the 1.9 Kopernicus loads on 1.10 without changes. This indicates that Kopernicus actually never sees the new shader, and that the Jool template still uses an old, known shader. Because ignoring Jools scaled space object removes the shader, it seems that it is applied by some script that is added to the scaled space object, and does it's work after Kopernicus finished loading. Kopernicus puts a list of the scripts that are attached to the scaled space object into the logfile that it creates for the planet. So you can check this by looking at any random logfile from Jool on 1.10. What I found is a script called MaterialBasedOnGraphicsSetting. I guess that the new shader is only used if the shader quality is set to "Ultra", and that that script is responsibly for applying it. Maybe "High" too. But everything else will use to the old 1.9 shader, which is applied by default. This would explain a lot of things: Kopernicus doesnt fail, because the old shader is known, parsable and applied by default. Every gas giant that was created from Jool looked like Jool, because every body got a copy of that script, with a copy of Jools high-quality material. You were able to fix it by removing Jools scaled space object, including that script from the body. Now you have two options: Just remove the script during templating. This would remove the new shader from Jool, but also from all other bodies. They fall back to the default one. Remove the script, but before that, force it to run already during templating, and not after Kopernicus is done. Kopernicus already forces the shader quality to "Ultra", because of how the terrain shaders are handled, so Jool, and every planet that templates off it get the new shader by default. This would also cause Kopernicus to refuse loading until support for the new shader was implemented. Personally I would go with Option 2, but since that is quite a bit more annoying (because you need to add support for the new shader), Option 1 might be a good idea for bleeding edge builds until you have all the building blocks in place. I would also warn you from trying to enable the new shader only for Jool. Don't try to be (overly) backwards compatible with stuff outside of your control (the stock bodies). It will only make your life harder in the long turn. It is way easier to adapt planet packs to the new default shader, than it is for Kopernicus to guess the wishes of the installed planet pack(s) and adapt itself to that.

Yes, there is a vanilla normal map. The reason why it is broken in 1.10 is because of the change you did to remove the new gas giant shader: You changed Kopernicus to not get the ScaledSpace object from the template body, but instead generate a barebones version yourself. https://github.com/R-T-B/Kopernicus/blob/dev110/src/Kopernicus/Configuration/Body.cs#L321 Normally when you template a body, you inherit all of it's configuration, including the normal map. So no planet pack ever had to set a custom one, except if they wanted to change it. But now, you changed the ScaledVersion node to behave as if no template was used at all, so that the user would have to specify every value themselves. This includes the normal map. But the existing planet packs expect that the body will inherit the normal map from Jool. I can't imagine any reason why it would break in 1.9 or even 1.8 too. Especially since 1.8 had a stable Kopernicus release for some time now and noone ever reported this issue. To me it sounds like you (accidentally) verified the issue with a Kopernicus build that had the scaled version change backported.

For what it's worth, these are the scripts that I used to generate / upload these stub assemblies: https://github.com/StollD/ksp-nuget It shouldn't be too difficult to adapt them for a different remote nuget repo, or to add definitions for new assemblies. They are already somewhat generic, so updating the assemblies to a new KSP version can be done very quickly. With that setup building was as easy as doing a (recursive, to get the parser submodule) clone of the repo, restoring nuget packages (IDEs do that automatically) and hitting build. Although people kept reporting that the nuget stuff would simply crash Visual Studio, so take it with a grain of salt.

If that was true, Kopernicus would have died with KSP 0.25 or so, because its original creators left. If noone else would have a say, I would never have been able to fork it and start working on improving it. @Dragon01 also gave the example of PlanetFactory which scratches the same itch. As long as it stays respectful, people who want to advance independently from the main developer should not be silenced just because it might annoy the main developer. The license explicitly allows forking, and I encourage forking it. The sad truth is that I have been done with KSP a long time ago, and I always tried to communicate it that way. I tried to keep Kopernicus updated as much as my time allowed it, but I reached a point where I don't have a lot of free time, and would prefer to use the time I have available to work on projects that I actually use and enjoy working on. I simply don't have the time and motivation to get the code for 1.9 into a shape where I would feel comfortable with releasing and supporting it. And adding to that, I dont want to push out releases without having the time and motivation to support them properly. That's why you haven't seen, and probably won't see a 1.9 release from me (or a 1.1x release for that matter). I'm sorry for not communicating this better, but I've been trying to figure this out myself too for some time... If someone wants to work on Kopernicus, and needs help with understanding how the code works and what it does, feel free to ping me on the Kopernicus Discord, open a GitHub issue, send a carrier pigeon, smoke signals etc. I'm happy to help with that. And if there is some specific problem that needs to be solved, and I have an idea for that, I'll even happily write the code for it. It's just the testing, release and support work that has become really painful for me to do, to the point where there are literally 1000 things I would rather do. Again, sorry for not really communicating (and / or realizing, I guess?) that earlier.... So, please: Don't stop people from discussing how Kopernicus development could continue, or even moderate them, in the name of some "Thomas just needs time" crusade. The license allows you to fork and work on it. I want you to fork and work on it. Kopernicus deserves a maintainer who has no lost interest in KSP 4 years ago and just keeps maintaining it just because he feels responsible for it. People should have fun with development and maintainance, which sadly is something I lost a while ago.

I think I found the issue and pushed a commit to fix it. Would be cool if you could test it.

Kopernicus forcing the ultra shader is not a bug. But all code that requires the ultra shader should be guarded with checks for it so that is definitly a bug. Although "forcing the ultra shader" is not really correct: it will force the highest available quality for every body, it just happens to be the ultra shader on kerbin. And this only applies to the template that a body is based off, you are able to change the used shader through the config just like you were in the past.