[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[Gotmachine]

V1.10.0 is out.

Available from GitHub and CKAN.

Changes in that release :

• New bugfix : DockingPortRotationDriftAndFixes [KSP 1.12.3]
  This patch contain several docking port fixes, and supersede the DockingPortLocking and DockingPortDrift patches, those patches have been removed. Make the stock docking port rotation feature actually useable :
  • Completely prevent unrecoverable position drift of children parts of docking ports.
  • Fix joint failure and phantom forces when a docking port pair is set to opposite extreme angles.
  • Allow tweaking the rotation in the editor and while not docked in flight.
  • Rotation can now be properly used in a robotic controller.
  • Remove the -86°/86° hardcoded limitation of hardMinMaxLimits, it is now -180°/180°.
  • Fix many issues and state inconsistencies.
  • An optional DockingPortExtendedRotation.cfg.extra MM patch extending rotation range to 360° is available in the Extras folder. Copy it to your GameData folder and remove the .extra extension to use it.
• New bugfix : PackedPartsRotation [KSP 1.8.0 - 1.12.3]
  Fix part rotations not being reset to their pristine value when a non-landed vessel is packed, resulting in permanent part rotation drift when docking and other minor/cosmetic issues. This patch is a generalization of a fix previously implemented in RoboticsDrift, and now cover all occurrences of that issue.
• New QoL patch : FairingMouseOverPersistence [KSP 1.8.0 - 1.12.3] (suggested by forum user @dok_377)
  Make the "Fairing Expansion" state persistent when reloading a craft in the editor.
• New mod API optional patch : OnSymmetryFieldChanged [KSP 1.8.0 - 1.12.3] (thanks to @DRVeyl)
  Disabled by default, you can enable it with a MM patch. Change the UI_Control.onSymmetryFieldChanged callback to behave identically to the UI_Control.onFieldChanged callback :
  • The callback will only be called when the field value has actually been modified.
  • The "object" argument will contain the previous field value (instead of the new value).
• New mod API optional patch : PersistentIConfigNode [KSP 1.8.0 - 1.12.3] (thanks to @NathanKell)
  Disabled by default, you can enable it with a MM patch. Implement IConfigNode members marked as [Persistent] serialization support when using the CreateObjectFromConfig(), LoadObjectFromConfig() and CreateConfigFromObject() methods.
• PartStartStability : fixed the patch causing an ArgumentOutOfRangeException on scene/vessel load in FlightIntegrator.Update(). As a side effect, this patch now make the FI first "valid" execution deterministic (will always be on the fourth FixedUpdate() cycle).
• RoboticsDrift : fixed incorrect handling when a robotic part is the vessel root part
• Prevent some patches failing with a ReflectionTypeLoadException when another plugin assembly fail to load (ex : the Sandcastle/EL integration assembly)

[Poodmund]

What do the new optional, OnSymmetryFieldChanged and PersistentIConfigNode, patches do in layman's terms?

[Gotmachine]

2 minutes ago, Poodmund said:

What do the new optional, OnSymmetryFieldChanged and PersistentIConfigNode, patches do in layman's terms?

Nothing of relevance for the end user. They implement missing stuff / fix some inconsistent behavior in the KSP "API", and were implemented at the request of other modders (DrVeyl and NathanKell), which are free to enable them if/when their own plugins make use of it.
They are disabled by default because since they technically alter the "stock" API, there is a (really tiny) chance they can have a side effect on another random plugin.
I checked a possible impact by doing a global github search and didn't found any plugin for which those patch could cause an issue. Making them "opt-in" is an additional safeguard in case I missed something.

[Spaceman.Spiff]

2 hours ago, Gotmachine said:

V1.10.0 is out.

Available from GitHub and CKAN.

Changes in that release :

• New bugfix : DockingPortRotationDriftAndFixes [KSP 1.12.3]
  This patch contain several docking port fixes, and supersede the DockingPortLocking and DockingPortDrift patches, those patches have been removed. Make the stock docking port rotation feature actually useable :
  • Completely prevent unrecoverable position drift of children parts of docking ports.
  • Fix joint failure and phantom forces when a docking port pair is set to opposite extreme angles.
  • Allow tweaking the rotation in the editor and while not docked in flight.
  • Rotation can now be properly used in a robotic controller.
  • Remove the -86°/86° hardcoded limitation of hardMinMaxLimits, it is now -180°/180°.
  • Fix many issues and state inconsistencies.
  • An optional DockingPortExtendedRotation.cfg.extra MM patch extending rotation range to 360° is available in the Extras folder. Copy it to your GameData folder and remove the .extra extension to use it.
• New bugfix : PackedPartsRotation [KSP 1.8.0 - 1.12.3]
  Fix part rotations not being reset to their pristine value when a non-landed vessel is packed, resulting in permanent part rotation drift when docking and other minor/cosmetic issues. This patch is a generalization of a fix previously implemented in RoboticsDrift, and now cover all occurrences of that issue.
• New QoL patch : FairingMouseOverPersistence [KSP 1.8.0 - 1.12.3] (suggested by forum user @dok_377)
  Make the "Fairing Expansion" state persistent when reloading a craft in the editor.
• New mod API optional patch : OnSymmetryFieldChanged [KSP 1.8.0 - 1.12.3] (thanks to @DRVeyl)
  Disabled by default, you can enable it with a MM patch. Change the UI_Control.onSymmetryFieldChanged callback to behave identically to the UI_Control.onFieldChanged callback :
  • The callback will only be called when the field value has actually been modified.
  • The "object" argument will contain the previous field value (instead of the new value).
• New mod API optional patch : PersistentIConfigNode [KSP 1.8.0 - 1.12.3] (thanks to @NathanKell)
  Disabled by default, you can enable it with a MM patch. Implement IConfigNode members marked as [Persistent] serialization support when using the CreateObjectFromConfig(), LoadObjectFromConfig() and CreateConfigFromObject() methods.
• PartStartStability : fixed the patch causing an ArgumentOutOfRangeException on scene/vessel load in FlightIntegrator.Update(). As a side effect, this patch now make the FI first "valid" execution deterministic (will always be on the fourth FixedUpdate() cycle).
• RoboticsDrift : fixed incorrect handling when a robotic part is the vessel root part
• Prevent some patches failing with a ReflectionTypeLoadException when another plugin assembly fail to load (ex : the Sandcastle/EL integration assembly)

The real question is whether it contains an April Fool’s prank/Easter egg….

[Admiral Fluffy]

2 hours ago, Spaceman.Spiff said:

The real question is whether it contains an April Fool’s prank/Easter egg….

I suspect it does.

[Spaceman.Spiff]

52 minutes ago, Admiral Fluffy said:

I suspect it does.

Those just look like standard Module Manager Nyans 

[Admiral Fluffy]

38 minutes ago, Spaceman.Spiff said:

Those just look like standard Module Manager Nyans 

Ah, then I don’t know if it does.

Thanks for telling me what it was from though!

[dok_377]

14 hours ago, Gotmachine said:

New QoL patch : FairingMouseOverPersistence [KSP 1.8.0 - 1.12.3] (suggested by forum user @dok_377)
Make the "Fairing Expansion" state persistent when reloading a craft in the editor.

Thank you!
For some reason the forum decided I'm going to be the only person not properly tagged.   Good thing I check this thread from time to time. 

[Matt77]

Thanks for the fixes.

Unfortunately the robotics drift isn't fixed for me.  I may be pushing the physics engine too far...  The rover on the left was created after installing Community Fixes 1.9 and the one on the right, after 1.10.

Log

More log

Craft File

Screenshot

[Gotmachine]

40 minutes ago, Matt77 said:

Unfortunately the robotics drift isn't fixed for me.

I'm not sure what I am looking at. What is your issue exactly ?
Also, I can't open that craft file, as it uses a bunch modded parts.
Could make a simple craft that reproduce your issue with only stock parts ?

Edit : I guess your issue is the strut target position not being updated ?
Indeed that's an issue, but a completely different one than what the KSPCF patch is for.
I will try to look into it...

Edited April 2, 2022 by Gotmachine

[flart]

beside the nullrefs, that I reported before

Spoiler

[EXC 21:50:54.186] NullReferenceException: Object reference not set to an instance of an object
	ModuleDockingNode.get_VisualTargetAngle () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
	ModuleDockingNode.OnPartUnpack () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Component:SendMessage(String, SendMessageOptions)
	Part:Unpack()
	Vessel:GoOffRails()
	OrbitPhysicsManager:LateUpdate()

there is a new nullref spam:

Spoiler

[EXC 21:50:54.314] NullReferenceException: Object reference not set to an instance of an object
	ModuleDockingNode.get_VisualTargetAngle () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
	KSPCommunityFixes.BugFixes.DockingPortRotationDriftAndFixes.ModuleDockingNode_UpdateAlignmentRotation_Prefix (ModuleDockingNode __instance) (at <a5b93ea983474f5a982daefac2a0037d>:0)
	(wrapper dynamic-method) ModuleDockingNode.ModuleDockingNode.UpdateAlignmentRotation_Patch1(ModuleDockingNode)
	ModuleDockingNode.FixedUpdate () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
[EXC 21:50:54.332] NullReferenceException: Object reference not set to an instance of an object
	ModuleDockingNode.get_VisualTargetAngle () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
	KSPCommunityFixes.BugFixes.DockingPortRotationDriftAndFixes.ModuleDockingNode_UpdateAlignmentRotation_Prefix (ModuleDockingNode __instance) (at <a5b93ea983474f5a982daefac2a0037d>:0)
	(wrapper dynamic-method) ModuleDockingNode.ModuleDockingNode.UpdateAlignmentRotation_Patch1(ModuleDockingNode)
	ModuleDockingNode.FixedUpdate () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

ksp.log https://1drv.ms/u/s!Alncj27YxKc-iCL9GZ9t7clVFpmX

Edited April 2, 2022 by flart

[Gotmachine]

@flartDo you have a docking port as a root part ? The stock code definitely will have trouble handling that.

[flart]

3 hours ago, Gotmachine said:

Do you have a docking port as a root part ?

Only if the game reroot to the DP on docking

[Matt77]

On 4/2/2022 at 6:07 PM, Gotmachine said:

I'm not sure what I am looking at. What is your issue exactly ?
Also, I can't open that craft file, as it uses a bunch modded parts.
Could make a simple craft that reproduce your issue with only stock parts ?

Edit : I guess your issue is the strut target position not being updated ?
Indeed that's an issue, but a completely different one than what the KSPCF patch is for.
I will try to look into it...

I wondered if the struts were a factor, but it also seems like the pistons go fully retracted.  It works ok on launch, but on reloading it seemed like the drift problem.

I'll try to recreate the issue in a stock install, but if it isn't within the scope of this mod I understand.

[Gotmachine]

45 minutes ago, Matt77 said:

I'll try to recreate the issue in a stock install, but if it isn't within the scope of this mod I understand.

It is definitely in the scope of this mod. I just need to figure out how to fix it

45 minutes ago, Matt77 said:

it also seems like the pistons go fully retracted

Do you mean that you extended them, and after reloading the vessel they were not extended like you left them ?
That feels weird to me. Are you sure of that ?

1 hour ago, flart said:

Only if the game reroot to the DP on docking

Not on docking, but on undocking, the undocked vessel root part will be the docking port.
Anyway, that is very likely the cause of the exception, the stock implementation is completely broken when a docking port is a root part. I'm fixing it, that issue will hopefully be gone in the next KSPCF update.

Edited April 3, 2022 by Gotmachine

[Gotmachine]

@Matt77After some testing, I'm don't think this is really "fixable".

If you use struts to "close" a loop of parts that include robotic parts, and then move the robotic parts, you're playing on the strut joint flexibility.
So if you change the relative position/orientation of each part connected on either end of the strut (using robotic parts in the middle), the strut will somewhat follow as far as its joint flexibility allows while in physics.

Thing is, a robotic part is designed to allow a degree of freedom (either on one translation, or one rotation), and is capable of keeping track of its displacement.
A strut can't do that. It has a designated position/orientation, and will always keep it.

The result is that when saving the vessel, the robotic parts will save their current displacement, but the strut won't (it will keep it's original "target coordinates")
So when reloading the vessel, the parts will have moved compared to the original vessel, but not the strut, so its "end target" will end up nowhere near what you would expect.

