[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[Hotel26]

4 hours ago, swjr-swis said:

I emptied the tanks

Although you haven't stated it explicitly, my thesis would simply be that KSP dynamically figures where control surfaces are wrt to the CoM to decide whether they are nose or tail.  It might have to do this simply due to docking and undocking, for example.  But that also makes this vulnerable to the CoM shifting in flight, when particular surfaces are only just 'nose' or 'tail'; but then switch as the CoM betrays them.  (So I'm guessing you already subscribe to the same thesis.)

I could see one fix being to simply lock them into their SPH/VAB initial function -- as long as there is no docking/undocking.  And yes, I have built flying machines that fly long-distances fast as a tandem couple; then the nose splits off to function as a low-speed, low-range, VTOL-capable 'rover', using the tail as a base (fuel and accomodation); cargo planes that have a nose-mounted cargo but the cargo plane is designed/required to fly after despoiting the cargo; etc etc.  In most circumstances, surfaces are in definitive positions nose/tail and not vulnerable, or when a reconfiguration occurs, the dynamic change does make sense.

I could always be wrong.  I haven't lain awake long at night thinking about this one.

Edited December 13, 2023 by Hotel26

[swjr-swis]

5 hours ago, Hotel26 said:

Although you haven't stated it explicitly, my thesis would simply be that KSP dynamically figures where control surfaces are wrt to the CoM to decide whether they are nose or tail.

It's a good consideration and I know KSP's penchant for flipping control surface action in-flight as CoM shifts 'past' their hinge-line. This is however not what is at play here, and the example craft I linked shows this.

• The bug manifests itself in the second elevon2 from the front. If it had flipped because of CoM shift, the first one would/should have flipped as well.
• Were CoM shift the cause, filling the tanks to default status would flip them back again, which does not happen. (*)
• Repositioning the entire wing assembly -with all elevons- back and forth was attempted and had no effect on their deployment status.
• Even if all the above were not the case, it would still not explain, nor could it be correct behaviour, that mirror-symmetric parts suddenly deploy in a radial-symmetric manner (one up, one down), instead of mirror-symmetric (both up or down).

*: I'm not even addressing here the other bug where KSP is completely inconsistent about what deployment direction a control surface defaults to, even in a series of otherwise identical, often even copied, parts.

Edited December 13, 2023 by swjr-swis

[Hotel26]

1 minute ago, swjr-swis said:

penchant

outright bug then?

[JonnyOThan]

Right, there's a common complaint from novice players that "their control surfaces are going the wrong way" because they don't understand the CoM thing.  I don't think that's what's going on here, but without repro steps it will be next to impossible to fix.

There's a complex state machine in the editor related to affecting symmetry-placed parts, swapping offset and rotate tools, etc.  There's probably just a bug buried somewhere in there.

