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

[iFlyAllTheTime]

...I will give it a try though, since I'm double checking other things at the moment.

I'll post an update soonish.

Cheers,

~Claw

Appreciate it!

[Claw]

Just updated Release to v.1.2a. Incredibly minor fixes and probably not necessary to download unless you're having a problem with the EVAEjectionFix (since it was compiled with the wrong .NET).

Would the AnchoredDecouplerFix.dll work with 0.24.2 install that I'm running?

I just tested all three .dlls with 0.24.2 and they are all compatible. (Although the EVAEjection fix isn't really needed, it causes no problems.) The parachute quickload fixer and the decoupler fix both seem to work correctly. I can't swear that they will work with your install since I don't know what else you have installed, but so far I haven't heard of any incompatibilities.

I don't know if it's compatible with tweakable everything since I don't know how it functions, but it doesn't look like the tweakable users have come back with complaints.

Hope that helps,

~Claw

Edited October 28, 2014 by Claw

[Tivec]

I am definitely giving you a huge thumbs up for this bug fix - especially for the EVAEjection fix, this bug was causing me MUCH headache.

[iFlyAllTheTime]

Please accept my gratitude for coming up with the decoupler fix.

I'm curious to know what caused the issue all of a sudden in 0.24.2 in the first place.

Never had this before that update.

Also, would love to know how you tackled it.

Don't need to know the code, a simple explanation in layman terms would suffice.

Edited October 29, 2014 by iFlyAllTheTime

[LvL]

Does anyone else experience that sometimes, when in the VAB or SPH, your keyboard just randomly decides to turn off? If you can fix this, PLEAS FIX THIS CLAW.

[Guest]

Does anyone else experience that sometimes, when in the VAB or SPH, your keyboard just randomly decides to turn off? If you can fix this, PLEAS FIX THIS CLAW.

Are you using a wireless keyboard? Some of the logitech wireless especially have had problems.

I also want to say that at the very least this thread should be stickied! And, I think that Squad should roll out a patch with these fixes included. Great work Claw, and thanks for this. It has made the game so much more enjoyable to not have to put up with these annoying bugs anymore.

[Claw]

I am definitely giving you a huge thumbs up for this bug fix - especially for the EVAEjection fix, this bug was causing me MUCH headache.

Thank you very much!

Please accept my gratitude for coming up with the decoupler fix.

I'm curious to know what caused the issue all of a sudden in 0.24.2 in the first place.

Never had this before that update.

Also, would love to know how you tackled it.

Don't need to know the code, a simple explanation in layman terms would suffice.

Thank you too!

There was a stack decoupler problem with 0.24.1. In the rush to put out a hotfix for the stack decoupler (0.24.2), the radial decouplers were broken in the process.

The layman explanation of how I fixed it was to disable the stock decoupler. Then I detect when the decoupler is activated, let it separate, then add the decoupler forces in at the appropriate time. After my module is done, it deletes itself so that it won't eat up anymore CPU cycles.

Does anyone else experience that sometimes, when in the VAB or SPH, your keyboard just randomly decides to turn off? If you can fix this, PLEAS FIX THIS CLAW.

I am sorry to hear that oarum, but I'm not sure what you are talking about. Perhaps you should consider submitting a support request to the support forum. If we can help you narrow down your problem better, then I can take a look at possible fixes.

Great work Claw, and thanks for this. It has made the game so much more enjoyable to not have to put up with these annoying bugs anymore.

Thanks Otis. I'm glad I could help.

I do have more fixes in the queue. I'm working on one right now. In the next day or two I will post a list of what I'm planning.

Cheers,

~Claw

Edited October 29, 2014 by Claw

[djnattyd]

I've noticed a weird issue with the decouplers since installing this where they don't fire off together when the stage is activated.

I am running Tweakable Everything and the right click menu is showing the stock decouplers as having a force of -200, the highest I can set them to is 0 but this still doesn't fix the issue of them not separating together.

[J.Random]

I think this thread should be sticky. Fixes for stock bugs are way too important to lose them on Nth page of the forum.

[NathanKell]

Tweakable Everything conflicts with most things, sadly.

[Claw]

I've noticed a weird issue with the decouplers since installing this where they don't fire off together when the stage is activated.

I am running Tweakable Everything and the right click menu is showing the stock decouplers as having a force of -200, the highest I can set them to is 0 but this still doesn't fix the issue of them not separating together.

Sorry about that. I haven't checked but it sounds like tweakable everything works by subtracting the force out. I set the stock decoupler force to an absolute value of zero, which is probably why tweakable everything shows zero as a max.

My module doesn't run until you go into flight mode. So I would say try setting all your decoupler force values before you launch, and don't tweak them after. My fix should use whatever you had tweakable settings at for launch, but I can't guarantee that since I don't know when/how tweakable applies it's tweaked force.

As for all the decouplers not firing off at the same time, can you provide a picture of what you're doing? It's unclear to me if it's a mod-interaction problem or something with my module. I'd be surprised if it's what I've done though because the staging and decoupling is still done by stock KSP. I only fiddle with the forces.

I think this thread should be sticky. Fixes for stock bugs are way too important to lose them on Nth page of the forum.

I'll leave that for another moderator to decide, since I don't want to abuse my powers for my own thread.

But I appreciate the positive feedback!

Cheers,

~Claw

[Claw]

Updated planned fixes. Feel free to post requests/suggestions (with details please). No guarantees that I can/will get to them, but the more details you provide the easier it is for me to narrow it down and work on it.

Cheers,

~Claw

[BudgetHedgehog]

SymmetryActionFix – STATUS: Replicated, In the queue to fix

- In the editors, if a part is placed symmetrically, assigned an action group, then removed and replaced with symmetry, the symmetric parts do not retain the action grouping.

Yes, that please

[LucidPixels]

SymmetryActionFix – STATUS: Replicated, In the queue to fix

- In the editors, if a part is placed symmetrically, assigned an action group, then removed and replaced with symmetry, the symmetric parts do not retain the action grouping.

This bug alone has been responsible for more than its share of rather hairy flights and landings. I am very much looking forward to your next update.

[Claw]

Yes, that please

This bug alone has been responsible for more than its share of rather hairy flights and landings. I am very much looking forward to your next update.

Your requests have been granted. Initial release of SymmetryActionFix is out.

Please bear in mind that this fix ONLY fixes the loss of action groups on symmetric parts. It does not fix any other symmetry bugs in the editor. As such, there are some symmetry bugs that cause this fix to fail. If you place a part and the action groups don't transfer, try lifting the part (or part tree) and placing again.

Of specific note, if you pick up a part that has children, the children become disassociated from their siblings. KSP fixes itself, but my module fails before that happens. Also, symmetry within symmetry is still buggy in stock, and my action group fix will suffer from those bugs. For example: If you lift a part, change the symmetry multiplier, then place the part back on, the module will fail. Again, if you hit one of these bugs, lift the part and place it again.

You can watch the ALT+F2 debug log. My module doesn't throw any warnings. So if you see warnings, it's the stock editor fixing itself. My module shouldn't break anything new, but I didn't want people to think that symmetry is completely fixed with this module.

[Claw]

Initial release of LargeCraftLaunchFix.dll - Fixes launch pad and runway explosions when launching large vessels.

[LucidPixels]

Your requests have been granted. Initial release of SymmetryActionFix is out.

You are a gentleman and a scholar.

Edited November 4, 2014 by LucidPixels

[slumpie]

Initial release of LargeCraftLaunchFix.dll - Fixes launch pad and runway explosions when launching large vessels.

Yay, that's a nice one!

Regarding AsymmetricFlameoutFix: There's actually a workaround for this. The order of placing parts makes the difference.

But great that you're trying to fix it, the workaround isn't very comfortable to use.

[Claw]

Regarding AsymmetricFlameoutFix: There's actually a workaround for this. The order of placing parts makes the difference.

But great that you're trying to fix it, the workaround isn't very comfortable to use.

Yep. In fact Kashua's work made me realize this is fixable with my flavor of fixes. (I try to work with existing mechanics instead of completely replacing things.) I actually have a working flameout fix (proof of concept), but it's far from ready for release.

Thanks for pointing this info out though.

Cheers,

-Claw

[Locob]

Sometimes in the editor when attach a part near of another, it goes bananas on the placement. this occur only with fixed angles placement.

any chance you work on that?

[BudgetHedgehog]

Sometimes in the editor when attach a part near of another, it goes bananas on the placement. this occur only with fixed angles placement.

any chance you work on that?

I believe you are on about this long standing bug? If so, then yeah, I've noticed it and with the new SP+ parts, it's become more common. Would love for Claw to try to fix this

[steve_v]

Thank you Claw, you just made the game 1000% less annoying.

[Claw]

Sometimes in the editor when attach a part near of another, it goes bananas on the placement. this occur only with fixed angles placement.

any chance you work on that?

I believe you are on about this long standing bug? If so, then yeah, I've noticed it and with the new SP+ parts, it's become more common. Would love for Claw to try to fix this

I will take a look, but no promises on this one. I think that code might be buried a bit too deep, and the editor should be getting an overhaul in the next update.

Thank you Claw, you just made the game 1000% less annoying.

Great! I'm glad the fixes are helpful for you.

Cheers,

~Claw

[Claw]

Added some updates to LargeCraftLaunchFix to be a bit more robust. Now works through quickloads, scene transitions, and when approaching a craft on the pad/runway from outside physics range.

Cheers,

~Claw

[John FX]

I'll leave that for another moderator to decide, since I don't want to abuse my powers for my own thread.

No, seriously, this should be a sticky until the bugs are gone in stock. (Can`t you send them a pull request to get your code into the main program?)

While you are fixing the crew manifest, could you make it so that kerbals only go onto any craft if they explicitly put there in the first place instead of jumping on every craft with an empty space? (while you are fixing the `change a part, jeb jumps back on the craft` bug)

I was hoping that the `don`t automatically hire crew` option would do it but it does not.

Meaning, often I want to send up an empty craft (stations, orbital rescue etc) so I make the first part I place a probe core hoping that kerbals will not inhabit the pod I place afterward but no, in their rush to get into space every time they have filled up the first pod (but not any subsequent ones). Is is possible to maybe have a .cfg so that any pod on a craft with a probe core is not filled up automatically?

I`ll totally understand if it is outside the remit for your wonderful and totally needed bugfixes.

Edited November 5, 2014 by John FX