[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks

[Gotmachine]

1 hour ago, MashAndBangers said:

Possible bug with the Hokulani (Skylab) truss section from BDB:  When I return to my space station, the truss is unlocked even though the PAW says it's locked.  I set mechjeb to orientate the station in Prograde, and thus the "unlocked" truss will move from momentum.

"Locking" a robotic part doesn't prevent it from moving...
Depending on how much mass is attached to it and how the joint is configured, it can move quite easily.
From my recent tests with that part from BDB, I seem to recall the joint is quite weak.

This being said, I wouldn't be surprised if there is some stock bug where the servo joint isn't correctly initialized when the servo is locked. In any case, I really doubt this has anything to do with KSPCF.
I don't have the time to test that right now, but if you have some, can you un-lock, then re-lock, then quit the scene and return back, do you confirm the joint is clearly less strong than it was when you unlocked it ?
(and ideally, test that with the RoboticsDrift setting option enabled and disabled, to rule out that KSPCF is involved ?)

[MashAndBangers]

1 hour ago, Gotmachine said:

"Locking" a robotic part doesn't prevent it from moving...
Depending on how much mass is attached to it and how the joint is configured, it can move quite easily.
From my recent tests with that part from BDB, I seem to recall the joint is quite weak.

This being said, I wouldn't be surprised if there is some stock bug where the servo joint isn't correctly initialized when the servo is locked. In any case, I really doubt this has anything to do with KSPCF.
I don't have the time to test that right now, but if you have some, can you un-lock, then re-lock, then quit the scene and return back, do you confirm the joint is clearly less strong than it was when you unlocked it ?
(and ideally, test that with the RoboticsDrift setting option enabled and disabled, to rule out that KSPCF is involved ?)

I was mistaken with my earlier report.  Looks like the hinge being loose only happens when I approach the station via another vehicle, normal rendezvous operation. 

So I opened up KSP with the robotic drift fix on, and when I loaded into the station, the PAW was showing the target angle slider even though locked was on and motor was off.  Toggling lock causes the target angle to disappear.  Note:  The hinge was not loose, but I didn't try a rendezvous during this test as I had already seen this happen before anyway with the settings as they were.

I then decided to close KSP, set the robotic drift fix to false, and start KSP.  Same thing as the first test, PAW shows the target angle even though locked was on and motor was off.  I then undocked the apollo, phased the orbit to force the station to derender, then rendezvoux again, and sure enough the hinge was loose. 

So this is a bug where KSP will let loose the hinge when you rendezvous with the vessel/station in question.  Possibly mass related as I have quite a bit on the truss hinge.   Note, I haven't tried the stock robotics parts.

[dok_377]

8 hours ago, Gotmachine said:

This being said, I wouldn't be surprised if there is some stock bug where the servo joint isn't correctly initialized when the servo is locked.

You're quite right, the game indeed has that bug. Sometimes when you return to the craft, some servos will just act like they don't have a motor engaged, even if they do. I think it even happens when the robotics are locked. The only way to fix that is to disengage the motor and then engage it again.  Happened with my station quite often, don't really know what's the cause of it. 

7 hours ago, MashAndBangers said:

So this is a bug where KSP will let loose the hinge when you rendezvous with the vessel/station in question.

Yeah, I believe this is the same thing I was talking about above. The same cause probably. Happens with stock too. 

[Baleurion]

Sorry for asking something probably alreayd asked, but what exactly is this?
I thought this referred to the gizmos in lower left, or the maneuver nodes, but they're still there when turning it off?
Or does this mod have a remade more efficent code for it?

• DisableManeuverTool [KSP 1.12.0 - 1.12.3]
  Allow disabling the stock maneuver tool in the in-game settings menu (it can cause severe lag/stutter, especially with Kopernicus modified systems)

[Gotmachine]

4 hours ago, dok_377 said:

You're quite right, the game indeed has that bug. Sometimes when you return to the craft, some servos will just act like they don't have a motor engaged, even if they do. I think it even happens when the robotics are locked. The only way to fix that is to disengage the motor and then engage it again. 

The whole thing is... messy...
Robotics give you 2 slider adjustments over the joint "stiffness" : the motor "torque limit" and the "damping" .
It also gives you 2 toggleable states : "motor engaged/disengaged" and "locked/unlocked".

After a bit of testing, it's not even clear how the stiffness adjustments are supposed to work in conjunction with the toggleable states.
The damping slider is always accessible, however depending on the sequence in which you enable/disable the states, changing it has sometimes no effect.
As for the torque limit tweakable, it is only available when the motor is engaged, but it still condition joint stiffness after you disengage the motor.

And that's just by messing around with toggling those states in sequence. I'm pretty sure things are even more inconsistent after a vessel reload, and I can't begin to imagine the mess of how all of this interact with the "power loss" stuff.

The implementation of those states is the very definition of a spaghetti code plate, with each possible state combination (locked-motorized, locked-unmotorized, unlocked-motorized, unlocked-unmotorized) being manually checked everywhere instead of using a basic state machine. And then you have the additional "powered/unpowered" states to check for every of those 4 states.

TBH, putting my hands in this rat's nest isn't on the table for now.
I fear this isn't something I can really fix without having to rewrite huge portions of the robotics code.

And for reference, here are related official fixes :

Spoiler

====================================== v1.5.1 - Requires KSP v1.10.1 ==============================
+++ Bugfixes
* Fix unmotorized hinges returning to their build angle when locked in flight mode.
====================================== v1.5.0 - Requires KSP v1.10.0 ==============================
+++ Bugfixes
* Fix issue with motors engaging on launch when they have been set to disengaged in editor.
* Fix Autostrut debug visualization on Robotic Parts when locked/unlocked.
* Fix Hinges and Pistons sometimes returning to build angle when locked.
* Fix lock/unlock of robotic parts not working when fired from an action group.
====================================== v1.4.1 - Requires KSP v1.9.1 ===============================
+++ Bugfixes
* Fix non-motorized robotic parts being free moving.
====================================== v1.4.0 - Requires KSP v1.9.0 ===============================
+++ Bugfixes
* Fix robotic parts losing functionality when auto-restart is enabled.
====================================== v1.3.1 - Requires KSP v1.8.1 ===============================
+++ Bugfixes
* Fix generation of free Electric Charge for robotic parts if stopped with the PAW closed.
* Fix setting robotic part motors to disengaged in editor and then persisting that way when vessel is launched.
====================================== v1.3.0 - Requires KSP v1.8.0 ===============================
+++ Bugfixes
* Fix Robotic Parts using EC when moving to initially set position on launch.
====================================== v1.2.0 - Requires KSP v1.7.3 ===============================
+++ Bugfixes
* Fix pistons not starting in correct position at launch when locked in the editor.
* Fix Rotors not able to reach maximum RPM when un-motorized/motor disabled.
====================================== v1.1.0 - Requires KSP v1.7.2 ===============================
+++ Bugfixes
* Fix piston servo locking not working.

 

27 minutes ago, Baleurion said:

Sorry for asking something probably alreayd asked, but what exactly is this?

• DisableManeuverTool [KSP 1.12.0 - 1.12.3]

This is for disabling the stock maneuver planner widget introduced in KSP 1.12, this stuff :

This feature uses a not very robust multithreaded implementation, and when it fails to "solve" transfers quickly enough it will cause the main thread to hang.
This doesn't happen too much in the stock system, but with custom Kopernicus systems this is quite frequent, especially with bigger-than-stock systems.
The end result for the user is performance issues in the form of random stutter.
In some extreme cases this can cause the game to freeze for several seconds or even minutes, at which point your OS will usually tell you that the game is not responding and should be closed.

Edited May 16, 2022 by Gotmachine

[dok_377]

18 minutes ago, Gotmachine said:

TBH, putting my hands in this rat's nest isn't on the table for now.
I fear this isn't something I can really fix without having to rewrite huge portions of the robotics code.

And for reference, here are related official fixes :

I wasn't really going into the direction of asking for fixes from you, just a piece of conversation. As for the fixes mentioned above, oh man, believe me, I know about this mess. I personally reported a decent chunk of these problems with varying success in getting attention/fixes from the devs. Heck, it took them several major versions of the game to fix a goddarn long-standing symmetry issue with servos. The robotics in general didn't really work as intended right from the beginning, there is always something breaking to this very day. 

[Grimmas]

I've run into the issue with the BDB Skylab truss myself as well. I haven't looked into it in detail. But it usually manifests itself in the most Murphy-esque ways possible, ie the truss will start to unfold whenever I dock something that is in the way of it, despite that I have locked it and disabled the motor...

[Rakete]

7 hours ago, Gotmachine said:

This feature uses a not very robust multithreaded implementation, and when it fails to "solve" transfers quickly enough it will cause the main thread to hang.
This doesn't happen too much in the stock system, but with custom Kopernicus systems this is quite frequent, especially with bigger-than-stock systems.
The end result for the user is performance issues in the form of random stutter.
In some extreme cases this can cause the game to freeze for several seconds or even minutes, at which point your OS will usually tell you that the game is not responding and should be closed.

But this happens only when you use the calculation, right? Or does it destabilize the game even if you don't perform a maneuver creation calculation?

[Gotmachine]

1 hour ago, Rakete said:

But this happens only when you use the calculation, right? Or does it destabilize the game even if you don't perform a maneuver creation calculation?

No, it runs in the background on certain events. I'm sure it at least trigger a background computation on active vessel switches and every time a maneuver node is created or deleted, no matter if the widget window is opened or not.
I think it also run in the background when your orbit eccentricity or inclination goes past a threshold, but I haven't investigated in detail.

I guess the design intent was to have those (potentially lengthy) calculations available right away without having to click on a "compute" button and wait a few seconds for the results (this is what happens in similar tools from mods like TWP or Mechjeb).
This could have been kinda fine without the implementation bugs, as KSP only use/need a single thread and most people are usually sitting on a ton of unused CPU cores/threads.

Anyway, the point is that this tool is buggy and will cause severe stutter or even indefinite hangs in larger-than-stock systems.

Edited May 16, 2022 by Gotmachine

[Rakete]

1 hour ago, Gotmachine said:

No, it runs in the background on certain events. I'm sure it at least trigger a background computation on active vessel switches and every time a maneuver node is created or deleted, no matter if the widget window is opened or not.
I think it also run in the background when your orbit eccentricity or inclination goes past a threshold, but I haven't investigated in detail.

I guess the design intent was to have those (potentially lengthy) calculations available right away without having to click on a "compute" button and wait a few seconds for the results (this is what happens in similar tools from mods like TWP or Mechjeb).

Haven't run in these issues yet. But when you say, it runs all the time, I wonder, why the tool shows me, its percentage during calculation, when I used it in my maximum laziness. Looked to me more like a run upon function call by user... but if you say so, than it is this way.

Is there a compromise to totally deactivating it, by only let it run upon function call via ingamebutton?

What happens when the tool is disabled? Is the button also cleared out or only disfunctional? But the alarm clock feature from 1.12 still works, right?

 

Another question. I accidentally activated the disk caching of textures upon KSPCF. Where can I disable it. I remember, that there is no config entry for this.

[Gotmachine]

8 minutes ago, Rakete said:

But when you say, it runs all the time, I wonder, why the tool shows me, its percentage during calculation, when I used it in my maximum laziness. Looked to me more like a run upon function call by user... but if you say so, than it is this way.

Yes, obviously it also runs when you manipulate the UI.

9 minutes ago, Rakete said:

Is there a compromise to totally deactivating it, by only let it run upon function call via ingamebutton?

I have no intent of actually fixing this thing. There are better alternatives in various mods.

10 minutes ago, Rakete said:

What happens when the tool is disabled? Is the button also cleared out or only disfunctional?

It entirely remove the component from the game, including the button.

10 minutes ago, Rakete said:

But the alarm clock feature from 1.12 still works, right?

Yes

10 minutes ago, Rakete said:

I accidentally activated the disk caching of textures upon KSPCF. Where can I disable it. I remember, that there is no config entry for this.

At the bottom of the KSP in-game settings menu (the one you get when pressing ESC > settings)

[Grimmas]

15 minutes ago, Gotmachine said:

I have no intent of actually fixing this thing. There are better alternatives in various mods.

If you mean Transfer Window Planner, it's better in that it is actually useful unlike the new stock tool, but it is worse in that it has about a 1 in 20 chance or causing a CTD when I actually use it  Are there better alternatives? (Apart from Astrogator which is sort of useful but too narrow in scope)

Edited May 16, 2022 by Grimmas

[Gotmachine]

3 minutes ago, Grimmas said:

Are there better alternatives

Mechjeb

[Rakete]

Mechjeb? Isn't that the autopilot thing? Mhhh... It kinda breaks my laziness threshold to too easy  ... 

[Gotmachine]

MechJeb has an autopilot, amongst many other features.
Like a DV calculator and many maneuver node planners.

[Stone Blue]

1 hour ago, Rakete said:

Mechjeb? Isn't that the autopilot thing? Mhhh... It kinda breaks my laziness threshold to too easy  ... 

MechJeb is pretty modular... Its not a mandatory do-everything-for-you thing... you can select different parts of waht it does, or not, to suit your level of laziness

[desert]

On 5/15/2022 at 6:04 PM, Grimmas said:

Really guys? It's like literally one screen per building that only comes up when you start a new save. Hardly worth the effort to remove.

It's just one of those things that annoy you a bit and are too minor to complain about, but they most likely annoy many people. 

On 5/15/2022 at 6:59 PM, Gotmachine said:

That's trivial to do but it won't be enabled by default. You will need to edit the Settings.cfg file to enable it (or better, to add a MM patch for that so your changes are kept when KSPCF is updated).

Fair enough. Thanks for the mod, glad it's continuing to improve.

[Baleurion]

15 hours ago, Gotmachine said:

This is for disabling the stock maneuver planner widget introduced in KSP 1.12, this stuff :

This feature uses a not very robust multithreaded implementation, and when it fails to "solve" transfers quickly enough it will cause the main thread to hang.
This doesn't happen too much in the stock system, but with custom Kopernicus systems this is quite frequent, especially with bigger-than-stock systems.
The end result for the user is performance issues in the form of random stutter.
In some extreme cases this can cause the game to freeze for several seconds or even minutes, at which point your OS will usually tell you that the game is not responding and should be closed.

Thanks! Yeah didnt even notice that widget xD
Does it cause those preformance issues even when not open / not being used?
 

Edit: Nvm, read first reply later

Edited May 17, 2022 by Baleurion

[Rodger]

This might be more due to the Kopurnicus asteroid spawner not handling comet-class asteroids, but the stock comet-renamer is constantly messing with my craft names. For eg:

Deford 12, Sidble 6, and Wenvin 9 are all the same craft attached to the same asteroid, it keeps getting auto-renamed. It's an I-Class which in vanilla is a comet, but with kop it's basically just an E. So if this is more due to Kop, and not a vanilla bug I understand if it's "out of scope", but a way to disable the renaming could be a nice feature.

[R-T-B]

15 hours ago, Rodger said:

This might be more due to the Kopurnicus asteroid spawner not handling comet-class asteroids, but the stock comet-renamer is constantly messing with my craft names. For eg:

Deford 12, Sidble 6, and Wenvin 9 are all the same craft attached to the same asteroid, it keeps getting auto-renamed. It's an I-Class which in vanilla is a comet, but with kop it's basically just an E. So if this is more due to Kop, and not a vanilla bug I understand if it's "out of scope", but a way to disable the renaming could be a nice feature.

This might be fixable from Kopernicus's side, not sure.

A few questions to investigate that angle:

1.) Is this with the stock asteroid spawner or the Kopernicus one?