*Maybe* the craft file will have a clue about where to look (I haven't investigated it yet).

[Manul]

5 hours ago, JonnyOThan said:

There's a complex state machine in the editor related to affecting symmetry-placed parts,

Mirror symmetry has always been buggy as hell, some parts (like triangular structural panels) can not be placed in mirror symmetry at all. They just deny symmetry and align themselves asymmetrically no matter what.

[JonnyOThan]

KSPCF 1.34 is now available!

• New KSP QoL/performance patch : LowerMinPhysicsDTPerFrame : Allow a min value of 0.02 instead of 0.03 for the "Max Physics Delta-Time Per Frame" main menu setting. This allows for higher and smoother framerate at the expense of the game lagging behind real time. This was already possible by manually editing the settings.cfg file, but changes would revert when going into the settings screen.
• New KSP QoL patch : BetterEditorUndoRedo : Invert the editor undo state capturing logic so part tweaks aren't lost when undoing.
• New KSP bugfix: InventoryPartMass : Fixes bugs where parts stored in inventories would not have the correct mass or volume when their resource levels were modified or variants changed.
• New KSP bugfix: EVAConstructionMass : Fixes a bug where picking up a part in EVA construction would set its mass to the wrong value when mass modifiers are involved (e.g. part variants).
• New KSP bugfix: RespawnDeadKerbals : When respawning is enabled, starts the respawn timer for any dead kerbals (changing their state to "missing") when loading a save. This addresses stock bugs where kerbals could be set to dead even when respawning is enabled.
• New KSP bugfix: ZeroCostTechNode : Fixes a bug where parts in tech nodes that have 0 science cost would become unusable.
• New KSP bugfix: ModulePartVariantsNodePersistence : Fixes an issue with ModulePartVariants where attachnodes would use their default state when resuming flight on a vessel from a saved game. This would lead to different behavior in part joints and flexibility between initial launch and loading a save.
• Changed patch behavior: PAWGroupMemory now tracks group state globally instead of per-window.
• Added zh-cn localization for ManufacturerFixes.cfg (thanks @zhangyuesai)

[Overlocker96]

There's some bugs with PartVariants since the new update. For example engine variants and such works fine, but engine plates or adapters with variants that change it's nodes, display all the models and nodes at once, and the change variant part of the PAW simply disappears.

Here's my log (I have a ton of mods but this only happened after updating KSPCF): KSP Log

[JonnyOThan]

1 hour ago, Overlocker96 said:

There's some bugs with PartVariants since the new update. For example engine variants and such works fine, but engine plates or adapters with variants that change it's nodes, display all the models and nodes at once, and the change variant part of the PAW simply disappears.

Here's my log (I have a ton of mods but this only happened after updating KSPCF): KSP Log

Thanks for the report. Can you post the log here?  I’m on my phone and can’t seem to download it from your link.  Also would be nice to see if it repros without your mods, or figure out which of the KSPCF patches causes it (you can disable individual patches in the settings.cfg). https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/189

[Overlocker96]

I had just tested the same config and mod list, but disabling the ModulePartVariantsNodePersistence patch, and I'm sure it was it.

Here's the relevant part of the log, it repeats for a lot of parts:

Spoiler

[WRN 22:36:18.060] [KSPCF:ModuleIndexingMismatch] Part "engineLargeSkipper.v2" configuration has changed. Synchronizing persisted modules...
[WRN 22:36:18.060] [KSPCF:ModuleIndexingMismatch] Persisted module "FXModuleLookAtConstraint" at index [9] moved to index [10]
[WRN 22:36:18.060] [KSPCF:ModuleIndexingMismatch] Persisted module "FXModuleThrottleEffects" at index [10] moved to index [11]
[WRN 22:36:18.060] [KSPCF:ModuleIndexingMismatch] Persisted module "FXModuleThrottleEffects" at index [11] moved to index [12]
[WRN 22:36:18.061] [KSPCF:ModuleIndexingMismatch] Persisted module "ModuleColorChanger" at index [12] moved to index [13]
[WRN 22:36:18.061] [KSPCF:ModuleIndexingMismatch] Persisted module "ModuleColorChanger" at index [13] moved to index [14]
[WRN 22:36:18.061] [KSPCF:ModuleIndexingMismatch] Persisted module "ModulePartVariants" at index [14] moved to index [15]
[WRN 22:36:18.061] [KSPCF:ModuleIndexingMismatch] Persisted module "HotSpotModule" at index [15] moved to index [16]
[WRN 22:36:18.061] [KSPCF:ModuleIndexingMismatch] Persisted module "ModuleWaterfallFX" at index [16] moved to index [18]
[WRN 22:36:18.061] [KSPCF:ModuleIndexingMismatch] Persisted module "ModuleB9PartSwitch" at index [17] has been removed, no matching module in the part config
[WRN 22:36:18.061] [KSPCF:ModuleIndexingMismatch] Module "ControllingRecoveryModule" at index [9] doesn't exist in the persisted part, a new instance will be created
[WRN 22:36:18.061] [KSPCF:ModuleIndexingMismatch] Module "ShipEffectsCollisions" at index [17] doesn't exist in the persisted part, a new instance will be created
[WRN 22:36:18.061] [KSPCF:ModuleIndexingMismatch] Module "RSE_Engines" at index [19] doesn't exist in the persisted part, a new instance will be created
[WRN 22:36:18.061] [KSPCF:ModuleIndexingMismatch] Module "ModuleEVARepairs" at index [20] doesn't exist in the persisted part, a new instance will be created
[WRN 22:36:18.069] [KSPCF:ModuleIndexingMismatch] Part "engineLargeSkipper.v2" configuration has changed. Synchronizing persisted modules...
[WRN 22:36:18.069] [KSPCF:ModuleIndexingMismatch] Persisted module "FXModuleLookAtConstraint" at index [9] moved to index [10]
[WRN 22:36:18.069] [KSPCF:ModuleIndexingMismatch] Persisted module "FXModuleThrottleEffects" at index [10] moved to index [11]
[WRN 22:36:18.069] [KSPCF:ModuleIndexingMismatch] Persisted module "FXModuleThrottleEffects" at index [11] moved to index [12]
[WRN 22:36:18.069] [KSPCF:ModuleIndexingMismatch] Persisted module "ModuleColorChanger" at index [12] moved to index [13]
[WRN 22:36:18.070] [KSPCF:ModuleIndexingMismatch] Persisted module "ModuleColorChanger" at index [13] moved to index [14]
[WRN 22:36:18.070] [KSPCF:ModuleIndexingMismatch] Persisted module "ModulePartVariants" at index [14] moved to index [15]
[WRN 22:36:18.070] [KSPCF:ModuleIndexingMismatch] Persisted module "HotSpotModule" at index [15] moved to index [16]
[WRN 22:36:18.070] [KSPCF:ModuleIndexingMismatch] Persisted module "ModuleWaterfallFX" at index [16] moved to index [18]
[WRN 22:36:18.070] [KSPCF:ModuleIndexingMismatch] Persisted module "ModuleB9PartSwitch" at index [17] has been removed, no matching module in the part config
[WRN 22:36:18.070] [KSPCF:ModuleIndexingMismatch] Module "ControllingRecoveryModule" at index [9] doesn't exist in the persisted part, a new instance will be created

As I can see, changing the index of Persistent modules, disables B9PartSwitch, that's why it didn't work.

[JonnyOThan]

5 hours ago, Overlocker96 said:

I had just tested the same config and mod list, but disabling the ModulePartVariantsNodePersistence patch, and I'm sure it was it.

I'm not really sure what you're saying here.  Does disabling that patch make the issue go away?  Are you sure you didn't change anything else?

The mismatched module index patch was not touched in this last release (though there still could be some interaction).

I'm pretty sure this is related to your bug, and it occurs before any of the module index mismatch errors:

[ERR 22:23:21.696] Module ModuleDynamicNodes threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object
  at ModuleDynamicNodes.InitializeNodeSets () [0x0002f] in <4b449f2841f84227adfaad3149c8fdba>:0 
  at ModuleDynamicNodes.OnStart (PartModule+StartState state) [0x00000] in <4b449f2841f84227adfaad3149c8fdba>:0 
  at Part.ModulesOnStart () [0x00120] in <4b449f2841f84227adfaad3149c8fdba>:0 

And ModuleDynamicNodes was also not touched in this release.. Could you post the modulemanger.configcache as well?

[Overlocker96]

 

5 hours ago, JonnyOThan said:

I'm not really sure what you're saying here.  Does disabling that patch make the issue go away?  Are you sure you didn't change anything else?

Yes, exactly that. I had only disabled that patch in the config file and I played for an hour without bugs.

5 hours ago, JonnyOThan said:

Could you post the modulemanger.configcache as well?

Here it is: https://drive.google.com/file/d/1ToEcAppIyaQ1WKVYHikNH2QsKBHQKI7l/view?usp=sharing

Edited January 31 by Overlocker96

[JonnyOThan]

44 minutes ago, Overlocker96 said:

 

Yes, exactly that. I had only disabled that patch in the config file and I played for an hour without bugs.

Here it is: https://drive.google.com/file/d/1ToEcAppIyaQ1WKVYHikNH2QsKBHQKI7l/view?usp=sharing

Well I'm not sure what's going on here.  I couldn't reproduce this with a simple install of Restock+ and KSPCF.  You might want to verify your game files, or start removing mods to try to find a trigger.

[TaintedLion]

My attachment nodes are moving apart immediately when I place them after installing this update.

[JonnyOThan]

24 minutes ago, TaintedLion said:

My attachment nodes are moving apart immediately when I place them after installing this update.

Which part? Post logs?

These kinds of problems don't happen on simple installs, so in order to fix any bugs we need to know exactly what you have installed and what you did.  The ksp.log file is best way to provide that info.

Edited February 1 by JonnyOThan

[JonnyOThan]

On 1/30/2024 at 5:02 PM, Overlocker96 said:

Here's my log (I have a ton of mods but this only happened after updating KSPCF): KSP Log

You have a number of mods installed that are only marked as compatible with KSP 1.7 - that's quite dangerous.  If you used CKAN, would you mind exporting a .ckan file so I can replicate your setup easily?

[TaintedLion]

7 hours ago, JonnyOThan said:

Which part? Post logs?

These kinds of problems don't happen on simple installs, so in order to fix any bugs we need to know exactly what you have installed and what you did.  The ksp.log file is best way to provide that info.

https://www.dropbox.com/scl/fi/v2uk827vmv65z5gndgzbw/KSP.log?rlkey=56xaa8x3ux85tso2iwcuadhel&dl=0

All I'm saying is that this problem didn't happen until after I got the latest update to this mod.

[NippyFlippers]

Since the last update I am expericencing bugs with part symmetry every time when I am detaching and reattaching parts in build mode.

[JonnyOThan]

20 minutes ago, NippyFlippers said:

Since the last update I am expericencing bugs with part symmetry every time when I am detaching and reattaching parts in build mode.

Can you please post your logs?  I've seen this reported a few times, but it doesn't happen when I try to reproduce it .  The log files might help isolate where the problem is.

[NippyFlippers]

3 hours ago, JonnyOThan said:

Can you please post your logs?  I've seen this reported a few times, but it doesn't happen when I try to reproduce it .  The log files might help isolate where the problem is.

Here ist the log file: https://speedyupload.com/d/5fs1GHBhTWAGi7

 

When I, for example try to reattach a tank with 4-way symetry, I get these random placements, sometimes they are even randomly offset in several axis:

Edited February 1 by NippyFlippers

[JonnyOThan]

4 hours ago, NippyFlippers said:

Here ist the log file: https://speedyupload.com/d/5fs1GHBhTWAGi7

 

When I, for example try to reattach a tank with 4-way symetry, I get these random placements, sometimes they are even randomly offset in several axis:

Try without tweakscale.  To be clear: I have no idea what the issue here might be.  The ModulePartVariantsNodePersistence patch should be a no-op in the editor and loading scenes.  The InventoryPartMass and EVAConstructionMass patches shouldn't be dealing with attachment nodes.  BetterEditorUndoRedo would then be my prime suspect but I didn't write that one so I'm not sure how it might be interacting.

I'll note that you have a 000_KSPAPIExtensions directory in gamedata, which seems like it probably shouldn't be there: https://github.com/net-lisias-ksp/KSPe/blob/mestre/INSTALL.md

Edited February 1 by JonnyOThan

[NippyFlippers]

1 hour ago, JonnyOThan said:

Try without tweakscale.  To be clear: I have no idea what the issue here might be.  The ModulePartVariantsNodePersistence patch should be a no-op in the editor and loading scenes.  The InventoryPartMass and EVAConstructionMass patches shouldn't be dealing with attachment nodes.  BetterEditorUndoRedo would then be my prime suspect but I didn't write that one so I'm not sure how it might be interacting.

I'll try. Maybe it helps. Thanks for the answer.

[JonnyOThan]

43 minutes ago, NippyFlippers said:

I'll try. Maybe it helps. Thanks for the answer.

OK, I've confirmed that this is some kind of bad interaction with the BetterEditorUndoRedo patch and TweakScale/L.  Heads up to @Lisias in case people report this over there.  In the short term I'll disable that patch in KSPCF when TweakScale/L is installed.

(and as always note you can disable any patch in KSPCF in the settings.cfg)

Edited February 1 by JonnyOThan

[Lisias]

[snip]

TweakScale tries to be a clean slate (granted, with variable degrees of success), with any shenanigans needed to survive KSP's idiosyncrasies  shoved on KSP-Recall. There's a chance, so, that KSPCF had deactivated something on KSP-Recall that it shouldn't. I suggest you to investigate this hypothesis.

Additionally, it's also possible that the glitch is between BetterEditorUndoRedo and KSPCF, with TweakScale being the screaming victim on this problem. This is also something to be investigated, if reactivating (or deactivating) something on KSP-Recall doesn't do the trick.

That said, I will try to reproduce the problem using BetterEditorUndoRedo by mangling things on TweakScale and KSP-Recall during the period. If I managed to break the toy into reproducing the misbehaviour, at least you will have less work to do as you will know exactly what's breaking - I'm on Working Hours®, so this may take a bit.

— — POST EDIT — — 

Just realized that BetterEditorUndoRedo is a new feature on KSPCF, mangling Editor's undo. On a wild guess, BetterEditorUndoRedo perhaps need to send some event to trigger PartModules to rebuilt themselves? Cloning parts is particularly tricky, and I wonder if the undo feature would not behave in a similar fashion - I have some rememberances about the Editor's undo using a stack with the whole craft state, and poping up the stack's head replacing the current craft with it on undo. (also remember the undo undoing two steps at once, but don't really remember in which KSP version, neither if it was fixed already).