So you could say : "then update and save the joint target !".
But that would only solve things on the cosmetic side. In your screenshot, the strut is visually mid-air, but it is actually still connected.
This mean every time you save/reload, you end up with a strut that lock your robotic parts in their current positions, with no guarantee that said robotic parts are able to force-stretch back the strut in the original position.

In the end, the conceptual issue is that KSP doesn't save the full "in physics" state of the vessel.
The original KSP assumption is that it has "original" coordinates for each part, and when you reload the vessel, it put the parts there and recreate brand new unstressed joints between them.
The "drift" issue in a nutshell is that when robotics parts are involved, the "elastic" deformation is saved as a "plastic" deformation : the "original" coordinates are overridden with the current in-physics part coordinates.
This obviously wrong in the context of that initial KSP assumption, and the end result is the progressive "drifting" of the part positions as you save and reload the vessel multiple times.
So what I'm doing to prevent this is to recompute the theoretical part positions resulting from robotic displacement as if there was no in-physics deformation at all. If a piston is extended by 1 meter in a direction, all connected parts "original" coordinates are moved by precisely 1 meter in that direction.

This is fine for an "open" part tree, but if you "close" the tree with struts with the expectation that the struts will act as some sort of pivot, this all fall apart.
To have that work, it would require KSP to not only save and restore part coordinates, but also the state of each joint connecting them (ie, the torques and forces the joint is currently experiencing)
In the context of a "strut fix", even if there was some way to convert back the current forces/torques to obtain a somewhat reliable joint target position/rotation offset, that would register all current forces/torques on that specific joint, so the result would be unusable unless the same is done on every other joint in the part loop.

