NathanKell

This is fixed in 1.20.1 V1.20.1 is out Available from GitHub and CKAN. Changes in that release : Fix an issue with the DoubleCurve patch Fix a stock issue where PartModules added via code would have a null upgrades List (would result in broken part tooltip in 1.20.0)

It's in your KSP folder. It's where all game settings are saved.

Fixed. In prior versions, CC had a special hacky way of formatting body names when placed "bare" in a string that took the displayName but stripped the Lingoona decorators off of that value. I've now restored that behavior while still leaving the DisplayName() method which will give the full, decorated displayName. This should fix the behavior you described, which is because GPP changes the display name of Kerbin to be Gael and Sun to be Ciro while leaving their actual underlying names untouched. (RSS also does this, because KSP gets very upset if the homeworld isn't named Kerbin, so we have to just change the display name instead). 2.1.4: - Return to legacy behavior for CelestialBody names when used without a function; Name() will report the actual name and DisplayName() the Lingoona-decorated name as in 2.1.3 however. This should preserve legacy contract behavior while still allowing Lingoona formatting going forward. - Change last remaining uses of CurrencyModifierQuery that didn't go through RunQuery

RP-1 turns off stock delta V (since it's very, very wrong for RP-1). You can turn it back on in your settings.cfg file. Find (and set back to true): DELTAV_APP_ENABLED DELTAV_CALCULATIONS_ENABLED

CONTRACT_TYPE { name = contract1 tag = Group 1 Contracts ... REQUIREMENT { name = AcceptContract type = AcceptContract invertRequirement = true tag = Group 1 Contracts } ... } CONTRACT_TYPE { name = contract2 tag = exclusiveGroup ... REQUIREMENT { name = AcceptContract type = AcceptContract invertRequirement = true tag = exclusiveGroup } ... } Will ensure that you can only have one of the two accepted at any time. (Note it had a bug for accept, though not complete, which I fixed just now.) You could also do loc, so instead do "tag = group1" and then somewhere else: LOCALIZATION { en-us { #cc.contracttag.OfType.group1 = of type Group 1 Contract #cc.contracttag.bare.group1 = Group 1 Contract } } This should now be fixed, the decorators will only be added with .DisplayName() calls for bodies and Kerbals (and FirstName() / LastName() calls for Kerbals).

The local metadata was outdated and thus confusing. As the release makes clear, and this thread, this is for everyone. I've now fixed the metadata.

I've updated v2.0's changelog to reflect the pre-RO changes.

@KraterKreatorapologies, didn't know about that. It was a trivial fix to get around this issue, and I've released 2.1.2. Ah I see what's going on. Looks like @nightingaledid merge some PRs but never made a release of 1.30.6. I'll update our changelog and I can look at that, although I'm not sure quite what the best fix is. Cheers!

Changelog is also in each release page on github, though most of the changes were in 2.0 (but ignore the "RO only" thing since it was fixed in 2.1). I built against 1.12.3 but I don't see why it wouldn't work for 1.9? And most of the thanks go to @siimav(and @Gotmachinefor finding the leaks).

We've adopted CC to perform some maintenance (performance and bugfixes) and add features, but it's entirely compatible with non-RO KSP now so it should be a strict improvement over 1.30.x.

Given how much work it was....yes, but not by me!

Huh. I had no idea the slider flipped, I'll edit my post. Although that will obsolete your excellent reply? EDIT: Linked to your reply along with the edit, so all should be well.

Awesome, thanks. I removed the Parallax config but missed that that subdivision PQSMod was also being added. Cheers!

Question about Parallax and EVE. Is there any way to disable Parallax completely for a body (i.e. Earth) such that the z-fighting with the city lights doesn't occur? (But still leave it enabled for all other bodies!)

For real stuff you probably want Realism Overhaul. Since I started working on it a bit over eight years ago, "a long time ago" fits.

What tanks are you talking about there? Though I highly recommend using only procedural tanks (or Modular tanks, from ROTanks) instead anyway.

Yup, that sounds wacked. I don't know how any of the KK code works, except the build errors I fixed to get things running on 1.12, but I can try to take a look this weekend and see if anything turns up.

Looking at the log, it looks like what's going on is Kopernicus is loading a crapton of maps, and that causes things to die (you can see this at the bottom, where it loads map after map and then keels over). Assuming things do work correctly if you use the same modlist but remove (only!) KK, then my hunch is that KK requires things to not be loaded on-demand (which is usually how Kopernicus saves memory when you send it a crapton of planets with hirez assets), which is probably pushing you over. How much memory does this machine have, and how much RAM was free before launching KSP?

Released v1.8.3 for KSP 1.8+ with the fix for 1.12.

Sweet! Thanks for testing, folks! I'll make the release this evening.

Ok, so the version of Unity used by KSP 1.12 finally hard-deprecates GUIText, it looks like. I replaced it with the suggested replacement (UI.Text) and recompiled, and it seems to work. Can you please test this? If it's good I'll make a release. https://www.dropbox.com/s/z191mfy69u2w31f/KerbalKonstructs.dll?dl=1

If you are playing in sandbox, enable "Enabled All Part Upgrades in Sandbox" in your difficulty settings. PF diameter limits are set via upgrades, and for some reason Squad defaults to leaving that option defaulted to off in difficulty settings, meaning your diameters are locked in sandbox.

You have "1.11" or "1.12" or both checked as compatible versions in CKAN and ended up with a version of Real Chute that is incompatible with 1.10. The same might be true for other mods. Make sure you have no compatibility overrides set in CKAN and try a clean install again. @OnlyLightMatters

Fixed thanks

Yep, though I'm sure HebaruSan will get you sorted out. My guess is that it's either due to a permissions thing (having KSP installed in Program Files, which has some weird permissions stuff, so try copying your KSP install out of there, pointing CKAN at the new location, and trying again), or due to somehow having a program running that is accessing that file (either KSP itself, or maybe Steam, or another CKAN instance, or I dunno what). I highly, highly recommend getting that sorted out and using the express install option.