NathanKell

I'd say it's well worth PRing in the rescaled KSRSS configs for now just so we have something, and you're the one who knows how they should be set best for RSS. I mean, I can try, but I don't know 'em as well.

Would you kindly PR these (and also later the forthcoming ones of course) to RSS? Please? It's sitting right here, waiting

The issue is that other systems in KSP (buoyancy, thermo) use drag cubes. So FAR being installed or not is irrelevant here. And as you can see in relevant issue on github leading to drag cube generation patching being disabled, one of the specific symptoms was a vessel (and its orbit) not appearing in map view, nothing to do with aerodynamics.

Workaround released.

Oh it's also possible that RemoteTech just doesn't use the correct KSP interfaces when displaying time, i.e. the bug could be there rather than in Kronometer (and yeah that sounds like what I'm thinking of). Good luck! Cheers.

I have a vague recollection that Sigma wrote a generic version of that? Not sure. Think someone did. Worth digging around the forum and CKAN to see if someone's already done what you want. Cheers!

Are you thinking of this?

1.30 is out. DragCubeGeneration : disabled by default since it continues to cause issues with fairings and some other parts. Will be reenabled by default when issues are fixed. New KSP bugfix : FixGetUnivseralTime [KSP 1.8.0 - 1.12.5], fix Planetarium.GetUniversalTime returning bad values in the editor.

Also: If modders aren't using the ModUpgradePipeline...please consider it, since you can write UpgradeScripts based on your own mods' versions with it.

Fixed a bug in the Mod Upgrade Pipeline where it would rerun on every load. 1.29.2 is out.

Released 1.29.1 to fix https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/152 -- it's a general issue with ConfigNodePerf and ConfigNode.CopyTo where stock doesn't recurse with 'overwrite' enabled and I was, leading to nodes that could not have duplicate value names.

Did you maybe forget to tool? That's insanely expensive.

RP-1 v2.0.0 - The Programs and Launch Complexes Update is now available on CKAN! The best option would be to create a completely fresh install of KSP, and then use CKAN to select the RP-1 Express Install. Alternately (but more complicated), would be to use CKAN to uninstall the RP-1 Express Install and then reinstall through CKAN. Make sure to select RP-1 rather than RP-1 (Legacy) when prompted. This is a massive update and is a completely different way to play RP-1 from what many of you are used to, read the changelog here to see everything that is different: Programs is a new way of playing RP-1, where contracts are grouped into overarching Programs. Use the Administration Building to select your starting Program(s) and go from there. You will only have access to the contracts appropriate to your current Program(s), and those contracts will only reward rep (and sometimes Confidence, a new currency). Income comes from your programs' budgets, though you also get a large subsidy (towards salary and other maintenance costs). This subsidy increases year-over-year until the mid-60s, and varies based on your current reputation. The existing VAB/SPH build queues are replaced with Launch Complexes. The player can have any number of launch complexes, and LCs have size, mass and resource limits. The Hangar is a special case of LC. You can now appoint (and fire) certain historic Leaders. These leaders offer bonuses and penalties, and new slots unlock as you advance in your career. For a longer overview, see The PLC Conversion Guide This will be the new version of RP-1 going forward and the previous versions will be "Legacy" (deprecated), and will no longer receive updates. A ton of time and effort has been put into this new version of RP-1 and we are excited for it to be released. Further development will continue and we expect the experience to keep improving over time. Enjoy! The RP-1 Team Please install via the express install Release info on GitHub

Always nice to come to a post and find the problem already solved.

The versioning is listed in the readme, but I edited the post above to show it there too.

V1.23.0 New performance / KSP bugfix patch : RestoreMaxPhysicsDT (contributed by @JonnyOThan). KSP 1.8.0-1.12.3. Fix typo in Strategy's SendStateMessage where bold was not disabled after title (as part of StrategyDuration fix, since that is the only place it would be used in stock KSP). Fix bug in ConfigNodePerf where it did not properly early-out of parsing if the cfg file had an extraneous } (stock parser aborts in that case). Added Chinese localization (contributed by @tinygrox).

Assuming one of you kind folks verifies it works for you too (it worked for me in dev mode), I'll release tomorrow (well, today).

Here is a test of the forthcoming release. Please verify it fixes your problems @CAPFlyer@Carni35@610yesnolovely https://www.dropbox.com/s/xllxh2ymchwrl0x/KSPCommunityFixes_1.23.0.zip?dl=1

Ok I've tracked the problem down. The Reflection.cfg file in BDBNIC has a ton of extra } in the middle of the file and somehow KSPCF1.22+ responds differently to those errors than stock does. Fixing. Thanks for narrowing this down!

@Carni35@CAPFlyerawesome work narrowing that down, but maaaan that's bonkers. AFAICT from the spacedock download of BDBNIC all it does is patch some part variants (and add some new assets), it doesn't touch any part with a RealChute module (let alone the part that's erroring in the log).

Hmm. Those files are identical. I think there might be something else going on here, because I'm not sure what you might have had installed that would set PersistentIConfigNode to true in the 1.21 cache, so I'm wondering if the cache wasn't regenerated when swapping versions? Did ModuleManager *say* it was re-applying the patches?

@CAPFlyer@Carni35Not seeing anything obvious, so...gonna make a request that'll take a bit of work. Please: (a) in your working game (i.e. with old, or no, KSPCF installed), load all the way to the main menu and then quit, and copy out your ModuleManager.ConfigCache. (b) Install latest KSPCF and do so again (until it hangs) and copy out *that* ModuleManager.ConfigCache. (c) upload both files. I will need to manually compare the resultant nodes in both files in the hopes that will give a clue. Clearly RC is failing to parse the PARACHUTE node in the mercuryRCS part, but I don't see how.

@RaketeJust tried what you mentioned and KSPCF happily created the file. Only thing I can think of is your KSP somehow doesn't have write permissions in that folder. (Also you have an outdated version of Kerbal Konstructs.) Create a new file in that folder and call it DisableManeuverTool.cfg and put this in it: DisableManeuverTool { enableManeuverTool = False } (make sure it's actually a cfg file, not .cfg.txt by the way).

The value is stored in that cfg file. I don't need MM cache because that cfg file is under PluginData and thus not managed by ModuleManager. KSP.log is right next to your KSP executable. If the value in the cfg is true, that means KSPCF is saving it to disk as enabled, which means either it's being reset or it's never being saved correctly in the first place. Please try the following: 1. Launch KSP, load a save, toggle the setting, apply, accept, and immediately quit KSP. Then give me the log and the cfg file I mentioned (and check its properties, make sure it's not read-only). 2. Make a clean install of KSP and add only KSPCF to it (use CKAN to install it so it gets all dependencies). Then repeat step 1. Oh that's very interesting, just saw your edit. I'll double-check that it properly creates it.

Actually what would be most helpful is your ModuleManager.ConfigCache file. Then I can compare the ConfigNodes generated by KSPCF and by stock KSP's loader. (And btw KSP.log is superior to player.log, player.log has a lot of excess junk and lacks some data KSP.log has)