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

[kiwi1960]

Mister Claw! I just found this thread. Thanks for thinking of the gamers and making their game play experience less buggy.

I'm not really aware of any bugs I have encountered in the game, although, my game playing time is bare bones at the moment. So, I have a few questions, just in case.

1) If I don't see any bugs, would this harm my game?

2) Is it incompatible with any mods?

3) does it help with the stutter?

4) Do I need to download ALL the fixes for the version I am using, or just the latest one?

It is people like you that makes living the adventure that is KSP worthwhile, even if you ARE a Squad person... I mean, you don't HAVE to do this, but you do, and I for one appreciate it.

BTW... on a side note, it must have been annoying having Maxwell Smart hunting you back in the 60's.... lets see how old you are now and if you know the "Get Smart" TV reference.

Edited July 13, 2016 by kiwi1960

[Nerfclasher]

sorry I can't but it fixed itself when I restarted ksp

[eberkain]

When I use a stock fairing, after ditching the shell, if I mouse over the ring part that is still on the vessel I get an exception thrown that has to do with the highlighting and the ring does not highlight properly.  I believe this is a stock bug, anyone else see this behavior?

[Randazzo]

You have personally saved my game on at least three occasions now, good sir Claw. This time it was the docking ports.

Thanks yet again.

[Claw]

3 hours ago, eberkain said:

When I use a stock fairing, after ditching the shell, if I mouse over the ring part that is still on the vessel I get an exception thrown that has to do with the highlighting

 

That's the core of the issue that causes kerbals to get stuck on EVA or the docking ports to break. Are you seeing this still with the fixes?

2 hours ago, Randazzo said:

Thanks yet again.

You are very welcome.

[Padishar]

On 7/12/2016 at 6:56 PM, Speadge said:

PS: sorry that i just can reproduce it with mods for now - but it should be "reliable" to test a fix. Sur one could argue that my example could also be fixed with kis/kas... For that reason i dont expect a fix for that by squad anyway.
It just happened to me some times before without KAS so i knew how to fix it... Cant tell you for sure if it still happens in stock.

You may be able to do this in stock with two rovers, drive them close enough to start attracting but apply the brakes so they don't dock.  Then destroy one of the ports with whack a kerbal (you might want to temporarily increase the magnet range to get a bit of clearance so you don't accidentally hit the other port too), or possibly decouple the port from the rover (though I suspect it needs the docking port to be deleted to go wrong).

[lajoswinkler]

@Claw Have you thought about adding a fix that finally lets us lock the camera to a Kerbal, just like we can lock it to the vessel and watch the whole environment move around? I never understood why it won't work on its own because Kerbals are also vessels in the game.

[Claw]

1 hour ago, lajoswinkler said:

lock the camera to a Kerbal, just like we can lock it to the vessel and watch the whole environment move around?

I think that was tried before, but it turns out that kerbals bounce around a lot, which means the camera bounces around a lot also. Might be possible to smooth out the camera motion, but then it wouldn't be as hard locked as the equivalent vessel camera.

[lajoswinkler]

6 hours ago, Claw said:

I think that was tried before, but it turns out that kerbals bounce around a lot, which means the camera bounces around a lot also. Might be possible to smooth out the camera motion, but then it wouldn't be as hard locked as the equivalent vessel camera.

They don't bounce on orbital EVA, unless you smack them into something. In any case, not only would it be useful, but also nice for making movies.

[Claw]

On 7/13/2016 at 11:00 AM, kiwi1960 said:

I'm not really aware of any bugs I have encountered in the game, although, my game playing time is bare bones at the moment. So, I have a few questions, just in case.

Well, I just noticed I missed this post entirely. I remember reading it, but I must have been mobile and couldn't reply at the time...

1) No harm should be done to your game. Also, you should be able to uninstall it at any time and your save game will still be usable.

2) There are some incompatibilities. The main one I know of is that the Parachute Plus is not compatible with RealChutes. The other incompatible modules that I know of off hand have been removed. In the case of any incompatibilities, you can remove individual .dll files and keep the others. The only one that's strictly required is the StockBugFixPlusController.dll, other wise the other modules will not work properly.

3) No, there's no attempts here to deal with stutter.

