Jognt

Most mods had it, you can check out SimpleFuelSwitch or other mods for how they fixed it. Edit: @Paul Kingtiger while using US II I've come across some quirks and oddities here and there. Mostly minor nitpicks regarding part weights, resource transfer, and slight inconsistencies vs Stock. Would you like me to list those here/add them to the tracker? I ask because it's not a small amount, I fully understand some of them being personal balance preference vs actual bugs, and I don't wish to flood you or the tracker . (and because I'm lazy, and it's easier to motivate myself to list them if I know the recipient would appreciate it )

It’s a purely graphical glitch due to recent changes to the Part Action Window. If you click outside of the window and select that part again it’ll show the right values/type.

You know your work is solid when the ‘bugs’ are caused by accidentally leaving the debugging enabled.

It would work yes. But you'd have a controller active for every wheel, which may cause unforeseen problems. Here's my personal patch that just adds the BV module to the Rovemate and Landercan: // Small patch to add the Bon Voyage control module to the Rovemate and MK2 Lander Can. // Author: Jognt @PART[roverBody_v2|mk2LanderCabin_v2]:AFTER[BonVoyage] { MODULE { name = BonVoyageModule } } By the way, by using AFTER you do two things: ModuleManager will only execute the patch if BonVoyage is present (Like NEEDS); ModuleManager will run the patch right after BonVoyage's FOR pass; That way you don't need NEEDS and FINAL, since both the timing and conditional is present in the single AFTER.

The default.

Some do, not all though. The deprecation process is just that: a process. Basically: Anything in zDeprecated OR clearly shown as deprecated can be removed in future updates. The folder thing is separate from that since it was done during a file structure reorganization, and not a deprecation AFAIK. Thats also why ReStock has that message: everyone has the same ‘deprecated’ parts, but only old installs have those old folders.

Now that you mention it, I had that once with the 1.25m shroud and the Atmospheric Fluid Spectrometer. Do you get this with every DM experiment and with every shroud?

If you mean the orbital Science mod parts, they work fine for me. Are you using a mod to activate the experiments like [x] Science? Because that mod has problems with them that the maintainer for some reason doesnt feel like responding to. Using the regular part action menu should work fine. Are you using a mod to activate them?

With JNSQ it was around 150 km? I only saw it once when I returned from minmus, since I was timewarping I didnt quite get the exact altitude.

I have similar problems with JNSQ since 1.7.3, maybe something changed in KSP?

Yup it’s for all scales, stock included. Fun side-effect: you may get a mission offer to splash down in the Mun’s Ocean.

Looks like the old Rovemate model with an OKTO on top.

Wow.. You actually.. did the math.. That's... a lot of antennas.. .. ... .. Yeah that antenna techtree placement could probably use a bit of a checkup!

Admittedly it was more of a "Theoretical" than a "Practical" thought. I kinda wonder how many you'd need and what it'd look like now though.

I agree that the antennas seem just a bit ‘up’ in the tree. Just remember that the C-16 is infinitely combinable.

Reduce braking strength on the rear gear by 50% and keep an eye on the nose gear. KSP ‘simulates’ inertia by simply applying torque when you brake. So each rear wheel is essentially compressing the front wheel when braking. This means the nose gear is easily overwhelmed and starts to drift left/right. Esit: keep an eye on the front wheel. If the little ‘ankle’ bottoms out: reduce rear brakes further, increase spring on the front wheel, or add another front wheel.

Don’t forget ModularFlightIntegrator. It’s a dependency for Kopernicus.

Can confirm.. 30km above Mun on 10x rescale with just Kopernicus, SigDem, ReScale, and the temporary Ocean{} fix and this is what I'm seeing: https://imgur.com/a/jUeQ4Hj Output log: https://www.dropbox.com/s/q3v8amwe4qjtx3h/30km_Orbit_Mun_10x_Scale_Save_output_log.zip?dl=0 Complete save: https://www.dropbox.com/s/2xmomw7lt07xh6r/30km_Orbit_Mun_10x_Scale_Save.zip?dl=0 Reproduce: 1. Install KSP; 2. Install Kopernicus; 3. Install SigmaDimensions; 4. Install ReScale (10x); 5. Copy the "complete save" data over to the fresh install; 6. Set KSP to "High" Terrain quality preset; 7. Load up the "10x 30km above Mun" save; 8. Enable the ROC data gathering and optionally the ROC locator; 9: Behold your puny framerate and the massive amounts of ROCs showing, even though you're way up and going at 1762m/s. This is not supposed to be a thing afaik. Is Kopernicus doing anything specific that would override the distance/speed limitation on ROCs?

The sudden smooth gameplay when you get 350m away from your lander isn't strange at all. In fact, it's the exact behavior I was seeing when I arrived in this thread. What CPU/speed are you running? Because technically, you shouldn't be having smooth gameplay on a body with no Ocean{} without the patch when running kopernicus I'll get off my behind and finally tweak the patch for GU, I've done most of the thinking, just need to put it into actual work done. Testing the FPS is best done with the same save, craft, location so everything is equal and you aren't comparing different parts/locations etc. Many people couldn't repro the FPS problem I had. It was 4x4Cheesecake who checked out my save and confirmed the problem. Which was probably due to me using structural plates to make something look nice which increased the part count to where the problem became noticeable. Oh, and thanks for the mention. I kinda feel popular. Edit: @Aelipse With some help from @StarCrusher96 I updated the anti-FPS-loss-on-some-planets MM patch so it should just work for every planetpack/whatever. Visual glitches may apply, I'm guessing that happens when the terrain itself is at 'sea level' so the terrain and newly added Ocean fight for dominance to show themselves. If someone knows how to tweak it further so even that side-effect is gone, sharing is caring Having said that, Kopernicus received several commits in recent days, one of which is aimed at resolving this problem, so perhaps the patch isn't needed anymore soon™. Be sure to remove the patch if you're using it once Kopernicus updates. Link to patch:

Its saying it didn’t find those variables in the game’s module Part. Basically “hey I found this in the part CFG (small p) but I can’t find a reference for it in the Part module (large P)”. You can ignore those warnings as long as you’re using them for personal purposes and don’t expect the game to actually recognize them. Edit: here’s the API for the Part Class. It’s logical that it can’t find your variable there, because it’s yours https://kerbalspaceprogram.com/api/class_part.html

Thanks I never quite got the rank and money for a ‘vette, but you're right, she’s gorgeous.

Uhm. Wouldn’t a stand-alone canopy fix all that? Just the canopy itself, radially attachable to whatever you want. Then you can turn any part into a cockpit.

Maybe it’s getting confused about being ‘landed’ on the sea floor vs ‘splashed down’? What if you try floating? Edit: either that, or you need to go further. Your location and situation there is landed on the shores. So it’s either the situation, or the location.

Laythe? Not Jool? that’d require some creativity though the mod will still work, just verry laggy without new Kopernicus or the patch.

Cheers thanks. What template/name did you use for gaseous bodies/stars? (may be more practical for an exclusion patch instead of inclusion)