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.

I need to know the commit that you compiled. And you need to post your Logs-Kopernicus.zip just like every other person that wants to report a bug.

What is wrong with people that they can wait months for a KSP update with regular teasers, but not wait until modders put out a proper update when their life permits it? And then not even try to contribute upstream to get stuff fixed faster, but just put out builds of in-development code out there for quick fame? See: I don't care if you fork Kopernicus and recompile it. I don't care if you put out code that is under development out there. I really don't care. But users who install those binaries care. If you don't know the workings of the mod inside-out, you have no idea what might (still) need changes. And if you just push out a binary they will probably end up breaking their saves and then come to the Kopernicus thread (not to yours!), complaining that the saves are broken. What I care about is you shipping dependencies that haven't been updated. The MFI included in Kopernicus might still work for testing, but from the very moment 1.8 released my plan was to not put out anything until sarbian at least had a chance to recompile it against the new KSP version. Shipping that old thing not only throws me under the bus, but sarbian too, potentially. Then, if you have to change the build systems of the mods, at least do it on the right branch. What you did for Kopernicus was checking out one branch, then copying everything onto master, making the commit look like those were your updates to get the mod working under 1.8. Again: I don't care at all. The license allows you to do it. But other people might care and then go on my nerves asking me to check out that branch because it might help me get 1.8 to work. Finally, let's be honest. If I wouldn't have changed the version number of Kopernicus to 900 you would have just shipped it as 1.8.0-1, messing with me even more because then I would have to memorize and compare the assembly checksums to even figure out what users are running once I release the real update.

Released 1.7.3-2 and all the other backports: Removed Kopernicus Buoyancy modifications to fix ocean lag, they never worked anyways Fixed texture loading with on-demand loading disabled Unload normal maps from RAM and only keep them in VRAM when loaded on demand Sorry for the really long delay, I just didn't really have time (or motivation) to do the release work. Note: This doesn't fix the lags that are caused by the DLC scatters! Those lags are not something that Kopernicus can fix, they are a design flaw in the DLC scatter system that is noticeable in rescaled systems (JNSQ for example). If a part of the terrain has reached it's highest subdivision level, the DLC scatters will be enabled in that area. In a rescaled system, the planets have to subdivide way earlier than in stock scale, to keep the same level of detail, meaning the area that gets filled with scatters is higher. I actually did the math, and in JNSQ you have 11x more DLC scatter than in stock. The stock scatters (i.e. the ones that exist for literally years without ever being enabled :P) solve this by not checking for subdivision level, but checking for the distance to the active vessel AFAIK. Of course I could probably hijack them somehow, but I would really prefer if Squad would fix their code to work better with rescaled systems. For a quick and dirty solution you have to disable the DLC scatters in your savegame (set ROCSeed to -1). Alternatively planet makers would have to finetune their subdivision settings for the DLC, but that might have other performance implications (because you need *more* subdivision)

1.7.3-1 is out, plus backports and Kittopia. Apart from recompiling against 1.7.3 it only contains a fix for the barycenter and selectable options, thanks to @Sigma88 Sorry for the long break and skipping one version, but I just had to get a break and do something else for a few days or weeks.

