Tellion

It should (someone correct me if I am wrong) come out to 9143 kg/m³

It is also possible to use MapDecals to apply high detail to a certain area via a specific height- and colormap. Borisbee's Sentar Expansion does that, even with Olympus Mons iirc. Granted, that would hardly make every part of the planet interesting, but it might be of interest to you nonetheless.

The system that ought to be a binary is blank which is accompanied by serious NaN exception spam. I am somewhat at loss as to the cause, especially as earlier versions of SigmaBinary did work without issue (a few months back, that is). After trying things with BEFORE and such I noticed that it also occurs with 64k and OPM only, no custom configs applied whatsoever, so it seems that the cause lies within the 64k configs themselves - no idea what specifically though. Maybe numbers get applied after letters by MM?

Finally found the time to update the OPM configs for 64k - you can get them here: https://github.com/Tellion/OPM_64K I did not notice any severe issues, however it seems that the atmospheres of the gas giants are quite dense even in their upper regions which makes aerobreaking relatively rough. Also, 64k and OPM seem to be gamebreakingly incompatible with SigmaBinary for some reason - this happens without any custom configs as well. No idea why this is happening, maybe some problem with the MM priorities... I also removed the AVP configs as those weren't all that useful in the first place.

My bad, I moved to github and must have deleted the original configs in the process. This should work with the latest 64k, but I haven't had much time for testing recently, so please do write me a pm if it doesn't.

Does the issue with the black edges occur without any other mods? Without EVE, specifically?

If you are feeling adventurous, play around with the maxLevel setting in the PQS Node, set it to something between 6 and 8. If you search for the term in the Kopernicus thread, some examples should turn up. Maybe that helps with the sinking issue.

Sure, but I think there is no need for that - using RSS values from the corresponding planets works perfectly fine

Even if this is unrelated, the issues OPM has with FAR atm are fixable by using correct values for adiabaticIndex. Right now, it has the same value as atmosphereMolarMass and that is a little too far off for FAR to deal with.

RSS does !Body,* {} before creating everything from templates and maps, so I think you had some error in the config. Using Tylo's maps by pointing the config to BUILTIN/whateverthename should also be possible without issue.

Yeah, probably not. @Kopernicus:AFTER[Kopernicus] { !Body[Tylo] {} Body { name = Tylo Template { name = Duna } } } Would be the procedure I imagine.

What about using a different template and copying whatever PQSMods you need from Tylo?

Regarding the terrain, if you did not do anything that would specifically cause this it won't be so easy to get rid of it. Is this present in stock? I imagine it would be, albeit to a much lesser degree... Regarding the scaledspace problems, delete the bodyName.bin file from the Kopernicus cache, or wherever OPM stores them if they are moved, then try again.

agreed, but you can't escape the noise without dedicated maps - it is also quite visible for some of the stock planets. KSP can do quite a few things with regards to terrain, but it's no match for dedicated terrain generation programs.

If you would be up for some testing, try setting maxLevel to 12 in Serran's .cfg file and try again. Ash: This might be the same issue I mentioned in the IRC.