[KSP v1.1.3] Stock Bug Fix Modules (Release v1.1.3b.1 - 10 Jul 16)

[Claw]

It's been a little while since I've posted a version, so I thought I would post a short update. I've been busy with life events, plus I took some time to partake in a couple challenges (including posting a mission report). In any case, you're not here to hear about my woes.

Most recently I've been working on the claw bugs. I have fixed the bug that eats ships if the ship in control is the one being clawed on. There is also the timewarp bug, where part of the ship freezes in place and the other parts rip off. I've managed to keep it from ripping the ship apart and allows you some time to save, but I haven't been able to halt it completely yet.

I've updated the StockPlus parachute flare (pictured in the OP) a bit, and now includes flare for symmetrically placed stack chutes (like the Mk-16). Also, it StockPlus chutes now have a safe/risky/unsafe indicator on the stage icons.

Finally, I'm starting work on the problems with fairings and service bays. Primarily the work is focusing on making sure parts don't stay disabled due to fairings, even though they aren't in them anymore. I think most recently someone else discovered there are drawbacks to simply resetting the "Shielded from airstream" flag.

Cheers,

-Claw

Edited July 21, 2015 by Claw

[waterlubber]

Is the Linux Crashing Bug that you fixed the one where you randomly crash for no reason whatsoever?

It's REALLY annoying.

[Claw]

Well, the linux crashing bug that I fixed (confirmed) has to do with parachutes. So I wouldn't quite say "for no reason" on that one. And, unfortunately, there are a lot of "crash for no reason" bugs. So without more details, I'm not sure which you are referring to.

Cheers,

-Claw

Edited July 21, 2015 by Claw

[Claw]

Version 1.0.4b.1 -- Updated for more KSP 0.23.5 craziness! (Yes, I said 0.23.5, when the Claw came out!)

Two significant changes:

• ModuleParachuteFix - Adds a "Safe/Risky/Unsafe" indicator. Updated/improved chute spread, which also now includes stack chutes (placed in symmetry).
  
• SymmetryActionFix - Minor update
  
• HighestSpeedFix - Uncaps the "Highest Speed Achieved" value in the F3 Flight Log (which currently tops out at 750 m/s)
  
• ModuleGrappleNodeFix - Fixes a bug which crashes KSP when in not in control of the claw ship while clawing (ship plummets to planet or game crashes). Also adds a bug trap (but not quite a fix) that prevents the Claw Kraken from shredding a ship when failing to initiate time warp. (Prevents the ship from being shredded, and will allow you to quicksave and exit.)
  

Cheers,

~Claw

Edited July 25, 2015 by Claw

[Ser]

Claw, ModuleGimbal still has some issues for me: it shows plumes at VAB and I suspect that other troubles like inability to start an engine with action menu persists too.

PilotRSASFix causes weird behaviour at launchpad: vessel's parts start to move slowly in different directions exploding and going through the launch pad.

I use a lot of mods, among them are FAR, DRE, Kerbal Joint Reinforcement, AJE, BetterTimeWarp, KerbalMass, RealHeat

[smjjames]

• ModuleGrappleNodeFix - Fixes a bug which crashes KSP when in not in control of the claw ship while clawing (ship plummets to planet or game crashes). Also adds a bug trap (but not quite a fix) that prevents the Claw Kraken from shredding a ship when failing to initiate time warp. (Prevents the ship from being shredded, and will allow you to quicksave and exit.)
  

Cheers,

~Claw

I wonder if that will help with an existing KIS/KAS bug....

[tg626]

Also, it StockPlus chutes now have a safe/risky/unsafe indicator on the stage icons.

Thank god!! Why oh why wasn't that stock?!?

[steve_v]

[*] ModuleGrappleNodeFix - Fixes a bug which crashes KSP when in not in control of the claw ship while clawing (ship plummets to planet or game crashes). Also adds a bug trap (but not quite a fix) that prevents the Claw Kraken from shredding a ship when failing to initiate time warp. (Prevents the ship from being shredded, and will allow you to quicksave and exit.)