2.) Were these asteroids ever potentially generated under a different spawner than the current one?

3.) I am understanding correctly this happens when craft are attatched to a comet, yes?   If so it's possible it's some sort of stock bug, which would make it relevant here in KSPCommunityFixes more than Kopernicus.  But unsure, just trying to get all the details straight.

Edited May 19, 2022 by R-T-B

[Rodger]

30 minutes ago, R-T-B said:

This might be fixable from Kopernicus's side, not sure.

A few questions to investigate that angle:

1.) Is this with the stock asteroid spawner or the Kopernicus one?

2.) Were these asteroids ever potentially generated under a different spawner than the current one?

3.) I am understanding correctly this happens when craft are attatched to a comet, yes?   If so it's possible it's some sort of stock bug, which would make it relevant here in KSPCommunityFixes more than Kopernicus.  But unsure, just trying to get all the details straight.

It's always been the Kopernicus spawner in my game. And yeah it seems to only be after a craft is attached. And then possibly a scene change? Not 100% on this one, I may have had the craft name change in-flight, the times it happened so far I wasn't looking out for when it happened, but I'll keep at eye out next time.

[R-T-B]

3 hours ago, Rodger said:

It's always been the Kopernicus spawner in my game. And yeah it seems to only be after a craft is attached. And then possibly a scene change? Not 100% on this one, I may have had the craft name change in-flight, the times it happened so far I wasn't looking out for when it happened, but I'll keep at eye out next time.

