Thomas P.

That's exactly the problem that is solved by the Scaled Space - at a certain distance the PQS fades out and gets disabled so only a handful of spheres are active at the same time. And since PQSMods are the only way to shape planets in KSP (heightmaps are also just PQSMods), there is no alternative anyways What is your opinion about a C# version instead of a Python version if I may ask? This would make this: way easier since Stellarator (and it's dependencies, namely the reimplemented PQSMods and parts of the Kopernicus code) is already written in C#.

Well, to be honest nobody is forcing you to follow the thread instead of focusing on development. Just stop replying unless you have something DD related to post. An escalation like this always involves two parties.

logs.

I would like to chime it on the topic of generating custom bodies. Some of you might know that some time ago, I started a project called "Stellarator" (Even before TBG was released IIRC). While TBG started with generating a whole galaxy, Stellarator focused on generating an actual planetary system. Stellarator solved the problem of generating an actual surface by having a set of PQS configuration templates. Theese templates contain a set of PQSMods that can generate terrain using noise and other methods (VertexPlanet for example). These template configs are special, since their values can contain variables and calculations (unlike regular Kopernicus configs). For example, the seed values of the PQSMods are dynamic and depend on the seed the user entered when running the program. Another feature was, that it generated a random color for the planet, that could be used together with different manipulation methods (For example to generate a brighter or darker color). And you had a way of generating a new random number using the seed, and either calculate with it or just assign it to the respective value. While loading the configs these expressions were evaluated, so every PQS template could produce an infinite amount of actual planets. The intention behind this was, that a human could create a planet that looks good, and then figure out which values could be changed, and which ones were neccessary to produce a result that has the same look and feel - as opposed to just throwing together noise functions and getting planets that might be totally wonky. Also, by using the PQS the program can simply rely on the tools and the API KSP and Kopernicus expose anyway, and not invent something totally new. The problem with this approach, as with probably any approach, is that you have to generate the ScaledSpace textures. They are always static, and there is no good way to generate them ingame without lagging the users PC to death. In Stellarator I solved this problem by rewriting the PQSMods and the Unity and KSP classes they need independent from KSP. Stellarator then used the Kopernicus Loader to convert the PQS configuration that was generated into a stack of PQSMods, just like they would exist in the game, and used this data to pregenerate the textures. That took a bit of time, but in the end you had a completely procedural solar system. But since Stellarator never took off, and I am a noob at actualy planet making, I never had the time to write the PQS database. I made three example configs, but thats it. Since TBG took off and got reasonably popular, I would like to propose that the planet generation concepts could be merged into TBG and developed further (I would totally like to help with that as soon as I got the time - I also have some magic for gas planets lying around, lol). I think it's just sad that my old code is lying around with me having no motivation to work on it, while it could help somewhere. And I simply like the idea of procedural generating a solar system that actually works and is not just a proof of concept. The only problem with that is, that every type of terrain generator would make the current code completely unreadable. The planet generation, and also the difficulty to work with it that daniel mentioned, would really benefit from rewriting it in a different language, probably Python (easy to read and write) or C# (most stuff for the planet generator could be taken from Stellarator). But of course thats your decision. If you are interested in my proposal, feel free to leave me a message, either on the forums or on the Kopernicus Discord.

Thats because Kopernicus isn't british It just never parsed that and used the default instead.

ambientColor = 0.4,0.4,0.5.1.0 ^ There is your problem, you need a , there, otherwise it isn't a valid color for KSP.

3.0 wasn't released at the time I released 1.3.1-3 and I am not going to make an update just for a new MM version when the one that is shipped still works.

Oh, he can keep his suggestion. It is useless since Kopernicus doesn't use the version file (actually no mod does - thats just visual stuff for the KSP-AVC users). The version checking is baked into the dll and unless you know what you are doing it is impossible to remove it. Actually on the topic of backports: I did backports in the past and it was an utter pain. Also, back then, Kopernicus could use pretty much the same code between both versions (1.2.2 and 1.3). This changed with 1.3.1, since now for example sunflares are handled fundamentally different and it would be even more work to port everything back to how it worked before. So sorry, I am currently not going to do backports again.