Oh yes, thank you.

About time that was sorted, Claw to the rescue again.

[Navi1982]

Good job! Like all what and how you are implementing. Many thanks. And, I hope you will spend some time for another fix - Precision Controls Toggle. As it setted on CapsLock key, the main problem is a LED on keyboard that misleading pleyers about the status of Precision Controls, especially when a rapid intervention in flight control of vessel is required and map orientation is preferable. I propose it to be set in function of CapsLock Led status...

What I mean... Since I own programming skills (unfortunately the old school) in assembler, I am sure that the state of the LEDs on the keyboard can be changed without pressing the key. And even more, to be checked. So, I propose that:

1. At the time of switching to the vessel, to check status of LED CapsLock and according its state to set right Precision Controls Toggle, and then transfer control to the player.

2. So if Precision Controls Toggle function can be assigned to any key, then calling this function can set desired state of CapsLock LED.

3. CapsLock LED state changing must be optionally, when Precision Controls Toggle function is called. I suppose it must be done through the configuration file, like the activation of the StockPlus.

This kind of fix will be very useful. And I hope this is posible via modern programming techniques.

Thanks in advance.

[steve_v]

Gets my vote too, it's been a minor annoyance for a while.

[includao]

Claw, ModuleGimbal still has some issues for me: it shows plumes at VAB and I suspect that other troubles like inability to start an engine with action menu persists too.

PilotRSASFix causes weird behaviour at launchpad: vessel's parts start to move slowly in different directions exploding and going through the launch pad.

I use a lot of mods, among them are FAR, DRE, Kerbal Joint Reinforcement, AJE, BetterTimeWarp, KerbalMass, RealHeat

+1 same situation here

[Claw]

Claw, ModuleGimbal still has some issues for me: it shows plumes at VAB and I suspect that other troubles like inability to start an engine with action menu persists too.

PilotRSASFix causes weird behaviour at launchpad: vessel's parts start to move slowly in different directions exploding and going through the launch pad.

I use a lot of mods, among them are FAR, DRE, Kerbal Joint Reinforcement, AJE, BetterTimeWarp, KerbalMass, RealHeat

Well, I can think of one thing off hand that I can do to possibly fix the ModuleGimbal in the editor, although this doesn't happen to me when running it by itself.

I'm really not sure about PilotRSASFix, since all it does is modify the SAS thresholds. So in this case I'd need some logs to see if there are errors or incompatibilities that are leading to this behavior.

What I mean... Since I own programming skills (unfortunately the old school) in assembler, I am sure that the state of the LEDs on the keyboard can be changed without pressing the key. And even more, to be checked. So, I propose that:

I know what you are talking about, but I'm not sure off hand how easy that is to accomplish within KSP since Unity handles all the inputs/outputs. It might very well be aware of what the caps lock state is, but maybe isn't being checked by KSP. I'm really not sure, and would have to investigate first.

As with other bugs, what would always help in speeding the process along is if you could provide exact (and short) replication steps that demonstrate the behavior.

EDIT:

Also, I'm not intentionally ignoring the other requests over the last couple weeks. Tbh, it was a bit of a struggle to get this update together. So now I will try to go back and get to the other requests if possible.

Cheers,

~Claw

Edited July 25, 2015 by Claw

[smjjames]

Cool new avatar pic Claw. Edit: I liked the Phoenix one better IMO.

Anyways, I'm noticing that when I load a ship for the first time after starting KSP and a new save, I get a couple of exceptions from the MGNfix. It doesn't appear again and in order to trigger them, you have to restart KSP.

NullReferenceException: Object reference not set to an instance of an object
  at ClawKSP.MGNFix.OnDestroy () [0x00000] in <filename unknown>:0 
UnityEngine.Object:DestroyImmediate(Object, Boolean)
UnityEngine.Object:DestroyImmediate(Object)
PartLoader:StripComponent(GameObject)
PartLoader:CreatePartIcon(GameObject, Single&)
PartLoader:ParsePart(UrlConfig, ConfigNode)
:MoveNext()

