Jump to content

[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks


Gotmachine

Recommended Posts

  On 5/15/2022 at 5:38 PM, 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.

Expand  

"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 ?)

Link to comment
Share on other sites

  On 5/15/2022 at 7:08 PM, 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 ?)

Expand  

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.

Link to comment
Share on other sites

  On 5/15/2022 at 7:08 PM, 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.

Expand  

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. 

  On 5/15/2022 at 8:24 PM, MashAndBangers said:

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

Expand  

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

Link to comment
Share on other sites

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)
Link to comment
Share on other sites

  On 5/16/2022 at 3:40 AM, 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. 

Expand  

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 :

  Reveal hidden contents

 

  On 5/16/2022 at 8:11 AM, Baleurion said:

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

  • DisableManeuverTool [KSP 1.12.0 - 1.12.3]
Expand  

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

9C18yBu.png

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 by Gotmachine
Link to comment
Share on other sites

  On 5/16/2022 at 8:36 AM, 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 :

Expand  

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. 

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

  On 5/16/2022 at 8:36 AM, 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.

Expand  

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?

Link to comment
Share on other sites

  On 5/16/2022 at 4:23 PM, 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?

Expand  

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 by Gotmachine
Link to comment
Share on other sites

  On 5/16/2022 at 5:36 PM, 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).

Expand  

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.

Link to comment
Share on other sites

  On 5/16/2022 at 7:30 PM, 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.

Expand  

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

  On 5/16/2022 at 7:30 PM, Rakete said:

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

Expand  

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

  On 5/16/2022 at 7:30 PM, Rakete said:

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

Expand  

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

  On 5/16/2022 at 7:30 PM, Rakete said:

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

Expand  

Yes

  On 5/16/2022 at 7:30 PM, 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.

Expand  

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

Link to comment
Share on other sites

  On 5/16/2022 at 7:43 PM, Gotmachine said:

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

Expand  

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 by Grimmas
Link to comment
Share on other sites

  On 5/16/2022 at 8:05 PM, Rakete said:

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

Expand  

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 ;)

Link to comment
Share on other sites

  On 5/15/2022 at 3: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.

Expand  

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 3: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).

Expand  

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

Link to comment
Share on other sites

  On 5/16/2022 at 8:36 AM, Gotmachine said:

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

9C18yBu.png

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.

Expand  

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 by Baleurion
Link to comment
Share on other sites

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:

unknown.png

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.

Link to comment
Share on other sites

  On 5/18/2022 at 11:51 AM, 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:

unknown.png

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.

Expand  

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 by R-T-B
Link to comment
Share on other sites

  On 5/19/2022 at 3:23 AM, 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.

Expand  

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.

Link to comment
Share on other sites

  On 5/19/2022 at 3:59 AM, 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.

Expand  

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.

Link to comment
Share on other sites

  On 5/18/2022 at 11:51 AM, 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.

Expand  

@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 by Gotmachine
Link to comment
Share on other sites

  On 5/19/2022 at 7:54 AM, 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).

Expand  

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...