[Moderator's note: This thread has been extensively pruned due to off-topic kvetching about Kopernicus' version lock, after a moderator request to cease doing so. However, Thomas' comments here are particularly cogent, since he's the author, so this post has been left in place for future reference, after anonymizing the quotes involved.] The solution to the problem is removing the checker and maintaining it like every other KSP mod without version locking. However, for various reasons that I keep posting every KSP release, I am not willing to do that. If someone shows up and takes Kopernicus out of my hands I am heading for the airlock faster than you can blink. I am still maintaining it because - as you said - people depend on it and I don't want to leave them standing in the rain, but as for myself, I have lost almost any interest I have in KSP. I am not going to spend my time with user errors that happen because of obscure errors that a new version introduced. Fine. If you can tell me any way, how to properly unit test a blackbox that can change at any time (hint: KSP updates do that, rumors say), without knowing anything about how this blackbox changed, and that at runtime, every time the game is launched, without lagging it to death, then I will happily accept it. Given that this test doesn't end up being bigger than the entire mod. For those of you who don't know it: KSP's planets (and basically the entire game) consist of objects that are parented to each other, creating a tree-alike structure. Each of these objects can have multiple scripts attached that are executed each frame. What KSP does is storing a copy of one of these trees, with all planets parented to it. At some point in the loading process, it takes this tree, and searches it's children for a predefined planet structure, and spawns them into the planetary system. Those planet prefabs have multiple sub-trees, like the PQS object, the scaled space etc. etc., all of which are spawned into different trees at runtime. (ScaledSpace for example is seperated from the PQS so you can disable and enable them independently). Kopernicus edits this prefab tree and lets KSP spawn the planets, so they are spawned exactly like KSP would like to have them. Spawning them manually has been tried before (=> Planet Factory), and yeah, it is even more chaos than Kopernicus is. But the spawner just copies objects and restores some references, everything else is assumed to be correct. At runtime, KSP then assumes that some things exist, like certain components that interact with each other etc. That is not a problem for Squad because they know (I hope) how their planets work, and can adjust to changes. But because Kopernicus uses stock components all the time to build the planets, if it doesn't create or edit one correctly - or in the right place, everything can break and kill your savegame. For example, the colliders on the terrain are a component. If Squad would change the place where that component goes, Kopernicus would still add it in the spot that worked before, and none of your bodies would have terrain colliders. And you wouldn't notice until it is too late and you loaded your vessel which is now falling into the void. Of course this is all a huge oversimplification, but I hope it gets the point across. Actually, an even simpler example: It is like figuring out if a car works or not, without actually starting the car. Even if you are a top class mechanic, you will have problems doing this when your car is a huge gigantic blackbox, that you cannot open, and you don't even know whether it drives with gasolin or rainbows. When you only see the surface you have no idea how things work behind it, and therefor cannot test for it. There are people who can test unlocked versions of Kopernicus and do so. However, the moment I release unlocked betas, people will think (or want to think) that they are stable. People are not reasonable. 4 releases in one day is an obvious consequence of me touching every file of the codebase and being an idiot sometimes (=> forgetting to update my build scripts, see 1.7.0-2 ). Game breaking bugs can get catched by testing. If there are obvious errors in the loading process (as in: code errors instead of logic errors in the KSP blackbox), you get greeted with the same warning to not load your saves. Yes, we make errors too, and yes we don't catch everything. We are just humans too. But some testing feels better than none at all. You forget that Kopernicus can be used for much more than just visuals. I could install an entire galaxy in KSP and populate it, and still start from Kerbin. If I don't edit Kerbin, there is no change to the main menu kerbin. But if all other bodies stop loading (for example with Outer Planets Mod), every vessel orbiting them is moved to the trashcan. Again, try figuring out how that hypothetical car work without actually starting it and seeing if it explodes or turns into a pumpkin. So, we will probably never agree and thats completely fine. Maybe it is possible to unit test KSP. I don't know. But I don't have the time to care about it either. My solution works for me and seemingly the majority of the people. If it wouldn't work, people would fork it and remove it. Thats the beauty of opensource after all. [One final moderator reminder, folks. This post by the mod author has been left in place as a useful reference. Please do not attempt to respond or continue the argument. Thank you for your understanding.]

(so much for wanting nice code and changing every file of the code) 1.7.1-5 and the associated backports are out. Kopernicus shouldn't crash anymore when trying to load other bin files (crude solution, but it works for the moment I hope. I am just hoping there is no mod that stores 2GB bin files somewhere ), and I fixed two other issues, related to scaled space on demand loading, and the parser misinterpreting node names. These two bugs were never reported in public, so I won't go into detail on them. If you want to know what happened, check github.

Kopernicus tries to preload all .bin files in GameData since they are used for caching scaled space meshes. The only other mod that used .bin files that I was aware of was Kerbalism, and they mentioned that they changed their file extension, but aparently Trajectories uses the same code that Kerbalism uses. I will look into how this can be solved properly tomorrow and probably make another release then, but until then you can only remove the mod, sorry.

And there we have 1.7.1-4, lol. Does making so many releases give me extra points on the "Kopernicus is not working on new KSP version, please update yesterday" scale?

And there we have 1.7.1-3. I really hope that everything works now.

Nice, I didn't knew that! CKAN users shouldn't have problems then, I guess.

Aaand, expect 1.7.1-2 soon because my build server messed up and didn't update the version numbers. Sorry. EDIT: 1.7.1-2 is out. Have fun. Sorry again.