NullReferenceException: Object reference not set to an instance of an object
  at ClawKSP.MGNFix.OnDestroy () [0x00000] in <filename unknown>:0 
UnityEngine.Object:DestroyImmediate(Object, Boolean)
UnityEngine.Object:DestroyImmediate(Object)

:MoveNext()

Output log from the first load: http://sta.sh/01mctl93r7jf

I'm noticing that most of them are triggering for the MKS expandotubes, which use the same module as the Klaw (which is why they're really bad krakenbait), however, it also triggers for a few other stuff which don't use that module, like the MKS Flexotube which is just an enlarged KAS pipe.

[Claw]

Cool new avatar pic Claw. Edit: I liked the Phoenix one better IMO.

Haha. Yes, I am quite indecisive at the moment.

Anyways, I'm noticing that when I load a ship for the first time after starting KSP and a new save, I get a couple of exceptions from the MGNfix. It doesn't appear again and in order to trigger them, you have to restart KSP.

Well, this seems easy enough to get rid of, actually. Although I can trap the time warp shredding claw kraken, I still haven't found the exact cause. This error looks like it's coming from a piece of code that I suspect isn't fixing anything, though I can't really confirm that since the bug is so difficult to trigger. Perhaps I will add a bit more error checking and see if that avoids the errors.

I'm noticing that most of them are triggering for the MKS expandotubes, which use the same module as the Klaw (which is why they're really bad krakenbait), however, it also triggers for a few other stuff which don't use that module, like the MKS Flexotube which is just an enlarged KAS pipe.

It's strange to me that it would trigger on something that isn't using the ModuleGrappleNode, since that is what this fix latches onto. It shouldn't be getting loaded onto a part that doesn't have it. So either there's another interaction bug in here, or it's actually lingering around orphaned in memory. I say that it might be orphaned, because that's actually what I suspect is happening with this claw bug to begin with (orphaned code is still out there trying to execute).

Thanks for the report. I'll try to dig through in more detail.

Cheers,

~Claw

[smjjames]

Haha. Yes, I am quite indecisive at the moment.

Well, this seems easy enough to get rid of, actually. Although I can trap the time warp shredding claw kraken, I still haven't found the exact cause. This error looks like it's coming from a piece of code that I suspect isn't fixing anything, though I can't really confirm that since the bug is so difficult to trigger. Perhaps I will add a bit more error checking and see if that avoids the errors.

It's strange to me that it would trigger on something that isn't using the ModuleGrappleNode, since that is what this fix latches onto. It shouldn't be getting loaded onto a part that doesn't have it. So either there's another interaction bug in here, or it's actually lingering around orphaned in memory. I say that it might be orphaned, because that's actually what I suspect is happening with this claw bug to begin with (orphaned code is still out there trying to execute).

Thanks for the report. I'll try to dig through in more detail.

Cheers,

~Claw

Actually, to correct what I said, they're actually appearing during the loading proccess, not when loading a craft after opening a save. Noticed that just now.

Edit: I'm noticing that when I crash a ship (not sure if it's a particular part or what though), intentionally in this case, I get spammed with an exception from the MGNfixaddon:

ArgumentOutOfRangeException: Argument is out of range.