Edited February 4 by Snark
Redacted by moderator

[JonnyOThan]

32 minutes ago, Lisias said:

There's a chance, so, that KSPCF had deactivated something on KSP-Recall that it shouldn't. I suggest you to investigate this hypothesis.

That's a decent theory - I'm not going to spend any time investigating it though, because BetterEditorUndoRedo is honestly very high cost:benefit - it's a pretty massive patch for a relatively small QOL increase.  It's not a big deal to disable the patch when other mods are installed that it doesn't work correctly with.  I was originally going to ship KSPCF 1.34 with BetterEditorUndoRedo disabled by default, but gotmachine said that it was production-ready.  FYI I did test the same case with only KSP-Recall installed and not TweakScale/L, and the bug did not occur.

32 minutes ago, Lisias said:

it's also possible that the glitch is between BetterEditorUndoRedo and KSPCF, with TweakScale being the screaming victim

I don't think so, because the bug doesn't occur when TweakScale/L isn't installed.  It also doesn't occur with TweakScaleRescaled.

To be clear: I'm not trying to place blame anywhere.  Mods sometimes have bad interactions and things that work in isolation don't work in combination.  That's all this is.

Update: KSPCF 1.34.1 is now available, disabling BetterEditorUndoRedo when TweakScale/L is installed: https://github.com/KSPModdingLibs/KSPCommunityFixes/releases/tag/1.34.1