So I don't really see a way to fix this. The "closing a robotic part loop with struts" use case isn't really something that can be handled correctly.

[DfA-DoM]

7 hours ago, Gotmachine said:

@Matt77After some testing, I'm don't think this is really "fixable".

If you use struts to "close" a loop of parts that include robotic parts, and then move the robotic parts, you're playing on the strut joint flexibility.
So if you change the relative position/orientation of each part connected on either end of the strut (using robotic parts in the middle), the strut will somewhat follow as far as its joint flexibility allows while in physics.

[...]

So I don't really see a way to fix this. The "closing a robotic part loop with struts" use case isn't really something that can be handled correctly.

IMHO, we are here at an edge between unhandled case (bug?) and misuse, but this kind of issue would be avoided if we got a way to detect such kind of structurally arguable builds.

Have you considered that your (already mandatory) mod could also provide some hints and warnings on the engineering report for example to prevent unintentional relying on ill-formed ships ?

Edited April 4, 2022 by DfA-DoM
typo

[Gotmachine]

V1.10.1 is out.

Available from GitHub and CKAN.

Changes in that release :

DockingPortRotationDriftAndFixes refinements :

• Fixed the stock implementation being unable to handle a rotating docking ports when it is the root part (was throwing exceptions and generally wasn't working correctly)
• Fixed another stock bug : having a rotationAxis other than "Y" result in the docking port still rotating around the Y axis. This bug affect the 2 "inline" stock docking port parts.
• Fixed KSPCF bug : parent port not being able to rotate after re-docking
• Fixed KSPCF bug : things were not working as expected when using a rotating + non-rotating docking port pair
• Fixed KSPCF bug : prevent rotation being available when about to dock or after undocking when the other docking port is "acquired" but not docked.
• Various performance optimizations

@flartThis should fix the exceptions you had. Let me know if there is still an issue.

[Matt77]

20 hours ago, Gotmachine said:

@Matt77After some testing, I'm don't think this is really "fixable".

If you use struts to "close" a loop of parts that include robotic parts, and then move the robotic parts, you're playing on the strut joint flexibility.
So if you change the relative position/orientation of each part connected on either end of the strut (using robotic parts in the middle), the strut will somewhat follow as far as its joint flexibility allows while in physics.

Thing is, a robotic part is designed to allow a degree of freedom (either on one translation, or one rotation), and is capable of keeping track of its displacement.
A strut can't do that. It has a designated position/orientation, and will always keep it.

The result is that when saving the vessel, the robotic parts will save their current displacement, but the strut won't (it will keep it's original "target coordinates")
So when reloading the vessel, the parts will have moved compared to the original vessel, but not the strut, so its "end target" will end up nowhere near what you would expect.