Release time! What was released: Kopernicus 1.7.1-1 Kopernicus 1.6.1-4 Kopernicus 1.5.1-6 Kopernicus 1.4.5-11 Kopernicus 1.3.1-20 KittopiaTech 1.7.1-1 Changelog: * refactored a large part of the codebase to align more with the coding style preferences in my IDE. This also includes merging the three core Kopernicus .dlls into one .dll again (+ Kopernicus.Parser). * Cache more properties of the generated scaled space mesh and preload them, to reduce the amount of calculations and disk IO that is done when loading planets * Reduce the amount of IO that is done by the logger * The `texture` and `normals` values from `ScaledVersion/Material` are no longer loaded on demand. If you want on demand loading for scaled space textures, you have to specify their paths inside of a `ScaledVersion/OnDemand` node, using `texture` and `normals`, just like before. * Allow loading `fogColorRamp` through a gradient instead of a texture * Abort loading planets if System.cfg was modified directly. There is no reason to do that except if you want to make your mod unremovable without breaking every other mod. Planet packs are supposed to use ModuleManager (I am looking at you, KerbalGalaxy Remastered) * Fix an error that prevented bodies with `invisible = True` from staying invisible, unless they templated the sun. * Take over the mesh generation / spawning for scatter meshes. Stock merges them into one big mesh which makes it impossible to detect their actual position, or give them sub-objects. Every scatter instance is now it's own dedicated object, which greatly simplyfies things. * Added a `HeatEmitter` scatter component that turns the scatter objects into a heat source. * Removed `ScatterExperiment` and replaced it with `ModuleSurfaceObjectTrigger`. It's a part module that can be added to parts, and enable / disable KSPActions when the vessel is near a surface object with a certain name (surface objects are scatters and PQSCity). It also sends events to all other PartModules on the part, so plugin developers could handle scatter with custom logic * Added a `useBetterDensity` option to the Scatter config. It tries to randomize the density a bit, and avoid rounding it down to an int like stock does. In stock, a scatter can either appear once (or more) per quad, or not at all. The idea behind useBetterDensity is to allow them to spawn, but not strictly on every quad. * Added a `ignoreDensityGameSetting` option to the Scatter config. If everything fails, this can be used to stop the density game setting from influencing your scatter, so you only have to find one density config that works. The scatter will be treated as if the game setting was set to 100% * Allow scatter rotation control through the `rotation` option. By default it is set to `rotation = 0 360` which means the scatter can rotate between 0 and 360 degrees. Set it to `rotation = 0 0` to fix the rotation * Allow specifying multiple meshes and randomly selecting one through the `Meshes` node in the scatter config. It can contain multiple entries (choose the key as you like), that point to .obj files in GameData. Kopernicus will load them all and assign one randomly to every scatter object that gets spawned. * Added a `spawnChance` option in the scatter config, that can be used to fine tune density even more. * The ScatterColliders component allows specifying a simplified collision mesh (.obj), through the `collider` option, as opposed to using the visual mesh for collisions * Added a scatter module that forces the scatters to spawn at sea level (with a settable offset), this can be used to create floating objects. * Readded the ability to set a custom mapMaxHeight for texture exports in Kittopia ATTENTION: This release will break plugins that depend on Kopernicus While the old files still work, it is recommended to regenerate your scaled space cache, to take advantage of the improved format and caching You have to adjust your configs to get scaled space OD working again Since this release reduces the amount of dlls that come with Kopernicus, you have to delete the Kopernicus folder from GameData before installing. Do not overwrite the folder. CKAN users probably have to uninstall and reinstall Kopernicus. DLC Surface Features: There is no need for Kopernicus to support adding or removing the surface objects from the DLC because they have their own config files in SquadExpansion/Serenity. Even if they would have to be managed through Kopernicus, I wouldn't actually want to add that, because it would fragment players between two similar systems (terrain scatters and surface objects), where one is behind a paywall. Thats why this release tries to make more use of the terrain scatters than before, with similar features to the DLC. Of course Squads code will always be more polished than this, and I think the DLC is absolutely worth it's price, but I like having an alternative.

precisely 2 weeks after 1.8 comes out. and everyone who demands answers that aren't silly is out of luck

Ok, so PSA: The next Kopernicus update will completely kill any plugin that depends on it (this means mods who interact with Kopernicus through anything except the config interface). The reason is that I did some really big refactoring to the code, so isn't full of warnings in my IDE and changed some of the more stupid choices I made in the past (like splitting Kopernicus into 3 dlls) The config interface is stable so far (and actually the new version might be able to load mods from pre 1.3.1-3 again, since I just deleted the config option that caused those bodies to error out - KSP always overwrites it with a default that I cannot change) - but I have some ideas that might require changes. When changes are neccessary I will post something about them. However, as previously said, all plugins that interface with Kopernicus or it's parser directly (i.e. the IC plugin, Sigmas plugins and so on) will need at least a recompile but probably some larger code changes. The logic didn't change, but a lot of parameter names did. If you need help with updating a plugin, feel free to ping me and I will see what I can do. I would appreciate if you could try (i.e. compiling the source code on github and checking if your plugin builds against it) before I release that version so that I can revert something before releasing it in case it is neccessary.

I am not going to revive this. It was made as a proof-of-concept mod, and while it still has concepts that I am pretty proud of, and that noone has re-used so far, I don't have the time nor the motivation to maintain it. Additionally, noone was ever able or willing to fill the PQS database to a reasonable degree, and I dont expect that to change. The ACCRETE based planet generation has lots of problems as well when integrated into KSP. If you want to revive and fork this, go for it, but I rather see this as a proof of concept mod that shows what can be done. If you want something that has reasonably active development, go check out To Boldly Go, but I am not sure how many planet-related features it has these days.