4) If you are using 1.1.3, you only need to download the most recent patch. If you are using an earlier version of KSP, then download the most recent patch that matches the version. (For example, 1.1.2Fb.1 for KSP v1.1.2).

 

Quote

BTW... on a side note, it must have been annoying having Maxwell Smart hunting you back in the 60's.... lets see how old you are now and if you know the "Get Smart" TV reference.

I wasn't around for the original, but I did enjoy that show from time to time.  I remember the bubbles they used when talking about secret stuffs, haha.

 

[Curveball Anders]

On 2016-07-09 at 9:48 PM, Claw said:

This is mostly it. I am squad staff, and pretty much all of the bug fixes are making their way into stock. However, a quick read through the release notes and you'll see that the primary development process is currently focused on 1.2. So for some of these bugs, I try to put out fixes for folk for primarily two reasons.

1. It lets people enjoy the game more, to eliminate some of the more destructive bugs while the main team focuses on the next release.
2. For some of the elusive bugs, it helps to confirm that the fix is aimed at fixing the right thing.

Anyone who's been working as a professional sysdev also knows that there's more.

3. Being able to fix (personally obvious) irritating bugs without having to run them by either managers wondering what you're spending time on or QA asking if this change is worth the testing it will require.

The concept of Staff Devs moonlighting as Mod Devs (or possibly the other way around ) is actually quite clever in so many ways.

Mod Dev Claw adds a fix in his mod:
User: Whaaaaa! That supposed fix broke my established workflow!
All: Then de-install the fix moron dude.

Staff Dev Claw commits a fix to release:
User: Whaaaa! That supposed fix broke my established workflow!
All: Tough luck.

As a devoted user I love the concept, and every time I suspect that something wonky actually isn't my own fault, but an actual bug in the game, I check this thread, and if I'm lucky, updates my fixes

 

[Tyko]

@Claw you're just awesome! just last week I was running into EVA light failures and undocking not working. This week you come out with a solution!!

Wish you had a Paypal link...I'd send you coffee money 