Parameter name: index
  at System.Collections.Generic.List`1[Part].get_Item (Int32 index) [0x00000] in <filename unknown>:0 

  at ClawKSP.MGNFixAddon.FixedUpdate () [0x00000] in <filename unknown>:0 

Output log: http://sta.sh/01lxi15v9bf1

Edit2: Yeah, it's when whatever craft (even debris) you're focused on gets destroyed.

Edited July 26, 2015 by smjjames

[Navi1982]

I know what you are talking about, but I'm not sure off hand how easy that is to accomplish within KSP since Unity handles all the inputs/outputs. It might very well be aware of what the caps lock state is, but maybe isn't being checked by KSP. I'm really not sure, and would have to investigate first.

As with other bugs, what would always help in speeding the process along is if you could provide exact (and short) replication steps that demonstrate the behavior.

Cheers,

~Claw

Just a link how to check state of CapsLock and other keyboard leds in unity - may be it will be useful... http://answers.unity3d.com/questions/219017/toggling-caps-lock-or-even-just-the-indicator-ligh.html

I can imagine the following steps:

1. When flying scene is calling - check state of CapsLock led on keyboard and set Precision Controls to: a) blue status (fine precision control) if it is On, and red status (hard precision control). (blue and red - it's mean color of control indicators in left-bottom side of screen that is shown when 3'rd person view camera mod is active, and I don't know another way to check it's status except to switch camera mode)

2. Do "1." if CheckCapsLedState = true from StockPlusController.cfg file. I mean, Check Led Status and set PrecisionControl if that option (CheckCapsLedState) is set to true in case when PrecisionControlsToggle is set to another key or CapsLock key - no mater.

in code (i prefer basic language):

<best place of this code would be in OnFlySceneLoad (not sure how it is called but you know what I mean) event>
<initialize some variables here before set somthing: read from StockPlusController.cfg option CheckCapsLedState and check CapsLock led state>
if CheckCapsLedState = true then
  if Led = true then          ' led is on?
    <set contol precision in Blue state - fine precision control>
  else
    <set contol precision in Red state - hard precision control>
  endif
endif

Next code must be implemented after PrecisionControlsToggleKey is pressed:

if CheckCapsLedState = true then
  if PrecisionControlsState = Blue then
    <set led of CapsLock to be On>
  else
    <set led of CapsLock to be Off>
  endif
endif

I really have no idea how to implement that... But, in general it might be in such way....

Many people will say to you many thanks for that fix. Good luck!

Edited July 26, 2015 by Navi1982

[anxcon]

for parachute fix, the source doesnt seem to be listed on your github with rest of the modules?

[Captain Sierra]

Claw, I made this report here: http://forum.kerbalspaceprogram.com/threads/129945-BUG-Decouplers-not-stopping-fuel-flow?p=2105401#post2105401

Since there's such a long wait to 1.1, I beg you. Deliver us from this evil.

[Claw]

for parachute fix, the source doesnt seem to be listed on your github with rest of the modules?

It ought to be. I'll double check.

Claw, I made this report here: http://forum.kerbalspaceprogram.com/threads/129945-BUG-Decouplers-not-stopping-fuel-flow?p=2105401#post2105401

Since there's such a long wait to 1.1, I beg you. Deliver us from this evil.

Well, I posted in your report thread (which you probably won't like the answer). I /can/ fix this, but it's not a decoupler bug so much as the way the fuel flow mode works for jet engines.

Cheers,

~Claw

[Amedee]

Anyways, I'm noticing that when I load a ship for the first time after starting KSP and a new save, I get a couple of exceptions from the MGNfix. It doesn't appear again and in order to trigger them, you have to restart KSP.

NullReferenceException: Object reference not set to an instance of an object
  at ClawKSP.MGNFix.OnDestroy () [0x00000] in <filename unknown>:0 
UnityEngine.Object:DestroyImmediate(Object, Boolean)
UnityEngine.Object:DestroyImmediate(Object)
PartLoader:StripComponent(GameObject)
PartLoader:CreatePartIcon(GameObject, Single&)
PartLoader:ParsePart(UrlConfig, ConfigNode)
:MoveNext()

NullReferenceException: Object reference not set to an instance of an object
  at ClawKSP.MGNFix.OnDestroy () [0x00000] in <filename unknown>:0 
UnityEngine.Object:DestroyImmediate(Object, Boolean)
UnityEngine.Object:DestroyImmediate(Object)

:MoveNext()

Output log from the first load: http://sta.sh/01mctl93r7jf

I'm noticing that most of them are triggering for the MKS expandotubes, which use the same module as the Klaw (which is why they're really bad krakenbait), however, it also triggers for a few other stuff which don't use that module, like the MKS Flexotube which is just an enlarged KAS pipe.

If it helps anything, I also see this MGNFix thing in my ksp.log in an early career game, only stock parts, only MM 2.6.6, CTT 2.1 and SBFM 1.0.4b.1 installed.

[Claw]

I'm noticing that when I load a ship for the first time after starting KSP and a new save, I get a couple of exceptions from the MGNfix. It doesn't appear again and in order to trigger them, you have to restart KSP.

Actually, to correct what I said, they're actually appearing during the loading proccess, not when loading a craft after opening a save. Noticed that just now.

Edit: I'm noticing that when I crash a ship (not sure if it's a particular part or what though), intentionally in this case, I get spammed with an exception from the MGNfixaddon:

ArgumentOutOfRangeException: Argument is out of range.

Parameter name: index
  at System.Collections.Generic.List`1[Part].get_Item (Int32 index) [0x00000] in <filename unknown>:0 

  at ClawKSP.MGNFixAddon.FixedUpdate () [0x00000] in <filename unknown>:0 

