Jognt

There is a temporary bandaid patch in the Kopernicus thread that should work for stock and JNSQ. I’m here to look into GU to see what needs changing to make it compatible with that (if anything). What I’d like to know to tweak the patch is the name and template used for any celestial body that do not have an ocean, but do have a surface (not gas giants/stars). I’m not very Kopernicus-savvy so I patched by name. If you know an easier way to discern hasTerrain && !hasOcean, i’m all ears. cheers.

Scroll down a bit to the “the logs” section. Alternatively there may be a ModuleManager log in the KSP/logs dir. but I’m not 100% sure.

Actually, the Output.log notes what patches are applied to what and when. So you could open it up and do a search for “noseConeAdapter.cfg“ and anything that touches it before SFS is a likely culprit. It should narrow down the list quite a bit. @traisjames

Hard to say without the complete log. That type of error usually happens when mods interact with each other in a way that makes the patching process trip over itself.

Thanks for the feedback. I have a rough idea of what’s going on that I’ll check up on. In the meantime I recommend removing the patch and checking what @starwaster said to help with the ROCs. One request though; could you upload your output.log file somewhere and link it here? You probably did tell me. And I probably forgot or missed it. Whoops. I’ll do a quick 10x run this afternoon then

I don’t know how the file from @Diddly Feelerino is set up, but the patch I posted is supposed to go into a .cfg that you can throw anywhere in your game data folder with any name you want as long as you don’t overwrite something else. There are currently two issues with Kopernicus. The first is a significant impact on frame rate on/near celestial bodies that have no ocean. And the second being an excessive amount of garbage being created every frame. While the second issue is very inelegant, the only impact it will have is greatly increased Garbage Collection cycles, which you notice because the game pauses for s split second while it does that. The mods Heappadder and Memgraph can be used to increase RAM available for garbage to reduce the frequency of the stutter, but there is no impact besides that. (Both mods do the same, don’t run both in the same install) The first issue can have a huge impact on game performance depending on the power of the CPU used and the amount of parts active in the scene. It is this performance problem that the patch is made for. (Because it happens when there’s no ocean, the bandaid solution is to give everything an ocean. May cause graphical glitches) The ROC count issue reported by for example @Starwaster is one I have not been able to replicate so far. I’ve asked him if he had been able to narrow it down to a subset of mods, so if he gets back to me on that I may be able to help check that out. If you’re seeing that problem too, be sure to note stuff like the amount of loaded quads and features shown in the alt+f12 menu, Breaking Ground, surface features, tick Enable ROC stats gathering. You may have to save/load to see values) If I missed something, just @mention me as I’m on mobile which isn’t very well suited for proper reading

Do you have a screenshot? I’m on JNSQ so I can’t vouch for stock, but I haven’t spotted any obvious oddities on Mun/minmus there (yet). @Galileo considering your experience with creating/modifying planets, do you know of a tweak for the current bandaid-patch to minimize side-effects? Im guessing that if the patch causes glitches it’d be due to the ocean being at the same height as the flats on MinMus, but I know far too little about planets to say. Kopernicus is on CKAN. You will have to set some of the older KSP versions as Compatible for it to install since (I think) ModularFlightIntegrator not being flagged for being 1.7.3 compatible.

Looks like you're missing the PART declaration. You can add that, or give these a go (also copy pasted from the original CFGs, but cleaned up a bit). The Radial one should work. The wedge variant _should_ work too, but I removed some stuff related to size switching since I don't think we can dynamically adjust the amount of slots it has anyway, and I haven't yet been able to check how that impacts the part. Let me know how they turn out if you're going to try 'em. Edit: @MrWizerd I've updated the CFGs to have the same cost, mass, and capacity as the stock container. The Wedge part is now also correctly 2 units high as intended. The model selection appears to be disabled due to some bugs, but I don't know whether those are a KIS/KAS thing or a US thing, so I left that limitation in there. Though this means you'll need two wedges to fit 4 slots. You do correctly get the 3 inventory slots now similarly to stock though.

EVA report: “Well we really did need that spacesuit to get here after all! Or at least the helmet..”

My apologies for the off-topic, but I giggled at your comment for how appropriate it sounded for a Dating for Geeks book. Carry on

I don’t know @Flupster his thoughts about it, but you can always use the MM patch I posted earlier in the thread to replace the DMScienceAnimate modules with DMScienceAnimateGeneric modules. Seems to work fine so far. The parameters are equal for both modules as far as I can tell. Note: DMScienceAnimateGeneric is a separate mod install. (Also does nice visual things with ReStock science parts when installed)

Any chance to take a quick look at the code for DMagic's science module? I noticed that DMScienceAnimateGeneric experiments work flawlessly with x science, whereas the DMScienceAnimate ones don't. Perhaps a typo somewhere?

More RCS quads on the bottom, the build aid window says you have [a lot of] torque. Or move the top quads closer to CoM so they don’t have as much leverage.

There’s a mod on CKAN called Xenon ISRU that does exactly that

If -like me- you were looking for bigger planets for bigger rockets while still keeping fuelmanagement simple like stock, you can remove RR. JNSQ works fine and Ore is returned. No fancy rethinking of how it’s distributed sadly though. (Reading your comments is like skipping back to when I found out the exact same thing )

The only one I’d not recommend is Universal Storage. And that is because there is a Universal Storage II that is simply amazing. So yeah, that list still looks good to go

As long as it ends with “.cfg”, it’s all good.

Many packs simply haven’t been (officially) updated. Many packs also have unofficial patches to fix bugs though. I recommend reading the last 2-3 pages of a pack’s thread to see what the latest ‘news and happenings’ around it was.

Stock, Kopernicus, 10x ReScale, right? If so, I’ll check later to see if I can reproduce it. Keep in mind that the lower Terrain Detail settings actually increase ROC count in less quads:

I’d set the 16GB amount to 2GB, but maybe I’m overestimating how many big mods people use. (memgraph is set to 512MB locally, with 16GB ram, and running Dx11, and my ram still hits 15,5GB after long VAB sessions. I manually removed IVAs for some big mods to free RAM, but I would be surprised if anyone else with 16GB didn’t experience this too.)

There's a temporary patch a few posts up if it's the same problem. (probably is?)

I wouldn’t go much higher than 2gb padding tbh. For one, a modded KSP can easily use 10GB, and windows can use several GBs for some users that run ‘stuff’ in the background. Ignoring that bit, the reduction in GC intervals is pretty good even for 0.5-1GB. If not, then the user probably has mods spamming garbage that is better off being reported than hidden. ( Kopernicus currently creates a LOT of garbage when having a medium amount of parts in the scene ) Going for 4-8GB on 16GB systems IMO is asking for trouble since most end users will take it for granted and run into lots of pagefile thrashing. TL:DR: I suggest not going higher than 2GB with the note that end-users can increase the amount based on how much free memory they have when playing KSP, with the recommendation to keep ~10% of total RAM free

Plenty of stuff (like the game itself) is rated to run on default settings. Anything custom means “you’re your own support”. If the problem occurs on a stock fresh install however, that’s a different story.

I’d start with making sure you have the dependencies (CTT is one). If that doesn’t help you can upload your outputlog.txt file.

There are some minor outstanding bugs, but they dont impact the mod’s function so its still functional.