[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[Gotmachine]

1 hour ago, Rakete said:

How does the Dockingport fix of the community pack interfere with the stock fix since 1.12.3 ? Or does ist not apply to 1.12.3?

It doesn't apply to 1.12.3
To which KSP versions each patch applies is mentioned in the OP or in the readme.

In other new : V1.9.0 pre-release is available

You can get it from github (it isn't available on CKAN yet)

This pre-release introduce a fix for the BG robotics drift issue. That fix is a bit experimental, so I won't release it "officially" until I get some user feedback confirming everything is fine.
Please help me by doing a bit of testing, but backup your saves first.
What you should be looking for is part position/orientation changes in child parts of robotic parts following timewarp/physics cycling, scene switches or save/load cycles.

For more details on the robotics drift issue, and on the fix, please read this : https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/13

Edited March 16, 2022 by Gotmachine

[Brigadier]

2 hours ago, Rakete said:

I use grandfather mode at almost every part

I wouldn't advise doing this since, IIRC, every autostrut acts like a part.  This can add to your part count unnecessarily.  Be judicious.

I could be mistaken, but there will be a penalty to autostruting everything.

[Rakete]

17 hours ago, Brigadier said:

I wouldn't advise doing this since, IIRC, every autostrut acts like a part.  This can add to your part count unnecessarily.  Be judicious.

I could be mistaken, but there will be a penalty to autostruting everything.

Didn't know this... Strange kind of coding, if a connection between two parts acts like an own part... Not quite intuitive to the user

So I used some power of my i7 9700 to calculate arcane autostruts

 

 

@Gotmachine

Think, I found a nice bug in KSP worth fixing: If you have docked a vehicle to a spacestation (eg. using a mk2 docking port and a shielded docking port) and have several autostruts engaged of several types (e.g. grandfather, heaviest part etc).  the following happens if you use the rotation feature of the docking port. It does not twist anymore around the docking axis. In some cases it twisted along an other axis causing mechanical tension on the parts, finally causing things to break apart.

 

Example: Dock the shared Phoenix-SSTO (pure stock) to the Docking arm of the Yggdrasil-Station in the save:

https://www.filemail.com/d/qvjymjdtuzenqzk  and than try to dockrotate.... it will cause mechanical tension and break. Same goes for the sj. Docking ports of the station

(You might need the Nertea Mods :-) for the savegame )

Edited March 17, 2022 by Rakete

[Rakete]

@Gotmachine

Is it possible, to make your QoL-Changes optional?

I'd like to opt-out this one: PAWStockGroups [KSP 1.10.1 - 1.12.3]

Can you provide a config, to opt-in/out of several changes?
 

[Gotmachine]

2 hours ago, Rakete said:

Think, I found a nice bug in KSP worth fixing: If you have docked a vehicle to a spacestation (eg. using a mk2 docking port and a shielded docking port) and have several autostruts engaged of several types (e.g. grandfather, heaviest part etc).  the following happens if you use the rotation feature of the docking port. It does not twist anymore around the docking axis. In some cases it twisted along an other axis causing mechanical tension on the parts, finally causing things to break apart.

The rotating docking port feature is a mess and has several issues. I've given up on my attempt to make it work, and I highly suggest never using it. Use this mod instead :

1 hour ago, Rakete said:

Is it possible, to make your QoL-Changes optional?

You can enable/disable individual patches either by editing the "Settings.cfg" file directly, or by creating a MM patch (create an empty text file and change the file extension to *.cfg) that you put in your GameData folder (that way you won't loose your changes when the mod is updated).

@KSP_COMMUNITY_FIXES:FINAL
{
  @PAWStockGroups = false
}

 

[Rakete]

3 hours ago, Gotmachine said:

The rotating docking port feature is a mess and has several issues. I've given up on my attempt to make it work, and I highly suggest never using it. Use this mod instead :

You can enable/disable individual patches either by editing the "Settings.cfg" file directly, or by creating a MM patch (create an empty text file and change the file extension to *.cfg) that you put in your GameData folder (that way you won't loose your changes when the mod is updated).

@KSP_COMMUNITY_FIXES:FINAL
{
  @PAWStockGroups = false
}

 

Ahhh great... sorry, I must have overlooked the config file.

[dok_377]

On 3/17/2022 at 1:11 AM, Gotmachine said:

a fix for the BG robotics drift issue

Wait, you actually trying to fix the bane of this game's existence? We as a community need more people like you. You, sir, are a legend. 

[Gotmachine]

V1.9.0 is out.

Available from GitHub and CKAN.

Changes in that release :

• New bugfix : RoboticsDrift [KSP 1.8.0 - 1.12.3]
  Prevent unrecoverable part position drift of Breaking Grounds DLC robotic parts and their children parts.
• New bugfix : DockingPortLocking [KSP 1.12.3]
  Fix some user-facing inconsistencies with the docking port rotation locking feature and hide irrelevant PAW items when the docking port is locked.
• New mod API patch : DockingPortLockedEvents (added for KJR, see related issue)
• PAWCollapsedInventories : Fixed mass/volume info not updating correctly in the group title.
• Now using Krafs.Publicizer for cleaner/faster access to KSP internals.

[Kwebib]

Fantastic work on this mod. Thank you.

[Rakete]

Hadn't have the time to check out the pre-release. Did you really manage to kill the evil robotic drift bug without causing nasty side-effects? I am impressed.

[Gotmachine]

2 hours ago, Rakete said:

Did you really manage to kill the evil robotic drift bug without causing nasty side-effects?

I hope so. I did a fair bit of testing on my side, but there is always the possibility of some corner case I missed. Let me know if you encounter any issue.

[linuxgurugamer]

14 hours ago, Gotmachine said:

Now using Krafs.Publicizer for cleaner/faster access to KSP internals.

That's very interesting.  Would you know if there was a way to use Krafs.Publicizer with the Mono compiler on Linux?  After quick look, I didn't see any info on that

[Gotmachine]

22 minutes ago, linuxgurugamer said:

That's very interesting.  Would you know if there was a way to use Krafs.Publicizer with the Mono compiler on Linux?  After quick look, I didn't see any info on that

Krafs.Publicizer is a nuget package that interact with your IDE and compiler through MSBuild. It doesn't care about the platform you're using.
Unless you're using an antiquated (non-Roslyn based) version of Mono to compile your project, it should work.

This being said, if for some reason you're unable to use it, you can achieve the same effect manually :
- Use an assembly publicizer tool on Assembly-CSharp (for example https://github.com/iRebbok/APublicizer or https://github.com/BepInEx/NStrip )
- Use the resulting Assembly-CSharp in your project reference when writing your code in whatever IDE you're using, and use that reference for your compiler.
- Add "<AllowUnsafeBlocks>true</AllowUnsafeBlocks>" to your plugin *.csproj

[Spaceman.Spiff]

3 hours ago, Gotmachine said:

I hope so. I did a fair bit of testing on my side, but there is always the possibility of some corner case I missed. Let me know if you encounter any issue.

Does it use a similar system to DockRotate? I used that mod for months before 1.12 and never had drift issues. 

[Gotmachine]

40 minutes ago, Spaceman.Spiff said:

Does it use a similar system to DockRotate? I used that mod for months before 1.12 and never had drift issues. 

From memory, yes, the solution and effect should be pretty similar.
There are more or less only two ways to implement translation/rotation actuation interactions with the part coordinates, a drift inducing one and an okay one. Stock robotics were just using the wrong one

If there are issues with the KSPCF fix, it's likely more implementation issues/oversights when interacting with the stock robotics code. The "drift fixing math" part should be pretty solid, I believe.

Edited March 22, 2022 by Gotmachine

[linuxgurugamer]

1 hour ago, Gotmachine said:

Krafs.Publicizer is a nuget package that interact with your IDE and compiler through MSBuild. It doesn't care about the platform you're using.
Unless you're using an antiquated (non-Roslyn based) version of Mono to compile your project, it should work.

This being said, if for some reason you're unable to use it, you can achieve the same effect manually :
- Use an assembly publicizer tool on Assembly-CSharp (for example https://github.com/iRebbok/APublicizer or https://github.com/BepInEx/NStrip )
- Use the resulting Assembly-CSharp in your project reference when writing your code in whatever IDE you're using, and use that reference for your compiler.
- Add "<AllowUnsafeBlocks>true</AllowUnsafeBlocks>" to your plugin *.csproj

Thank you.  

[OrbitalManeuvers]

On 3/16/2022 at 4:28 PM, Brigadier said:

I wouldn't advise doing this since, IIRC, every autostrut acts like a part.  This can add to your part count unnecessarily.

This is a bit of an extraordinary claim, and I'd be super interested in some extraordinary evidence. I use a mod that fully autostruts everything, and my part count definitely does not double (or change at all) when I disable/enable autostrut on every part (it's a one-click op). Is there a definition of "part count" that I'm not understanding? I'm just looking at the part count displayed in the engineer's report.

[dok_377]

1 hour ago, OrbitalManeuvers said:

I use a mod that fully autostruts everything, and my part count definitely does not double (or change at all) when I disable/enable autostrut on every part (it's a one-click op).

Autostrut acts like a joint between parts, not a full part. It still has some performance impact because of the calculations, but definitely will not double the partcount performance loss. I will even go as far as saying that the regular struts don't affect the performance that much either. If you use a mod to see a collider of the part itself, you will see that it's just a simple ball. They don't do much if used properly. 

Edited March 22, 2022 by dok_377

[dok_377]

@Gotmachine

There's some things happening in the editor (only in the editor, the flight scene looks good) with robotics and KAL controllers with KSPCF Installed. When the KAL is played, the whole thing just flips out and starts spamming commands on the craft and destroys the log. Happens on newly built crafts as well. I don't really know what's causing it, but here's all the things I can gather:

The video of it happening: https://youtu.be/oKRlRiFeCb8
The craft file: https://drive.google.com/file/d/1guZAhR1hShyWxwep8XXZo6joKUEPjQ9L
KSP log: https://drive.google.com/file/d/1U7eAE6YpSEJK8dtd1SIYiWgodfgfHASE
Player log: https://drive.google.com/file/d/1w6d_jG_fQWoZdhBlBCVqGVmVLktxgHPv
Game version: 1.10.1, clean install

 

[Gotmachine]

1 hour ago, dok_377 said:

There's some things happening in the editor (only in the editor, the flight scene looks good) with robotics and KAL controllers with KSPCF Installed.

Thanks for the detailed report.

So, two things happening here :
- There is a missing check in KSPCF causing the "[RoboticsDrift] Servo info not found..." log entries when the "locked" state of a robotic part is toggled in the editor. This is harmless, but I will correct it to avoid the log spam.
- The "NullReferenceException" log spam is unrelated to KSPCF, this is a stock bug. This happen because you have the "control from here" command module action assigned in the KAL controller, and that action is failing to signal that it shouldn't be executed while in the editor.

V1.9.1 is out.

Available from GitHub and CKAN.

Changes in that release :

• RoboticsDrift : fixed (harmless) [RoboticsDrift] Servo info not found... log spam when toggling the locked state of a robotic part in the editor

[dok_377]

39 minutes ago, Gotmachine said:

- The "NullReferenceException" log spam is unrelated to KSPCF, this is a stock bug. This happen because you have the "control from here" command module action assigned in the KAL controller, and that action is failing to signal that it shouldn't be executed while in the editor.

Oh, that's actually interesting, I didn't know about this. Thanks for the quick fix. 

[flart]

[LOG 13:40:18.382] Unpacking Transfer Station
[EXC 13:40:18.383] 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()

Is it possible that the KSPCF is responsible?

[Gotmachine]

1 hour ago, flart said:

Is it possible that the KSPCF is responsible?

I'm not entirely excluding it, but it's very likely a stock issue.
I've seen this exception happening while testing other stuff a while ago, and I remember being able to reproduce it without KSPCF (but I might remember wrong)

I'm not able to reproduce it right now, giving me a reproducible test case would help (also, which KSP version ?).

Edited March 23, 2022 by Gotmachine

[Rakete]

@Gotmachine

I think i might have found a nasty sideeffect. Since I installed the community fix pack sometimes KSP eats my craftfiles. I usually save my builds before launching testwise. Since I installed the fixes, sometimes the game refuses to load the flightscene foe launch and throws me back to the KSC-outside. Because I have saved the craft before launch it is as messed up as the autosaved vehicle and refuses to show the staging (shows its elements horizontally in a green box starting with a + symbol...). No interactions with the displayed craft in the vab are possible, so that i can't ve repaired. It doesn't even close the load window, after loading a messed up craft file. Something in the crafteditor seems not to work. I could not reproduce it. Sometimes it happens if I use one of my standardlifters and remove two of four boosters. Hadn't had it after uninstalling the community fixes.

Unfortunately i have no log at hand, when this happens, as it happens random for me. Also i have no messed up craft at hand, cause I deleted it in a fury. :-) unfortunately... I ate a craft i was working on 5 hours. My fault not to save different itterations ×D. It drove me nuts today.

 

may be keep an eye on that behavior... I will deliver a log, when it happens again.

Edited March 27, 2022 by Rakete

[dok_377]

@Gotmachine
I just came up with another idea for a QoL improvement. You know how on fairings you can press the button for the fairing to not open when you mouseover it? It gets reset each time you reload the craft file. Would be nice to have it remember the setting, that would help immensely with crafts that have a lot of fairings on them. 

Edited March 29, 2022 by dok_377