Jognt

Also added a step-by-step for the non-MM inclined Im not sure what version was linked for download (wasn’t me), but that post of mine has the most recent patch @Thadeasaurous1 Ping for relevance. (Kopernicus performance issue)

I know this isn't exactly a 'solution', but you could do a MM patch that adds a ModuleCommand MODULE to the science container. That might be enough to work around it.

TL:DR -> That message is harmless. FPS problem is due to another bug. Link to temporary fix in my signature. Link to step-by-step instructions in the linked link.

I saw you got it sorted, there's a step-by-step on how to do it 5 posts above yours on this page though. Well if you manage to actually splash down you can probably complete them. If you've found some spots of water, be sure to take a selfie. You could even start a hypetrain by posting said selfie on the internets saying "Look, I found water!", without saying why the water is there . (But that'd be a bad person thing to do I think )

*Looks at mod licenses* *Sees a thing called ARR* Gee I wonder what would happen if someone were to poke it..

PBC also alters science multipliers for celestial bodies, so one of them will have their changes overwritten. (Or PBC will alter bodies that don’t exist, I don’t know GPP but that still wouldn’t cause problems afaik) Overall, it’ll work fine and without errors though.

Cheers! Glad it's sorted now Edit: A side effect of that patch is that you will get contract offers to "Splash down in the Mun's Oceans" or similar. Be warned, you can't complete these (though you're welcome to try). Just a heads-up so you're not scratching your head wondering where that came from.

Copy everything from the first @ to the last } (so everything in that grey block); Open a text editor; Paste it in there; Save it as something like Kopernicus1731TempFix.cfg (name isn't critical, just name it so you remember what it is. Just make sure it ends in .cfg); Place the newly created file somewhere in your KSP/GameData folder (I'd make a new folder that contains your personal custom patches, name is not important, so GameData/mycutelittlepatches/fixFile.cfg would work); Done! As long as that code is in a file that ends in ".cfg", and that file is somewhere in your KSP/GameData folder, it'll work. You can/should remove the patch if/once Kopernicus updates as it won't be needed anymore then.

I understand why you’d make that correlation, that message is harmless though. The reason you’re getting that slowdown is most likely due to a known bug in Kopernicus. I think work on a fix is underway, in the meantime there’s a ModuleManager patch in the last few pages that should alleviate most of the slowdown. Edit: I placed a link to the patch in my signature. Not sure if it shows for old posts, if not, there’s a link one page back by me.

Uhm, I know Apollo saved mass where possible, but I think they did bring supplies. Edit: From experience I can tell you that 666 supplies is not enough for three Kerbonauts to do a round trip comfortably (with station rendezvous). You'll still have control on return, but they will be 'starving'. I'd aim for ~300 supplies per Kerbal. You should be fine then even with the 1541m/s slow-mode trip.

Very hyped for KSP2! Micro transactions are a dealbreaker for me though (I know my weakness, so does my bank account). Let’s see what we’ll get next year

Check to make sure the Kopernicus folder is gone. Sometimes parts linger and cause problems.

Place your sats when the Mun is there if they’re safe then, they’re safe always. (In keosync anyway)

The panels get changed by Kopernicus, so there’s nothing this mod can do about that. There’s a patch in the Kopernicus thread to work around the FPS problem though so I suggest you use that. Edit: I assumed the rover worked fine before and that the amount of generated power should be sufficient, but somehow wasn’t generated anymore. As Maja suggested, if the problem is just that there’s more power needed than available, just turn off some wheels.

Backup just the config, delete the folder, install the New one, make sure that the New config file has the same lay-out and variables as the old one. Or remember your settings, delete the old mod, install the new, and set it up again.

Probably there from pre-1.7 kopernicus. 1.7 kopernicus recieved a major refactor which (among other things) unified everything in the one .dll so it’s possible these weren’t removed when the folder was overwritten.

For anyone else that noticed the performance impact: I’ve traced it back to EVE nuking my Physics Time Ratio, which meant even a tiny bit extra would cause simulation time to be exceeded. So if you’re noticing SCANsat lagging your game hard, it’s probably a symptom of another mod misbehaving.

Ah yes. If the copy was done before ReStock initialized it’s parts, it’ll fail because the copy contains the old info. What I mainly meant is that an end-user shouldn’t need to worry about whitelisting stuff for another mod, because if the mod needs it, the author will (probably?) do the whitelisting As always, anything I say will have terms and conditions attached that may or may not be stated in the post itself

Squad used to be an advertising company afaik, so it’s not so much modern as it is a concequence of ‘learning as you go’.

Uhm, did you test in a clean install? I could swear bon voyage works fine in my JNSQ (and thus Kopernicus/MFI) game. I’ll double check later.

What module(s) do you look for? ModuleEngineFX?

Most mods will whitelist something if they need it. ‘Stock assets’ are things like models. Lets say a mod copied the Terrier engine, that copy will now look like the ReStock model unless you whitelist the old model and point your copy there.

With regards to NREs, I see them quite often with stock robotics too, so that could be a KSP thing.

It appears that the log-in to bitbucket is being blocked by my iPhones safari contentblocking, so i’ll Report 2 bugs here before I forget: 1. Minor - The 2.5m core generates a slight thrust torque when every side is occupied by the same part. (Place all LF wedges, still torque) it’s only 0.01Kn, but it bugged me. 2. Major - when Resource Transfer Obeys Crossfeed Rules is enabled, parts below a US core cannot Crossfeed back up IF the bottom node of the core was populated in an earlier session. Build a craft from a probecore -> tank -> US core -> tank. Launch it, Crossfeed works fine. Revert to assembly, launch it, Crossfeed does not work. I checked the craft files and noticed that the bottom node loses its assignment, so whatever is below it is seemingly attached to nothing. Edit: both issues tested in a clean up to date install with just US2 and KER (for the torque readout) Remembered to properly do this once I got home this time. Bugs have been added to the tracker.

Considering Kerbalism replaces all the functional modules from those parts with their own, they are perfectly welcome to support DBS But thats just my view on it