Output log: http://sta.sh/01lxi15v9bf1

Edit2: Yeah, it's when whatever craft (even debris) you're focused on gets destroyed.

If it helps anything, I also see this MGNFix thing in my ksp.log in an early career game, only stock parts, only MM 2.6.6, CTT 2.1 and SBFM 1.0.4b.1 installed.

Excellent. Thank you for the log reports. I am reworking this module and including some other great finds by other forum members. So a fix to this AOOR might not be immediate, but that's because I'm working to make a bigger fix.

Thanks again!

~Claw

[Grumman]

What is the purpose of the Flash Speed and Flash Time variables now visible on parachutes?

[Claw]

What is the purpose of the Flash Speed and Flash Time variables now visible on parachutes?

Well, those were debug tools that I thought I hid. But since they are there, they simply control how fast and how long the safe/risky/unsafe indicator blinks when a new condition occurs (for example, transitioning from risky to safe).

Cheers,

-Claw

[Claw]

Version 1.0.4b.2 -- Updated for more KSP 0.23.5 craziness! (Yes, more Claw updates!)

Significant changes:

• ModuleGrappleNodeFix - I think this is now in a real releasable state. Fixes two major bugs and provides a failsafe: Fixes bug when clawing onto the active vessel; Fixes bug which prevents activation of time warp; Fail Safe prevents kraken eating ship during time warp failure
  
• ModuleParachuteFix - Re-release of this module. 1.0.4b.1 had debug code in it (I released the wrong .dll, sorry).
  
• ModuleGimbalFix - Added a bit of code to (hopefully) improve mod compatibility.
  

Cheers,

~Claw

- - - Updated - - -

Edit: I'm noticing that when I crash a ship (not sure if it's a particular part or what though), intentionally in this case, I get spammed with an exception from the MGNfixaddon:

ArgumentOutOfRangeException: Argument is out of range.