So you could say : "then update and save the joint target !".
But that would only solve things on the cosmetic side. In your screenshot, the strut is visually mid-air, but it is actually still connected.
This mean every time you save/reload, you end up with a strut that lock your robotic parts in their current positions, with no guarantee that said robotic parts are able to force-stretch back the strut in the original position.

In the end, the conceptual issue is that KSP doesn't save the full "in physics" state of the vessel.
The original KSP assumption is that it has "original" coordinates for each part, and when you reload the vessel, it put the parts there and recreate brand new unstressed joints between them.
The "drift" issue in a nutshell is that when robotics parts are involved, the "elastic" deformation is saved as a "plastic" deformation : the "original" coordinates are overridden with the current in-physics part coordinates.
This obviously wrong in the context of that initial KSP assumption, and the end result is the progressive "drifting" of the part positions as you save and reload the vessel multiple times.
So what I'm doing to prevent this is to recompute the theoretical part positions resulting from robotic displacement as if there was no in-physics deformation at all. If a piston is extended by 1 meter in a direction, all connected parts "original" coordinates are moved by precisely 1 meter in that direction.

This is fine for an "open" part tree, but if you "close" the tree with struts with the expectation that the struts will act as some sort of pivot, this all fall apart.
To have that work, it would require KSP to not only save and restore part coordinates, but also the state of each joint connecting them (ie, the torques and forces the joint is currently experiencing)
In the context of a "strut fix", even if there was some way to convert back the current forces/torques to obtain a somewhat reliable joint target position/rotation offset, that would register all current forces/torques on that specific joint, so the result would be unusable unless the same is done on every other joint in the part loop.