[Glaran K'erman]

Force undock FTW, thanks @Claw

[New Horizons]

This GUI appears after every scene change. This is annoying. How can I deactivate it?

[Claw]

1 hour ago, New Horizons said:

How can I deactivate it?

Cycle the StockPlus option on, then back off. That should pop up the save button. Once you save, it won't come up anymore.

[JohnWittle]

Hey, so, I had the "EVA'd Kerbals Stuck on Ladders, Basically All Parts Orphaned, Lots of Problems, etc., After Fairing/EngineShroud Decouple" bug, and was extremely thankful to see that these bug fixes claimed to fix it. So I loaded it up and off I went. And it didn't fix anything at all. All of my parts are still orphaned (empty context menus), when I tried to reboard my log claimed to be "Switching to Vessel: Jebediah Kerman" (with the exemplary warning "Warning: Jebediah Kerman has crew but no interior model!" lol).

I'm using Procedural Fairings. I guess I had assumed that the bugfix fixed whatever ShieldedParts bug was going on... but now I'm guessing that actually it just fixed the problem on the actual fairing part end of things? And because I'm not using stock fairings, I still have the bug?

[Claw]

12 hours ago, JohnWittle said:

And because I'm not using stock fairings, I still have the bug?

I don't want to be dismissive and say "Yeah, it's because you're using add-ons." But that's likely the case, since my addon specifically targets stock components. So if an add-on is doing it's own thing, I tend to not aim fixes at other people's works. In the case of this "stuck kerbal" and "stuck docking ports" issue, there are some bits that need to be added to the code that handles the fairings. I would imagine ProcFairings are using their own modules, which this particular addon isn't going to be looking for.

 

And the " Warning: Jebediah Kerman has crew but no interior model" is actually harmless, and isn't part of the issue of stuck kerbals. 

[JohnWittle]

Oh, no offense taken. I know the bug has something to do with the ShieldedPart functionality, which is why it only happens with fairings and engine shrouds. I had assumed your bugfix tampered with the function which causes the parts to become shielded and unshielded, in which case any fairing mod would slso be fixed. I thought that would be easier on the code, since I assume there's only one 'shielded part' function but many stock parts which *create* a shield. My inquiry was as to whether this was the case, or if instead your bugfix actually tampered with the actual shielding parts themselves (stock fairings, shrouds), etc.

 

Do you think you could explain the nature of the bug to me? There are about a billion threads about it in both the Modded and Unmodded Tech Support forums and nobody is really sure of the actual technical details.

[Beetlecat]

On the subject of parts and fixes: Hardpoints:

I tried to do some quick searching about stageable hardpoints for aircraft drop tanks, etc. but nothing appears by way of a fix or noting the problem. They no longer drain connected tanks first, but rather at the same rate as the rest of the craft. Is this a crossfeed issue or fuel-line behavior that they're missing now?

[Claw]

On 8/4/2016 at 8:27 AM, Beetlecat said:

They no longer drain connected tanks first, but rather at the same rate as the rest of the craft. Is this a crossfeed issue or fuel-line behavior that they're missing now?

I guess I'm not sure what you mean exactly by that. I'd have to go take a look and see. You can toggle crossfeed on them, so perhaps it's off?

[Beetlecat]

13 hours ago, Claw said:

I guess I'm not sure what you mean exactly by that. I'd have to go take a look and see. You can toggle crossfeed on them, so perhaps it's off?

It's not so much the crossfeed toggle, but rather that the stage-able pylons used to act like fuel lines, draining outer-attached tanks first. Instead, they simply draw at the same rate as all tanks on aircraft/spaceplanes.

I noticed it when looking at a set of craft from Raptor9, and this was the response:

Quote

Thanks @Beetlecat.  It does take a fair amount of time to design, test, revise, test again, polish the rims, and generate the graphics for publishing.

Regarding the drop tanks, I did some testing a little bit ago.  My X-5 and X-6 drew fuel from the drop tanks as soon as I turned the engines on, as usual without any interaction from me.  However, my X-7 did not; it drew fuel from all tanks simultaneously.  The difference is the X-5 and X-6 were craft that I built in 1.0.5, whereas the X-7 was built in 1.1.  When I was upgrading my new craft with the updated landing gear after 1.1 came out, I simply opened the 1.0.5 craft files, re-geared them, and saved them as 1.1 craft files.  I'm guessing some of that 1.0.5 behavior carried over.  Since the X-7 was a new build after the 1.1 switch...well, it doesn't behave as I originally intended.

I tried it with the drop tanks "staged", and "not staged".  Made no difference.  I can say though that pre-1.1 the pylons treated fuel tanks appropriately as drop tanks and drew fuel from them first.  Maybe that will get fixed in the next patch.   I don't think it's a major deal at this time though.

The variation between craft originally built in 1.1+ vs built pre 1.1 is a bit perplexing.

Edited August 8, 2016 by Beetlecat

[HafCoJoe]

1 hour ago, Beetlecat said:

It's not so much the crossfeed toggle, but rather that the stage-able pylons used to act like fuel lines, draining outer-attached tanks first. Instead, they simply draw at the same rate as all tanks on aircraft/spaceplanes.

I noticed it when looking at a set of craft from Raptor9, and this was the response:

The variation between craft built in 1.1+ vs built pre 1.1 is a bit perplexing.

I've had similar issues with fuel drain myself but in what sounds like an opposite way from this  I've been wanting to drain fuel evenly from a set of tanks that are attached stacked on top of each other, but no matter how I rearranged fuel lines I couldn't get the tanks to all drain at the same time without placing a panel in between them (Which greatly increases drag to the point of the craft being unusable). The addition of being able to toggle fuel transfer on fuel tanks which is coming in 1.2 is going to be very useful for this type of thing though . It was mentioned in the devnotes alongside the advanced building mode if I recall correctly.

Edited August 8, 2016 by Avera9eJoe

[Guest]

On 13/07/2016 at 10:00 PM, kiwi1960 said:

3) does it help with the stutter?

This can help with that, though it's not especially convenient or easy to configure.

 

[Space Kadet]

This dose not work, i spent 4 hours repairing my save file and got it all working again, then added this to the game, and now im constantly getting ksc lockups and building lockups and kerbals that i was using going missing

[Claw]

2 hours ago, Space Kadet said:

and now im constantly getting ksc lockups and building lockups and kerbals that i was using going missing

If you have a log file, I'll take a look and try to see what's going on.