NathanKell

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 @[email protected]@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!

@[email protected] 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?

@[email protected] 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)

Can't repro. Just tried locally and it worked fine. Check your KSPCommunityFixes folder in GameData -- look in PluginData and open the DisalbeManeuverTool.cfg file--does it show the correct state in that? (Does the file even exist for you??)

What version of BDB do you have? The game is choking compiling the parachute and RCS part for the BDB Mercury.

@seyMonstershas a good tutorial RP-1 series that's worth a look! As to installing, it's very simply, just follow the steps here: https://github.com/KSP-RO/RP-0/wiki/RO-&-RP-1-Express-Installation-for-1.12.3 If you run into further trouble I highly recommend asking on the RO/RP-1 discord, folks can walk you through step by step.

Ah, I misread a previous quote. Then I'm not sure where the confusion is? RP-1 disables stock delta V. Because stock delta V is worse than useless when RP-1 is installed. So if you have RP-1 installed, you don't get stock delta V. If you uninstall RP-1, you should get it back. What's the actual question?

If RP-1 is uninstalled and the settings file has both related settings set back to true then it must be some other random mod because, well, RP-1 isn't installed

As siimav says it definitely does.

Procedural Parts 2.4.2 (which took advantage of KSPCF 1.22+) exposed a stock bug with the SaveUpgradePipeline, namely that it blew up if an upgrade script did not apply to both sfs and craft loadcontexts. I have now fixed that bug in: V1.22.2 Fix a stock UpgradePipeline bug where load context is not checked for upgradescripts before running them, which results in upgradescripts with the 'wrong' loadcontext breaking craft or sfs loading.

Turns out this wasn't a bug in Proc Parts, it was a bug in stock KSP--apparently no one else had yet written an UpgradeScript that used only one loadcontext (sfs) rather than both sfs and craft contexts. I've fixed that bug in KSPCommunityFixes 1.22.2, please download that and download Proc Parts 2.4.3. @NippyFlippers^

For anyone who didn't see, I've done a bunch of work speeding up reading and writing ConfigNode for KSPCommunityFixes, which significantly speeds up Principia saves and loads. If you haven't updated yet (or don't have KSPCF installed) I suggest you give it a try.

Because I can never get an initial release right, V1.22.1 is out. Add KSPAssembly attribute to MultipleModulePartAPI as well, and add the KSPAssemblyDependency to KSPCommunityFixes just in case. Set AssemblyVersion to 1.0 and only increment AssemblyFileVersion and KSPAssembly Refactor FieldData.WriteValue for ease in use by other mods.

V1.22 is released! New modding patch : ModUpgradePipeline [KSP 1.8.0 - KSP 1.12.3]. Further improve ConfigNode performance. The tunable settings blocks have been removed since base performance is high enough now. They've been replaced by a single setting that enables not indenting save games and craft files on save, which offers a slight performance boost reading and writing and a fair amount of savings on disk. See #90 for full details. Note that some of this rewrite is done via PersistentIConfigNode, which is now enabled by default. Add a KSPAssembly attribute to the dll. I should expand a bit on the Mod Upgrade Pipeline. It lets mods use the stock SaveUpgradePipeline for upgrading sfs and craft files, but instead of having to use KSP version numbers (and thus having to run every single time), KSPCF will save the version numbers of all loaded mod DLLs in sfs and craft files, and use those saved version numbers when running addons' UpgradeScripts. Note that if no version number exists (because the mod was not installed when the craft or game was saved, or because this feature was not enabled at the time), the version 0.0.0 will be passed to the mod. This defaults to off so mods are responsible for turning it on if they wish.

v1.8.5 released: * Fix exceptions closing and removing RT stations and on scene transition when detaching groundstations. * Fix exceptions trying to get debug mode state when in a scene transition.

I'll fix that last exception when I have a sec and release (if there hasn't been a KK release by the middle of the weekend, ping me! Currently busy shipping things at work...) As to the facility stuff...I don't know anything about the econ side of KK, do other bits of that work? We just use it for making the Cape (or other launch sites) look pretty and, err, extra-launch-siteable. :] My guess is the overlap between KK and RT folks is pretty minimal? I'd guess many RT folks who play stock-ish moved on to CommNet (and maybe Kerbalism?) But I'm really not plugged into the non-RO scene at all.