So I don't really see a way to fix this. The "closing a robotic part loop with struts" use case isn't really something that can be handled correctly.

Thank you for the in-depth reply.  I believe I understand but will have to read it again.  I did make a stock install to try to make it repeatable but apparently it's not that easy.

I had an inkling that using struts that way might be a cause, a "misuse", definitely :-)  I know from past experience that KSP prefers a tree structure to loops but I didn't really notice that I was breaking the rules - I thought it was similar to using struts to add rigidity to boosters, clearly not the same use case though!

I appreciate the time you have taken to look into this, thank you.

[Rodger]

A suggestion for a small QOL feature that could be added - have the stock science module show transmission % in the part info window in the editor, like DMagicMSAG does.

[flart]

36 minutes ago, Rodger said:

have the stock science module show transmission % in the part info window in the editor

iirc this one is showing that

[Rodger]

Ah nice, it didn't do that last time I checked, but does now. Thanks for letting me know!

[Rakete]

@Gotmachine Since you are the expert on drifting things in KSP, can you do something against the drift of vehicles on even the smalles slopes e.g. in the mun or e.g. drifting of a heavy plane on the runway if you do not take off imediatly after loading in?

 

Really really appreciate your work. It should have been done by the devs. Thanks for all those efforts.

Edited April 9, 2022 by Rakete

[Gotmachine]

17 hours ago, Rakete said:

Since you are the expert on drifting things in KSP, can you do something against the drift of vehicles on even the smalles slopes e.g. in the mun or e.g. drifting of a heavy plane on the runway if you do not take off imediatly after loading in?

Well, this is a completely different thing.
Stuff moving around in physics is a result of the physics simulation itself, there is no real way to make it "less slippery", apart from disabling/overriding the physics simulation results altogether.
Which could be a solution. Squad kinda implemented something like that for Kerbals on ladders, where as long as you don't actively move on the ladder, the Kerbal is "pinned" to its current position.
But in that case, this would be a completely new feature, likely an UI option that you activate to "pin the vessel to the ground".
This is kinda out of the scope of this mod and that would be quite some work to implement right.

This being said, if you need something like this, there is https://github.com/gotmachine/PhysicsHold
Just be aware that this is kinda experimental, that I offer no support whatsoever for that mod, and that it has a bunch of caveats (read the readme carefully).

[Gotmachine]

V1.11.0 is out.

Available from GitHub and CKAN.

Changes in that release :

• New bugfix : ExtendedDeployableParts [KSP 1.12.0 - 1.12.3]
  Fix deployable parts (antennas, solar panels, radiators...) always starting in the extended state when the model isn't exported in the retracted state. This bug affect parts from various mods (ex : Ven's stock revamp solar panels).
• New performance tweak : TextureLoaderOptimizations [KSP 1.10.0 - 1.12.3]
  Speedup loading time by caching on disk the PNG textures KSP converts to DXT5 on every launch. Also make PNG @thumbs cargo part textures non-readable to free some RAM. This patch has no entry in settings.cfg, but is opt-in (a popup is shown on first KSP launch) and can be disabled latter in the in-game settings menu.
• New Qol tweak : HidePartUpgradeExtendedInfo [KSP 1.8.0 - 1.12.3]
  Hides irrelevant extended info on the part tooltip for PartUpgrades in the RnD screen. Courtesy of @NathanKell (see #29)