[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[theJesuit]

 

1 hour ago, TaintedLion said:

Is there any way I can stop parts that have a B9 part switch module from resetting back to their defaults when installing this mod?

I don't seem to have this problem.  Can you explain further?

[TaintedLion]

7 hours ago, theJesuit said:

I don't seem to have this problem.  Can you explain further?

Whenever I install this mod, any in-flight craft I have that have switchable parts with a B9 module (like BDB parts with alternate colour schemes or engine types) will reset back to the first option.

[AtomicRocketBooster]

Just started playing around with the CommNet Throttling patch based on some things I was seeing in the debugger, and I'm seeing some really impressive performance increases - on the order of 10fps! I have a ton of relays and active ships - probably ~100.

Are there any known issues with just enabling it by default, or are they just theoretical? I have yet to encounter any issues on my heavily modded install with an unpacked delay as high as 30s. I have to imagine that it's very rare that losing comms 30s later than you might have would have any measurable impact on gameplay - most comms issues would be when you're landing, messing around on the surface,  or performing maneuvers while shielded by a celestial body, which all would usually take on the order of minutes

Edited August 19, 2022 by AtomicRocketBooster

[Rodger]

Something I'd really love is for non-engineers to be able to drop parts in EVA construction. Keep the engineer requirement to attach parts, but c'mon, anyone can drop a parachute!

[theJesuit]

24 minutes ago, Rodger said:

Something I'd really love is for non-engineers to be able to drop parts in EVA construction. Keep the engineer requirement to attach parts, but c'mon, anyone can drop a parachute!

Given the way Jeb flies i really don't want to drop my parachute.  Quite the opposite actually.

[JonnyOThan]

On 8/19/2022 at 5:55 AM, TaintedLion said:

Whenever I install this mod, any in-flight craft I have that have switchable parts with a B9 module (like BDB parts with alternate colour schemes or engine types) will reset back to the first option.

Sounds like it might be related to the partmodule index patch?  If you disable that patch, does the issue go away?

Edited August 20, 2022 by JonnyOThan

[TaintedLion]

Just now, JonnyOThan said:

If you disable that patch, does the issue go away?

How do I disable that module?

[JonnyOThan]

23 minutes ago, TaintedLion said:

How do I disable that module?

Open up the settings.cfg file and change this line to false: https://github.com/KSPModdingLibs/KSPCommunityFixes/blob/af1dfc5d7958488e8b2117a7a4720fa97ad46d6e/GameData/KSPCommunityFixes/Settings.cfg#L37

[Gotmachine]

On 8/19/2022 at 11:55 AM, TaintedLion said:

Whenever I install this mod, any in-flight craft I have that have switchable parts with a B9 module (like BDB parts with alternate colour schemes or engine types) will reset back to the first option.

Please provide logs, and ideally also your save file and module manager cache. Ideally use KSPBugReport for that.
I doubt this is directly caused by KSPCF as this would have been widely reported, in any case I didn't manage to reproduce it.
This is likely some peculiar corner case in your specific modded setup.

[TaintedLion]

13 hours ago, JonnyOThan said:

 If you disable that patch, does the issue go away?

I disabled it and my issue has gone away.

12 hours ago, Gotmachine said:

I doubt this is directly caused by KSPCF as this would have been widely reported, in any case I didn't manage to reproduce it.

Well I disabled one of the patches and the issue went away, so idk, sounds to me like it was caused by CF. I actively avoided installing this mod because that bug destroyed one of my old saves, but somehow it became a dependency for some of the other mods I use, so I had to find a way to make this work, but it's fine now.

[JonnyOThan]

34 minutes ago, TaintedLion said:

I disabled it and my issue has gone away.

Well I disabled one of the patches and the issue went away, so idk, sounds to me like it was caused by CF. I actively avoided installing this mod because that bug destroyed one of my old saves, but somehow it became a dependency for some of the other mods I use, so I had to find a way to make this work, but it's fine now.

If you can reproduce this easily, please provide the info Gotmachine mentioned and we can hopefully get this fixed.

[swjr-swis]

Ok, I am really hoping someone here sees merit in my request this time.

Context: KSP 1.12.3, stock + both DLC, no mods of any kind (but it's an issue that I see happen even in stock 1.3.1, and it has existed in all versions in between).

Reproduction: Pegasus 4 Lux  or Pegasus 4 Mk2G (before it was renamed and uploaded). Download it, launch to runway, and try engaging flaps by toggling RCS. Look at left and right wings. The problem should be evident: one of the mirror-symmetric control surfaces is deploying in the wrong direction. Inverting deploy direction is no use, because then the other of the mirrored pair will be deploying wrong. Their symmetry is still mirror, not radial, but deployment is not obeying that.

That craft has gone through a whole series of iterations, all the while being flown and tested several dozens of times in both my game and Hotel26's. He finally settles on this last one for upload. I empty the SPH, and specifically because of this issue, try one more time loading the craft and launching it to double-check, and it all works correctly. Satisfied, I send the file, Hotel26 publishes it to KerbalX, and .... the uploaded file is crapped.

I restart my own KSP hoping the original is still good, reload the craft... and the control surfaces are deploying in opposite directions, just like the uploaded craft. So it crapped out *after* I had checked it worked, after which I made no changes to the craft whatsoever.

So TL;DR, my plea then: is there any chance at all that someone please, please, fix the piece of code that keeps randomly flipping the deployment direction of control surfaces?

 

Some more context, in a spoiler because... well, levels of frustration:

Spoiler

I don't even mean the one that -sometimes, but not always, of course not always- happens in mid-flight when CoM 'transits' through the extended longitudinal axis of the control surfaces, usually affecting roll. I guess the two issues could be related somehow, but this is not the one I mean.

I mean the one that happens on planes that have previously been working perfectly fine, both in the SPH and in flight, and then simply RELOADING OR LAUNCHING THAT EXACT SAME PLANE, without having made a single change to it, results in one or more control surfaces deploying incorrectly. It does get triggered more often by saving after changes, which is rather inevitable, but frustratingly enough also happens without changes or entirely without saving too. Just loading, or launching, can trigger it.

For absolutely no reason whatsoever, suddenly KSP decides that flaps are not longer deploying downward, for example. Nothing touched, just reloading a previously saved and used plane, or even from a working situation in the SPH, launching and on the runway the deployment direction gets flipped. Revert and now in the SPH it is also flipped. This is actually the slightly more tolerable variant of the issue, because the workaround (almost muscle memory by now) is to ALWAYS visually verify control surface movement before take off, and be prepared to right click and invert the deployment when needed.

Sometimes though -of course just sometimes, not always- it decides to make MIRRORED horizontal control surfaces deploy in OPPOSITE directions, as if they've been attached in radial symmetry - except the craft file keeps showing them as mirrored. Again, no changes to the craft, simply reloading, or launching - worked perfectly before, suddenly screwed up. In that situation those control surfaces basically become unusable, and the problem is incorrectable as both of the mirrored parts flip when inverting the deployment direction of either, leaving them always in a broken configuration. If that state somehow saves to the craft file, which seems to happen by simply launching to the runway, the only thing to do now is to remove that part entirely and reattach a NEW one (using the same one just gets you the same), and hope the settings stick for a while.

I still find it unpredictable when this is going to manifest itself, but use (not even edit/tweak, simply USE) a plane often enough and eventually it'll start happening. It's added another one of those muscle memory things with KSP, training myself to always double-check before taking off and 'invert' if it happens.

If I sound a bit frustrated... I have no words to explain how much.

Does it sound like something that could be corrected in this fix pack?

 

 

Edited August 25, 2022 by swjr-swis

[NathanKell]

 

V1.21.0

Got's busy atm so I'm handling the release this round.

• New performance / KSP bugfix patch : PQSCoroutineLeak (issue discovered by @Gameslinx) [KSP 1.8.0 - 1.12.3] Prevent KSP from spawning multiple PQS update coroutines for the same PQS after scene switches and on other occasions, causing large performance degradation over time.
• Fixed the ToolbarShowHide patch partially failing due to an ambigious match exception when searching the no args `ApplicationLauncher.ShouldItHide()` method overload.
• PersistentIConfigNode patch : added support for nested Persistent IConfigNode, see associated PR (@NathanKell).
• New performance patch : ConfigNodePerf (@NathanKell) [KSP 1.8.0 - KSP 1.12.3] Speeds up loading and saving of ConfigNodes and allows skipping processing on certain known-good keys (like Principia's serialized data). This has yielded up to an 8x boost loading from/saving to disk in testing (although much of the expense remains serializing/deserializing the actual objects involved, not just reading and writing ConfigNodes from/to disk). This applies to all confignode parsing/saving, including loading into GameDatabase, MM loading/saving the cache, sfs and craft files, etc.

Edited August 26, 2022 by NathanKell

[Rodger]

9 hours ago, swjr-swis said:

Ok, I am really hoping someone here sees merit in my request this time.

Context: KSP 1.12.3, stock + both DLC, no mods of any kind (but it's an issue that I see happen even in stock 1.3.1, and it has existed in all versions in between).

Reproduction: Pegasus 4 Lux  or Pegasus 4 Mk2G (before it was renamed and uploaded). Download it, launch to runway, and try engaging flaps by toggling RCS. Look at left and right wings. The problem should be evident: one of the mirror-symmetric control surfaces is deploying in the wrong direction. Inverting deploy direction is no use, because then the other of the mirrored pair will be deploying wrong. Their symmetry is still mirror, not radial, but deployment is not obeying that.

Just a possible work-around, but have you tried the 'Remove From Symmetry' option in the PAW on the flaps, to unlink them from each other, so you can invert one and not the other?

[swjr-swis]

5 hours ago, Rodger said:

Just a possible work-around, but have you tried the 'Remove From Symmetry' option in the PAW on the flaps, to unlink them from each other, so you can invert one and not the other?

Yes, and it does work as a workaround for the reason you explain. As a stop-gap in an emergency oh-I-don't-have-time-to-revert-and-redo-let's-just-finish-this-mission kind of situation, it would help.

Going forward though, with that plane, you lose all benefits of symmetry, while the problem will continue to manifest itself. So now you have DOUBLE the checks (and potential corrections) to perform, every time you use the plane, while trying to remember that each control surface has to be adapted individually when you make any changes on the editor/template version.

In the case of the Pegasus shown, that line of planes has a years-long history, spawning multiple models, and nothing says it wouldn't go on to many more. All the while, now one would be forced to constantly work the control surfaces individually, in any changes made and in checking/verifying the plane before launching. I would hate to saddle @Hotel26, or any of the players downloading his plane, with that kind of a legacy cave at. And that's just one (line of) plane(s)... of many, many others.

Just to be clear: the input is appreciated, and yes it is a workaround, just not one you want to have to rely on, for either one's own planes or for tweak work you do for others.

[Jason Kerman]

Hi! Is there a way to force disabling the maneuver tool using MM patch?

[Rodger]

8 hours ago, Jason Kerman said:

Hi! Is there a way to force disabling the maneuver tool using MM patch?

Yep:

@KSP_COMMUNITY_FIXES:FINAL
{
	@DisableManeuverTool = true
}

 

[JonnyOThan]

1 hour ago, Rodger said:

Yep:

@KSP_COMMUNITY_FIXES:FINAL
{
	@DisableManeuverTool = true
}

 

Note I'm pretty sure all this does is add the OPTION to disable the maneuver tool into the settings window; you still need to go in there and turn it off.

[mhoram]

I would like to suggest the following MM-cfg-file bugfix to be included into this package.

@PART[ServiceModule25]
{
    !node_stack_core_A1 = dummy
    !node_stack_core_A2 = dummy
    !node_stack_core_A3 = dummy
    !node_stack_core_B1 = dummy
    !node_stack_core_B2 = dummy
    !node_stack_core_B3 = dummy
    node_stack_coreA1 = 0.0, 1.4, 0.0, 0.0, -1.0, 0.0, 1
    node_stack_coreA2 = 0.625, 1.4, 0.0, 0.0, -1.0, 0.0, 1
    node_stack_coreA3 = -0.625, 1.4, 0.0, 0.0, -1.0, 0.0, 1
    node_stack_coreB1 = 0.0, -1.4, 0.0, 0.0, 1.0, 0.0, 1
    node_stack_coreB2 = 0.625, -1.4, 0.0, 0.0, 1.0, 0.0, 1
    node_stack_coreB3 = -0.625, -1.4, 0.0, 0.0, 1.0, 0.0, 1
}

Before creating a pull request, I want to evaluate, if this is a patch that you would consider including into the KSPCommunityFixes or if there is a better place for this fix.

This patch fixes the stock bug that using undo (ctrl-z) in the editor can cause some nodes of the ServiceModule25 to become unusable.

A video of this happening for a different part can be seen here. My detailed analysis for this fix is available here.

I would appreciate feedback about this.

[NathanKell]

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.

Edited September 9, 2022 by NathanKell

[NathanKell]

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.

[internerd]

I think the latest release is preventing me from loading craft. Whenever I try to load craft the game becomes unreponsive and I have to restart.

When I check the log, I notice there is this repeated over and over and over.

Quote

[SaveUpgradePipeline]: Test Module ProceduralParts 2.1 Bezier Cone Upgrader KCT-GAME/SCENARIO/KSC/VABList/KCTVessel/ShipNode/PART does not apply for Craft loading! 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript ShapeBezierConeUpgrade from assembly ProceduralParts, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript MECEngineConfigUpgrade_KCT9 from assembly RealismOverhaul, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript MECEngineConfigUpgrade_KCT8 from assembly RealismOverhaul, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript MECEngineConfigUpgrade_KCT7 from assembly RealismOverhaul, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript MECEngineConfigUpgrade_KCT6 from assembly RealismOverhaul, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript MECEngineConfigUpgrade_KCT5 from assembly RealismOverhaul, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript MECEngineConfigUpgrade_KCT4 from assembly RealismOverhaul, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript MECEngineConfigUpgrade_KCT3 from assembly RealismOverhaul, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript MECEngineConfigUpgrade_KCT2 from assembly RealismOverhaul, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript MECEngineConfigUpgrade_KCT1 from assembly RealismOverhaul, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript MECEngineConfigUpgrade from assembly RealismOverhaul, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript PatchFilesProcessor from assembly KAS, using version 0.0.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[KSPCommunityFixes] Testing UpgradeScript DeprecateAdapterAndResizer from assembly ProceduralFairings, using version 1.0.0 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

I actually left my PC running for a while to see if it fixed it and it was still frozen but the logs were now gigabytes in size. The log is here. https://www.dropbox.com/s/kil4yy1egw3pxqk/kspcf.log? 

If I downgrade KSPCF to version 1.21.0, I don't have this issue.

[NathanKell]

1 hour ago, internerd said:

I think the latest release is preventing me from loading craft. Whenever I try to load craft the game becomes unreponsive and I have to restart.

When I check the log, I notice there is this repeated over and over and over.

I actually left my PC running for a while to see if it fixed it and it was still frozen but the logs were now gigabytes in size. The log is here. https://www.dropbox.com/s/kil4yy1egw3pxqk/kspcf.log? 

If I downgrade KSPCF to version 1.21.0, I don't have this issue.

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.

[JonnyOThan]

On 9/9/2022 at 1:48 AM, NathanKell said:

Set AssemblyVersion to 1.0 and only increment AssemblyFileVersion and KSPAssembly

Hmm, does the AssemblyFileVersion get printed in the logs?  It's really annoying when mods leave their version at 1.0 and then you can't tell what someone installed.  But maybe they're not using AssemblyFileVersion.

[siimav]

3 hours ago, JonnyOThan said:

Hmm, does the AssemblyFileVersion get printed in the logs?

It does in the ksp.log at least.