Parameter name: index
at System.Collections.Generic.List`1[Part].get_Item (Int32 index) [0x00000] in <filename unknown>:0

at ClawKSP.MGNFixAddon.FixedUpdate () [0x00000] in <filename unknown>:0

Output log: http://sta.sh/01lxi15v9bf1

Edit2: Yeah, it's when whatever craft (even debris) you're focused on gets destroyed.

This should also be fixed.

[Claw]

Rejoice, ye followers of the Claw!

(The grabber part, not me! )

The claw turned out to be quite the adventure. I wouldn’t say it is the most complex of my fixes, but it is certainly the one that took the most work. This bug has been around for nearly a year and a half now, and it took quite some effort to really get down to it. Given how difficult this bug was to replicate, it was very difficult to determine the cause, much less build and test a fix.

I would be completely remiss if I didn’t provide a special thanks to three of our very own Kerbonauts for their efforts in hunting down this bug. With their combined efforts, the development of this (hopeful) fix has been greatly accelerated. Feel free to hand them some rep if you are so inclined.

• littlebluegaming – Who posted some initial findings here in the BUST thread, providing a save file with reproduction steps. While those steps replicated infrequently, the save contributed to the experimental fix.
  
• fireblade274 – Who posted a save file and discussion here. This post and discourse with diomedea led to some more confirmation for the experimental fix.
  
• Vkihyone – Whose .craft files here in the BUST thread finally broke the ground I needed to nail down the core issue.
  
• ScienceLion also posted some reproduction steps here for another claw bug, which was fixed in the first release of ModuleGrappleNodeFix.

There were certainly many others who have posted reports and thoughts for some months now. It's quite impossible for me to list them all, so please accept my thanks for everyone who has had a hand in this.

Because of the volatility of this bug, I wanted to provide some extra background about this fix. This way, if any of you encounter a problem, you can provide me some very precise feedback about what happened and how. This fix contains three primary parts, one of which is a fail-safe that I am leaving in until I am more confident about the primary fix.

- Physics Crash when the active ship is clawed onto.

This first bug was fixed in the original (experimental) release of ModuleGrappleNodeFix. This bug occurs when you drive two vessels into each other, but it’s the ship you’re not in control of that has the claw. This bug is easy to replicate, and should be 100% fixed (fingers crossed).

Something here that still needs testing: Ensure the vessel docking hierarchy doesn’t cause problems with this fix.

- Time-Warp Primary Fix

The primary fix should (ideally) prevent the issue where initiating non-physical time-warp results in failed warp and a destroyed ship. This “glue kraken†typically shows up as a ship that fails to enter time warp, followed by the root part freezing in place while the rest of the ship bends and rips off. As far as I tested, the primary fix catches the errors I know about. However, I added a secondary (backup) fix that isn't as clean as the primary fix, but will hopefully catch things if they manage to slip through the primary fix.

- Time-Warp Fail-Safe

The fail-safe is a fall back check that activates in the event that the primary fix fails. This was the original “fix†that came out in the experimental release. This was mostly an interim fix while investigation was ongoing. I’ve decided to leave it in for now since it’s effective, and I would like some more testing on the primary fix before I remove the fail-safe.

The idea behind the fail-safe is that when time-warp initiation fails, the fail-safe will correct some physics problems long enough to allow the user to save the game and exit. The vessel’s orbit will likely still experience phantom-force issues (causing changes in orbital parameters). However, the fail-safe should prevent the active ship from being shredded by phantom forces and allow enough time to save and restart.

Note: When the fail-safe is triggered, it will display a warning on the screen to save and restart. I recommend you do NOT go to another vessel. Quicksave and exit the game normally, getting out of flight mode as quickly as able to prevent deterioration of the active vessel’s orbit. If you exit normally, the persistent should be fine, and you’ll have the quicksave as a backup.

Something to note with this fix is that the core problem will still cause KSP to throw a NullReferenceException, and (in some cases) the Fix might also throw an NRE (though I think I've trapped them all). However, there is a hierarchy of code taking place. So hopefully when an error is encountered, follow on code should resolve the issue. If you do encounter any of these, please post the appropriate logs, description of events leading up to the error, and pictures of the craft. It’s important to note that while I appreciate all feedback about this, it’s a complex bug to track. So, in that regard, scrimpy bug reports, crazy reproduction steps, or 10MB log files to comb through are not particularly helpful. If you aren't quite sure what happened, a non-descript post of “I did X and Y happened†might be more useful in the BUST thread than in here, so that other people might see and help focus on the issue.

What’s next for the infamous fixes?

Well, quite frankly this has been a lot of work. So I think rather than taking on another ambitious bug right at the moment (such as the super-heating bug), I’m going to circle back around and work on cleaning up and internally bug-fixing the fixes themselves. The next release will be focused on internal bug fixing, the release after that will focus on building new stock bug fixes. I am expecting the internal bug-fixing will last around two weeks.

There are already a few internal bugs I know about, but if you have encountered other issues with my fixes or with StockPlus, feel free to post about them (even if you already posted previously).

As I said before, more detail is better. Also, while I am not anti-add-on, if you post me a list of 60 mods in your install with “I have a non-descript problem,†it’ll be difficult for me to get to. The more you can narrow it down to specific mod incompatibility or specific problem, the quicker it is for me to fix...which ultimately means I’m more likely to get to it.

Cheers!

~Claw