It may be a bug in Kopernicus then, the spawner we use is not rooted in stock code at all (and thus isn't really eligible for a fix in KSPCommunityFixes).

I'll take a look at it for next release.

[Gotmachine]

20 hours ago, Rodger said:

This might be more due to the Kopurnicus asteroid spawner not handling comet-class asteroids, but the stock comet-renamer is constantly messing with my craft names.

@R-T-BHaven't tested it but pretty confident that's a stock issue and has nothing to do with Kopernicus. I will take a look.

Edit : I gave a look,

@RodgerDo you have your vessel type set to "Space object" (in the vessel type selection available from the "rename vessel" popup) ?
If so, the auto-renaming is a stock "feature". I guess the idea here was to avoid loosing the original comet name. Good idea, bad execution.
If you want to avoid it, either :
- assign another vessel type to your vessel.
- change every comet name to the vessel name you want (using the "Rename Comet" button on the comet parts PAW).

Edited May 19, 2022 by Gotmachine

[Grimmas]

On 5/16/2022 at 10:02 PM, Gotmachine said:

Mechjeb

So, I looked at Mechjeb's porkchop thingy and I can now only assume that you were joking. Well, strictly speaking it may really be better than stock for some vague definition of "better" but ugh. Not a fan. 

[Rodger]

20 hours ago, Gotmachine said:

 

@RodgerDo you have your vessel type set to "Space object" (in the vessel type selection available from the "rename vessel" popup) ?
If so, the auto-renaming is a stock "feature". I guess the idea here was to avoid loosing the original comet name. Good idea, bad execution.
If you want to avoid it, either :
- assign another vessel type to your vessel.
- change every comet name to the vessel name you want (using the "Rename Comet" button on the comet parts PAW).

They have all been probe types, based on the craft with the claw on them. And after they're auto-renamed, they are still probes. switching scene away form them and back does trigger a rename too.

When I first discover the asteroids I collect, I rename them in the tracking station (just add the size class to the name), and when I right click the attached asteroids, in the title of the PAW they still retain my customized name. But my craft is still a probe type with a comet name.