Edited February 1 by JonnyOThan

[Lisias]

On 2/1/2024 at 7:59 AM, NippyFlippers said:

When I, for example try to reattach a tank with 4-way symetry, I get these random placements, sometimes they are even randomly offset in several axis:

Determined the exact Modus Operandi. The original part of the symmetry is being displaced, the cloned parts goes to the right place.

This thing is the exactly opposite from what I was fearing - the cloned parts goes to the rigth place, it's the original part that is being misplaced. Go figure it out...

Reproduced using:

• Harmony 2.2.1.0
• KSP Recall 0.4.0.1
• KSPCF 1.34.0.0.
• TweakScale 2.4.7.4

No changes on any config file. I don't even know what'a active or not on KSP-Recall. Yet.

No part were scaled, they are all with the default scalings. No Exceptions found on KSP.log.

[snip]

Someone, somehow, is screwing the part symmetry when TweakScale™ is installed and BetterEditorUndoRedo is active.

Given the hypotheses I raised above, it makes sense for me to check if I haven't missed any atrocities in my code (I'm not mad at you for thinking it could be TweakScale™, I was annoyed by you considering it without the due process first).

[snip] the cloned parts on a symmetry are being correctly handled, it's the original part that it's misplaced. What's completely caught me with my pants down, because 

1. All the parts were unscaled. TweakScale™ is not even active on these parts! Literally, nothing is being executed!!!
2. When you scale a part and apply symmetry on it, TweakScale™ gets some heat on the cloned parts, not on the original one.
3. Worst, I didn't even used the Undo feature at any time neither!
   1. Fired up KSP
   2. Opened a random savegame
   3. Entered Editor
   4. Reproduced the problem pinpointed by @NippyFlippers, but using only the Command Module and the Fuel Tanks.

This apparently rules out TweakScale™ from the list of probable suspects.

Since I'm already here, I will proceed with the testings, this time checking if would not be KSP-Recall - besides having the remembrance that KSPCF deactivates some of its PartModules as it does the job itself.

Edited February 4 by Snark
Redacted by moderator