And thats totally fine, but it is always better to use the stucture of the dependencies. You only interface directly with KSS, so you should ask the KSS dev first. Either it is an error you made yourself (then its an easy fix), or it is something you as the user cannot control. If the KSS dev now has no idea how to fix the bug with his configs, they should go to the Kopernicus thread and ask for help. Why the KSS dev you might ask? Because they know their work and know what we mean if we ask them about PQS, ScaledSpace and so on. In the best case the bug has been resolved at this point because the Kopernicus thread can help the planet maker to fix his bug and they publish a new release If it is not possible for the planet maker to fix the bug with his configs, either Sigma or I (or anyone else) searches the reason for that in the Kopernicus code. Again, in the best case we find it and push a new release or publish a workaround because we don't have the time at the moment. If the failure doesn't happen in the Kopernicus code, we first check the dependencies (i.e. MFI), or go and check said functionality in KSP directly. If it is possible for us to fix it, we do it, either with a change that we submit to the author (i.e. sarbian) or we invent a hacky workaround. If a fix is not possible we add a warning to the OP and the download that said functionality is broken and you need to avoid it (reparenting Kerbin, renaming Kerbin or the Sun, etc.) This might sound harsh, but always blame the first part of the chain first, because it is easiest. Not easiest to blame them, but easiest to find and fix the bug. And if the bug is unexplainable to you don't try to figure out what's going on. Leave that to the modders. I mean, it is nice when others (try to) debug our mods for us, but that's exactly what we're there for.

Crossposting my reply from the MFI thread here, because I feel it is important. Stop right there. So neither the assumtion that this is a bug is true, nor that this is caused by MFI. MFI does nothing to starlight or shadow rendering. If any mod should be blamed for this it would be Kopernicus. But it isn't Kopernicus fault, at least not directly. This bug is based on the (wrong) assumption that the distance parameter of Kopernicus Intensity Curves (for local space and scaled space) use the same distance units, which is not true. But it kinda was the default behaviour because of a stupid bug that I didn't notice. (the one intensity curve overwrote the other, so they effectively had the same distance units). This bug was fixed in the latest Kopernicus Release, and even though the correct behaviour was documented multiple times in the Kopernicus thread (and even the bug was posted there), planet makers still didn't change their curves (they could do that, because one curve wasn't used at all - it would have had no influence on their stars). I am not blaming them though because Kopernicus documentation is a true hellhole. The only one who deserves blame is me because I messed this up, and didn't notice this for months. But also generally speaking: I find it truly astonishing how many users claim to know exactly which mod causes the failure they are experiencing and straigtly blame the authors of said mod. Don't get me wrong, the reasons for doing that are good, you want to help fixing this bug etc., but you simply aren't the one with the experience here. If you would have the experience to figure out what exactly causes the bug you could go on, fix it yourself and submit the fix to me, sarbian, or whoever else. TL;DR: Planet packs need to fix their intensity curves to work with Kopernicus 1.3.1-3, and you should blame me, not sarbian or the planet makers.

Stop right there. So neither the assumtion that this is a bug is true, nor that this is caused by MFI. MFI does nothing to starlight or shadow rendering. If any mod should be blamed for this it would be Kopernicus. But it isn't Kopernicus fault, at least not directly. This bug is based on the (wrong) assumption that the distance parameter of Kopernicus Intensity Curves (for local space and scaled space) use the same distance units, which is not true. But it kinda was the default behaviour because of a stupid bug that I didn't notice. (the one intensity curve overwrote the other, so they effectively had the same distance units). This bug was fixed in the latest Kopernicus Release, and even though the correct behaviour was documented multiple times in the Kopernicus thread (and even the bug was posted there), planet makers still didn't change their curves (they could do that, because one curve wasn't used at all - it would have had no influence on their stars). I am not blaming them though because Kopernicus documentation is a true hellhole. The only one who deserves blame is me because I messed this up, and didn't notice this for months. But also generally speaking: I find it truly astonishing how many users claim to know exactly which mod causes the failure they are experiencing and straigtly blame the authors of said mod. Don't get me wrong, the reasons for doing that are good, you want to help fixing this bug etc., but you simply aren't the one with the experience here. If you would have the experience to figure out what exactly causes the bug you could go on, fix it yourself and submit the fix to me, sarbian, or whoever else. TL;DR: Planet packs need to fix their intensity curves to work with Kopernicus 1.3.1-3, and you should blame me, not sarbian or the planet makers.

