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

[bac9]

I think I found an issue with the tweakable UI, but I'm not sure how exposed that part of KSP is to allow a third-party fix. It's pretty easy to replicate on any stock part in the editor, like a LFO fuel tank:

• Open the tweakable menu: ~1.1mb RAM allocated
  
• Close the tweakable menu: ~1.1mb RAM deallocated
  
• Move the slider: ~1-3mb additional RAM allocated per second
  

I suspect there is a leak somewhere in the tweakable UI, because the memory used on tweaking is never freed unless you change the scene (i.e. trigger garbage collection). I have managed to bring memory usage from 2.5Gb to 3Gb through simply tweaking stock fuel tank oxidizer and fuel values for a few minutes. Can someone confirm the same behavior and @Claw, can you chime in on the possibility of accessing tweakable UI innards to potentially fix it?

[smjjames]

@claw, I think it was just a fluke plus the ladder slide thing since I haven't had any problems since with the EVA.

[koluch]

Hey Claw!

Thanks for all the hard work on fixing "stock KSP bugs"

I`m here with a rant about the chute bug. I know that the ChuteFixer solves the issue with chutes missing after a quickload, however I hoped so much to have it fixed in a more fundamental way.

Scenario: I have a lifter with lots and lots SRB boosters, so I figured I could roleplay Musk and get them all safely landed and recovered, so I packed every booster with 3 chutes and set them to deploy together with the decouplers.

Sadly with the boosters going straight up when chutes/decouplers are fired, there soon comes the moment when boosters vertical velocity becomes zero and the chutes are cut. No reusable boosters for me ( and I know they are intended to be resuable - its even in their description! )

The key point is that it should be fixed with just a single line of code that would add a check like "not on the ground" into the check "velocity almost zero" into the code that cuts them.

Should I put this rant into the bug description for the relevant bug, what do you think?

[Claw]

Hey Claw!

Thanks for all the hard work on fixing "stock KSP bugs"

...

Sadly with the boosters going straight up when chutes/decouplers are fired, there soon comes the moment when boosters vertical velocity becomes zero and the chutes are cut. No reusable boosters for me ( and I know they are intended to be resuable - its even in their description! )

Thanks! I hope the fixes are working well for you.

What you are describing is a separate bug than the shrunken parachute bug. Also, I have reported the one you describe and it's known to the developers, so hopefully it'll get fixed somewhere in the Beta pipeline.

Just to be certain we are talking about the same thing though, if your boosters are below ~23km altitude on Kerbin and go outside of 2.5km from the ship you are controlling, they will be deleted regardless of if you have parachutes on them or not. It doesn't sound like that's what you are describing, because I know about the 0m/s parachute cut that you're talking about. I suppose I could actually build a fix for that too, although I think it's experienced a lot less. If you offset your rocket to the side even just a little while it's launching, you can avoid the parachute cutoff problem (the booster will retain some sideways velocity and the chute remains).

Oh, and welcome to the forums!

Cheers,

~Claw

[koluch]

Thanks for the welcome!

Yeah you got me exactly right. Hope this one gets fixed by the Squad soon... By the way wonder what kind of API they expose for plugin developers that might help fixing that before they bother to. Do you have any links I could look at?

Koluch.

[linuxgurugamer]

Thanks! I hope the fixes are working well for you.

What you are describing is a separate bug than the shrunken parachute bug. Also, I have reported the one you describe and it's known to the developers, so hopefully it'll get fixed somewhere in the Beta pipeline.

Just to be certain we are talking about the same thing though, if your boosters are below ~23km altitude on Kerbin and go outside of 2.5km from the ship you are controlling, they will be deleted regardless of if you have parachutes on them or not. It doesn't sound like that's what you are describing, because I know about the 0m/s parachute cut that you're talking about. I suppose I could actually build a fix for that too, although I think it's experienced a lot less. If you offset your rocket to the side even just a little while it's launching, you can avoid the parachute cutoff problem (the booster will retain some sideways velocity and the chute remains).

Oh, and welcome to the forums!

Cheers,

~Claw

You could also put a seperaton on each booster to push it away to the side. That would also keep them from hitting a 0 velocity.

[basic.syntax]

The description for the S1 SRB encourages players to try to save them.

"This super heavy booster is designed to be recovered after jettisoning. Once recovered, it is refurbished and refueled for another launch."

If the laws of physics can't be changed to accommodate the suggestion, I think the text needs to be changed.

(I'm actually MORE interested in saving expensive engines and tanks from heavy first stages. Sadly, this seems to be a "cost of doing business" you just have to accept - in real life, and in game.)

[BigFatStupidHead]

Claw,

I see you've got asymmetric flameouts on you hitlist. Here is one way in which it can be dealt with; it may help you develop your fix.

[linuxgurugamer]

The description for the S1 SRB encourages players to try to save them.

"This super heavy booster is designed to be recovered after jettisoning. Once recovered, it is refurbished and refueled for another launch."

If the laws of physics can't be changed to accommodate the suggestion, I think the text needs to be changed.

(I'm actually MORE interested in saving expensive engines and tanks from heavy first stages. Sadly, this seems to be a "cost of doing business" you just have to accept - in real life, and in game.)

I wonder if you put a mechjeb package on each SRB, will that allow the game to keep them around even after they get more than 2.5km away?

[smjjames]

I wonder if you put a mechjeb package on each SRB, will that allow the game to keep them around even after they get more than 2.5km away?

I actually tried something similar, but I'm not sure if they disappeared due to that or due to the parachutes not fully slowing them down.

[Claw]

The description for the S1 SRB encourages players to try to save them.

"This super heavy booster is designed to be recovered after jettisoning. Once recovered, it is refurbished and refueled for another launch."

If the laws of physics can't be changed to accommodate the suggestion, I think the text needs to be changed.

(I'm actually MORE interested in saving expensive engines and tanks from heavy first stages. Sadly, this seems to be a "cost of doing business" you just have to accept - in real life, and in game.)

I wonder if you put a mechjeb package on each SRB, will that allow the game to keep them around even after they get more than 2.5km away?

I actually tried something similar, but I'm not sure if they disappeared due to that or due to the parachutes not fully slowing them down.

Yeah, unfortunately the game's description is misleading. And there is a common misperception about atmospheric deletion. I'll explain in a little more detail than I usually do...

"On Rails" - When craft are not within physics range (~2.5km) of the ship being controlled, they are put into a state called "On Rails." Craft are put on rails to simplify physics calculations for the game.

Craft that are "On Rails" get deleted for basically two reasons:

1) On an airless world, they get deleted when striking the terrain.

2) On worlds with an atmosphere, they are deleted when the ship encounters > 0.1 atmospheres of pressure.

On Kerbin, 0.1 atmospheres is about 23km altitude. So any craft experience more than 0.1 atmospheres (which means is below ~23km on Kerbin) and is "On Rails" (also known as outside Physics Range) is deleted. Period.

Some people have been adding on the statement "and isn't being controlled." This is redundant, because any ship the player is controlling defines the center of physics range. It is impossible for the ship the player is controlling to "go outside of physics range" because physics follows the ship being controlled. The statement "isn't being controlled" has been mistaken to mean "without a probe core (or MJ, or whatever)," but that's not the case. In stock, craft deletion on atmospheric bodies follows these two rules, and no others.

"On Rails" and greater than 0.1 atmospheres.

Hopefully that clears it up.

That being said, there are several mods that will refund money automatically for stages that are deleted. DebRefund and StageRecovery are two that I can think of off hand. There are also mods that extend physics range beyond 2.5km, though I don't know of any current ones off hand. (TTNeverUnload was one, but I think that's old.)

Cheers,

~Claw

[Claw]

Claw,

I see you've got asymmetric flameouts on you hitlist. Here is one way in which it can be dealt with; it may help you develop your fix.

I do, and I've seen that mod, but thanks for pointing it out. I've slowed development of my mod given that one's existence and more pressing stock bugs.

I do have a sort of working prototype. My mod works on a slight revamp of the intake air system, rather than reshuffling intakes. Although I think my approach is a bit beyond my usual flavor of "non-interference" for stock bug fixes.

Cheers!

~Claw

[Claw]

My apologies. I just removed SymmetryActionFix again due to some bugs I found that interfere with the new stock symmetry functions. I'm not sure if it's a mod interaction problem, or purely with my module.

The only difference between v0.1.7b and v0.1.7c is the removal of SymmetryActionFix.dll. So you can just delete that file from your install (you don't have to download the whole thing again). I'll try (again) to fix this.

Cheers,

~Claw

[smjjames]

Like what bugs?

[Epoxide]

I'm getting a super weird StickyLaunchPad bug, I don't have a clue if there is a mod installed that's causing it, I have lots of them installed. It's caused when you have something radially attached to a RT-10, I'm having this bug on T1 Launchpad. The entire vessel tries to move but is stuck to the radially attached object. I'd be glad to upload any logs that could help if you could point me to them. Not sure if this would be the right place to post it in.

[linuxgurugamer]

Yeah, unfortunately the game's description is misleading. And there is a common misperception about atmospheric deletion. I'll explain in a little more detail than I usually do...

"On Rails" - When craft are not within physics range (~2.5km) of the ship being controlled, they are put into a state called "On Rails." Craft are put on rails to simplify physics calculations for the game.

Craft that are "On Rails" get deleted for basically two reasons:

1) On an airless world, they get deleted when striking the terrain.

2) On worlds with an atmosphere, they are deleted when the ship encounters > 0.1 atmospheres of pressure.

On Kerbin, 0.1 atmospheres is about 23km altitude. So any craft experience more than 0.1 atmospheres (which means is below ~23km on Kerbin) and is "On Rails" (also known as outside Physics Range) is deleted. Period.

Some people have been adding on the statement "and isn't being controlled." This is redundant, because any ship the player is controlling defines the center of physics range. It is impossible for the ship the player is controlling to "go outside of physics range" because physics follows the ship being controlled. The statement "isn't being controlled" has been mistaken to mean "without a probe core (or MJ, or whatever)," but that's not the case. In stock, craft deletion on atmospheric bodies follows these two rules, and no others.

"On Rails" and greater than 0.1 atmospheres.

Hopefully that clears it up.

That being said, there are several mods that will refund money automatically for stages that are deleted. DebRefund and StageRecovery are two that I can think of off hand. There are also mods that extend physics range beyond 2.5km, though I don't know of any current ones off hand. (TTNeverUnload was one, but I think that's old.)

Cheers,

~Claw

Wow! What a great explanation!

Even though it sucks.

I'm using StageRecovery, which is better than nothing, I guess.

Thank you!

[Claw]

Like what bugs?

Two specific bugs that I encountered:

- Broken (even more so than usual) symmetry on symmetry

- Situations where craft files create circular symmetry links, leading to errors when deleting a part in the circular reference.

I haven't run into anything that breaks the save, but it's been causing errors with craft files and craft building. I think I can fix the SymmetryActionFix to function like it did before, but some of the additional checks I built need to be pulled (I don't think they are working properly).

Cheers,

~Claw

[Claw]

I'm getting a super weird StickyLaunchPad bug

Well, that's a strange one. My request would be to see if you can replicate it with a stock install, or at least a 100% stock craft in your game. If you can do that, post the .craft file (because specifics inside the file can matter). Also post specific launch conditions, such as specifying a tier 1 launch pad. I will also try to replicate your picture, but I can't tell what that part is below the Mk1.

Cheers,

~Claw

[Rebelgamer]

^That part is from DMagic's Orbital Science mod.

[Epoxide]

Well, that's a strange one. My request would be to see if you can replicate it with a stock install, or at least a 100% stock craft in your game. If you can do that, post the .craft file (because specifics inside the file can matter). Also post specific launch conditions, such as specifying a tier 1 launch pad. I will also try to replicate your picture, but I can't tell what that part is below the Mk1.

Cheers,

~Claw

I did some more testing and narrowed it down to an issue with the mod Universal Storage, when using the part Universal Storage Core: Quad and attaching RT-10 to it and then something radially to the RT-10 the radially attached object acts like it's completely stuck. As this isn't a stock issue I'll just post it in that mods thread instead.

[Zero266]

Has anyone had trouble with the high altitude parachutes, the orange one, or is it just me?

[Claw]

Has anyone had trouble with the high altitude parachutes, the orange one, or is it just me?

Can you be more specific? What kind of trouble, at what altitude, and when doing what? Personally I don't use that one much.

Cheers,

-Claw

[Waladil]

I just downloaded the stock bug fixes because I was hit by a Kerbal turning into debris when he was knocked out of an external command seat. The bugfix doesn't seem to have restored him, is there another step I need to take to fix him? I've been trying to grab him with an AGU then release, but it's being really tricky since I can't control him and he's just standing on a Minmus slope.

Also, is there some way to confirm installation? I put the various .dlls into the gamedata folder like most of my other mods, but I dunno if I missed a step.

[Claw]

For installation, that's all you need to do. You can confirm that it's being loaded by KSP by opening the file KSP_Data\output_log.txt (assuming windows) and searching for this line

Non platform assembly: C:\Games\KSP_win_0.90.0.705_Dev\GameData\StockBugFixModules\KerbalDebrisFix.dll (this message is harmless)

My fix usually wakes them up if you switch vessels nearby (using ] or [ ). If you load directly to the kerbal and do nothing else, it probably won't wake him up. If that's not working for you, try waking him up with this thread: http://forum.kerbalspaceprogram.com/threads/75586-Master-Thread-Unresponsive-Kerbals-in-EVA

Cheers,

~Claw

[Waladil]

I figured it out shortly after writing the post, but before the moderator approved the post -- I even tried to remove the post from the moderator queue!

Anyway, apparently one must go from tracking station to a nearby vessel. At first I went from the tracking station to the kerbal himself and that didn't work, nor did switching around "ships" with [ or ] right after, but returning to the tracking station then loading the craft that he was knocked out of worked.