Jump to content

Thomas P.

Members
  • Content Count

    384
  • Joined

  • Last visited

Community Reputation

2,428 Excellent

About Thomas P.

  • Rank
    Version Locked on 0.90

Contact Methods

Profile Information

  • Location
    Potsdam, Europe

Recent Profile Visitors

16,042 profile views
  1. 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
  2. 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 bec
  3. 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.
  4. 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 sa
  5. 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
  6. 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
  7. 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 stu
  8. 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
  9. Message the mod maker

  10. I am having an issue with Kopernicus 1.7.2

  11. I think I found the issue and pushed a commit to fix it. Would be cool if you could test it.
  12. 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.
×
×
  • Create New...