The only way to do that would be to change the file extension of the dll and using the new one in the DllImport attribute. But it is safe to ignore the error message in the log, KSP won't try to mess with the native DLL. (Principia is the best example)

Kopernicus 1.2.2-11 is the last version I published for 1.2, you can get it here: https://github.com/Kopernicus/Kopernicus/releases/tag/backport-1.2.2-11 The features are those of Kopernicus 1.3.0-6, so a bit outdated and probably bugged

So, long time without anything from me here... But now my exams are over and I am back. Over the last month there were two pretty important changes to Kopernicus and I think I should finally release them. So here is Kopernicus 1.3.1-3 (Download link in the OP): Changelog: - Kopernicus now tracks vessel orbits using a custom identifier (for example a GUID) instead of the FGI. The identifier is loaded from the "identifier" option in the Body node. If no identifier is specified, the body name is used. This should make it possible to install or remove planet packs mid-game without messing up all of the orbits. IMPORTANT: Make a backup of your save before installing this version! - Fixed IntensityCurve and IVAIntensityCurve. Their values were never used. - Updated the MFI .version file Have fun.

Actually, the license you chose clearly states that he can do whatever he wants with your work as long as he gives credit to you.

Because we are legion Jokes aside, I would say it is used to lead the one who reads the code a bit and "talk" to them, and probably because you we want to include possible contributors too.

That is already possible, you just have to do it properly. You can install multiple planet packs and modify them with Module Manager. In fact, this already has been done in Galactic Neighborhood by @Sigma88 which works pretty good. With some good hardware, some time, and GN, you can get an installation featuring about 200 planets and some more stars. If you don't want to have the same bodies everyone else has, I will allow me a small self-advertisement here and recommend my own mod Planetary Diversity What I want to say is, that all of this has been done already, and there is absolutely no need for removing planets at runtime. I am sure that someone could get that to work, but tricking KSP into spawning a body is hard enough, telling it to forget about it entirely is probably nothing anyone wants to spend time on.

Because removing a planet while having KSP started is like removing a wheel while you are driving

Well, showing us what you are doing exactly (i.e. posting your config) would be a good start.

meanAnomalyAtEpochD is based on the epoch value, that is set here: https://github.com/KSP-RO/RealSolarSystem/blob/master/GameData/RealSolarSystem/RSSKopernicusSettings.cfg The D is really just a shortcut for "degrees" (meanAnomalyAtEpoch uses radians).

The ban on System.IO was lifted a long time ago, so you should be able to use it like in every other C# based project.

I released Version 1.3.0-4of Planetary Diversity, you can get it on GitHub (Link in the OP). Changelog * Ported @Sigma88's namegenerator from Stellarator to PD * Various fixes for all tweaks * Added an atmosphere toggle tweak, that can add and remove atmospheres (This is the biggest update for PD so far.) Note: This release works with both, 1.3.0 and 1.3.1 Another note: Running GN with all supported planet packs and PD is really fun, if your Computer has got enough power (16 GB RAM minimum) Have fun.

Hello again (and sorry for doubleposting), I released Version 1.3.0-3 of Planetary Diversity, you can get it on GitHub (Link in the OP). Changelog * Added a tweak for atmospheric pressure and temperature * Fully recolor gas planet atmospheres Note: This release works with both, 1.3.0 and 1.3.1 Have fun.

Add this to your Body node: Debug { showSOI = true } ----------------------------------------------------------------------- In other news: For the past days @Sigma88 @GregroxMun @Gameslinx and myself have been working on setting up an official Kopernicus Discord Server. It is meant to be some kind of central hub for Kopernicus planet makers to exchange ideas, post pictures of their WIP stuff and also learn new things. We also want to move the development chat that is currently on IRC to Discord. One of the main reasons for creating this server is, that the entry barrier for Discord is way lower than for IRC, and real time chat is often better for supporting and teaching new features than a forum thread. And it is easier to stay up-to-date with the backlog, because you don't have to setup stuff like an IRC Bouncer if you don't want to miss anything. Anyways, I am bad at describing things. So, if you are interested, just check it out! The Invite link is: https://discord.gg/Q2bnQ7N

From your second error.log: I don't think thats enough to run KSP with mods. Maybe a computer reboot will help?