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

[smjjames]

What chance would there be to make wheels behave a little more than wheels? E.g. provide propulsion when flipped upside down as well? Currently only the bottom area provides propulsive force - it would be nice if the top surface could pull in the opposite direction.

(and if front of the wheel pulled upwards, and back downwards, that would be totally sweet!)

The wheels are being completely redesigned in Unity 5, read the devnotes from yesterday and last week.

[Claw]

E.g. provide propulsion when flipped upside down as well?

I have no idea how easy or hard this one might be. The stock wheels appear to use mostly Unity functions for wheels, but it looks like there's also some in-house work for those too. I don't know if Unity only assumes one direction for wheels or not. And yes, as was stated above, wheels sound like they're a lot of work for converting in U5. Hopefully they'll work better than currently.

TLDR (ignore if this has been mentioned already). "Sticky Launchpad Fix - It's possible this fix isn't needed anymore, but not yet confirmed". I can confirm that as of v1.0.4 the sticky launchpad problems in the stock game still exist.

I thought I fixed that forever ago, but apparently not. Yeah, someone did mention it before...but thanks for pointing it out because it seems I forgot to update it. It's fixed now, thanks!

Cheers,

~Claw

- - - Updated - - -

Here is the problem I'm talking about. Notice how the control surfaces on the wing are moving in opposite directions when you pitch up or down.

This has to do with how KSP figures out where the part's location is relative to the CoM. It's more pronounced on swept wings because they swing further back behind the CoM. What's actually strange to me is that I usually see that all the surfaces on the wing swing the wrong way. But in your pictures, the inner and middle are swinging in opposite directions.

I'll try to have a look and see if I can get a better idea of what's causing it. The problem here is that if I put an "invert" button on there, it'll end up flipping ALL controls, and not just pitch. I can't flip each axis independently without rewriting the whole Control Surface module, and that starts to cause problems with uninstalling the mod.

Cheers,

~Claw

[BudgetHedgehog]

This has to do with how KSP figures out where the part's location is relative to the CoM. It's more pronounced on swept wings because they swing further back behind the CoM. What's actually strange to me is that I usually see that all the surfaces on the wing swing the wrong way. But in your pictures, the inner and middle are swinging in opposite directions.

I could be wrong, but I thought KSP used the orientation of the attached part to figure out its position relative to the CoM, as well as its absolute position.

See below - the inner surfaces are attached behind the CoM and the attachment surface is aligned behind the CoM. The outer surfaces are also attached behind the CoM, but their alignment draws a straight line in front of the CoM, confusing KSP.

You probably see all flaps deflecting wrong because all are attached at the same angle.

Also, as I mentioned beforehand, those control surfaces should NOT be used for pitch like, at all. Only flaps/spoilers and possibly roll. Pitch should only be controlled with the elevators on the tail (in this case).

[_Rade]

Thanks for the reply.

I think the KSP draws a line that is perpendicular to the control surface and if that line falls behind the COM the control surface will move in one direction and if it's ahead of COM it will move in the opposite direction.

Issue with the large wings is that the control surfaces you can attach to in can be both straight and swept, because of that you can get a wing with control surfaces that are both behind and ahead of COM.

[NeverEnoughFuel!!]

Elevon fix doesn't work... they work as they should if a wing is at the same position as a tail... i.e. faaar behind the COM... this is my first post and I was compelled to register after I saw some posts of "experts" on aerodynamics on the net, who post a photo of a plane who is OBVIOUSLY landing (flaps down, elevons down, EVERYTHING down... desperately braking ;-))... and claim that it takes off... my childhood dream was to be fighter pilot (as many of us here I suppose ;-) )... and I know how elevons suppose to work... this is a BIG BUG... and I think even I'm not a programmer (i know something here and there about programming) that some wings have a tail class or rotational matrices of a tail... just a suggestion...

[luizopiloto]

Is there a fix for that bug where wings collide with Launchpad or Vab when coming from orbit and landing on runway?

[Claw]

I would agree that there is a bit of an issue with how KSP is flipping the direction of the control surface. However, I'd also like to point out that actual elevons aren't placed so close to the CoM/CoL, because at that position they don't provide much leverage. So they would act more like flaps and less like elevators.

Elevons need to be back away from the aircraft's CoM, or it pushes the Center of Rotation out in front of the craft. Actually, even the shuttle suffered from a Center of Rotation that was out in front of the nose. This results when the elevon deflects trailing edge upward (when pitching up), and creates a loss of lift for the main wing (causing the craft to momentarily drop).

My point being that Elevons are a little more complex than just "somewhere on the plane."

Edit: Also, I meant to include a thanks for clarifying for me a bit more what the problem is. I thought it worked a little different than the picture above. Thanks!

Cheers,

~Claw

Edited July 11, 2015 by Claw

[Claw]

Is there a fix for that bug where wings collide with Launchpad or Vab when coming from orbit and landing on runway?

No, I don't have a fix for that. I know exactly what you are talking about, but the specific cause for that bug hasn't been determined yet. If I could get some good replication steps, I might be able to figure it out. But without having a consistent way to trigger it, it's difficult to track down and fix.

Cheers,

~Claw

[kingoftheinternet]

Installing Stock Plus brings my memory usage after loading the KSC from ~3300MB to ~3000MB. This is delightful, of course (means I can make several more scene transitions before I have to restart the game), but do you have any insight into why that might be?

[Claw]

Installing Stock Plus brings my memory usage after loading the KSC from ~3300MB to ~3000MB. This is delightful, of course (means I can make several more scene transitions before I have to restart the game), but do you have any insight into why that might be?

Hmm. I don't know off hand why that would be, but it's definitely an interesting observation. I will try to do some investigation as to why this might be. Is it just StockPlus? Or does having the Bug Fixes with StockPlus disabled do the same?

Thanks!

~Claw

[Skalou]

hi dear Claw,

1st thank you for your patch, it is really usefull.

Maybe i have an idea for your mod:

I see sometime the service bays dancing la Brujita when loading the vessel, i think it 's when we put too big stuff inside colliding the small service bay (like a small white tank of monopropelant, or covered solar pannel in a small bay).

the main problem is this wobble can lead to a dissably of the ship.

however, if we toggle twice the doors it seems to recalculate something and fix the problem,

so maybe a modlet doing this when loading the vessel?

[kingoftheinternet]

Hmm. I don't know off hand why that would be, but it's definitely an interesting observation. I will try to do some investigation as to why this might be. Is it just StockPlus? Or does having the Bug Fixes with StockPlus disabled do the same?

Thanks!

~Claw

Ah, good call, it's Stock Bug Fix that causes the memory decrease; Stock Plus actually does nothing to memory use on its own.

[ABZB]

There seems to be a stock bug that is causing part temperatures to become 'infinity' in certain scenarios (mostly during high RAM use do to many mods). Would it be possible to construct a fix module that watches for that and resets those temps to something sane?

[smjjames]

There seems to be a stock bug that is causing part temperatures to become 'infinity' in certain scenarios (mostly during high RAM use do to many mods). Would it be possible to construct a fix module that watches for that and resets those temps to something sane?

It actually happens with mods too, it happens a lot for me around Tylo (for some odd reason) with DMagic orbital science and SCANsat parts, it's the same bug that I've seen mentioned around and what ABZB is talking about.

[Gryphon]

It actually happens with mods too, it happens a lot for me around Tylo (for some odd reason) with DMagic orbital science and SCANsat parts, it's the same bug that I've seen mentioned around and what ABZB is talking about.

It seems that various mods expose it, but it appears to be occurring in stock heating.

Interestingly, before the new stock heating system was added, Deadly Reentry encountered a similar issue with some mod parts. IIRC, Starwaster had a workaround of raising the thermal mass of affected parts.

[kcs123]

Heating bug is more noticable if you use FAR. Although it is most probably stock game bug with usage of some mods it becomes visible much sooner.

Nansuchao found workaround for this that involves savegame file editing. He described how to do it in FAR thread.

There should be much better solution by preventing faulty info to be saved in savegame file in the first place. I hope that his info will help to narrow down problem further.

[Claw]

hi dear Claw,

1st thank you for your patch, it is really usefull.

Maybe i have an idea for your mod:

I see sometime the service bays dancing la Brujita when loading the vessel

You are very welcome!

That might be something I can work out. I know what you are talking about, though I haven't poked around into that particular bug.

Ah, good call, it's Stock Bug Fix that causes the memory decrease; Stock Plus actually does nothing to memory use on its own.

Good info. I'm not sure if I'll be able to tell anything, but I can give it a try.

Heating bug ...

Nansuchao found workaround for this that involves savegame file editing. He described how to do it in FAR thread.

Thanks, that might indeed be helpful. I'll see if I can poke around in there soon-ish.

Cheers!

-Claw

[smjjames]

This is wierd, something seems to have broke the KerbalDebris fix and theres also these phantom screwdrivers. I think it may have something to do with KIS/KAS, I dunno.

I noticed a case of phantom screwdriver yesterday, but I didn't see any kerbals stuck in T pose.

It happened while I was cycling around just go get to the kerbal that is right freaking next to me.

Output log: http://sta.sh/05id5oao029

[Claw]

This is wierd, something seems to have broke the KerbalDebris fix and theres also these phantom screwdrivers.

Huh. Thanks for the log file. I don't see what's obviously wrong, but I do see some unusual things. Hopefully I can figure it out.

Was that kerbal involved in a crash? Or did he just suddenly end up that way?

Cheers,

~Claw

[smjjames]

Huh. Thanks for the log file. I don't see what's obviously wrong, but I do see some unusual things. Hopefully I can figure it out.

Was that kerbal involved in a crash? Or did he just suddenly end up that way?

Cheers,

~Claw

Nope, wasn't in a crash. He might have bumped into something or maybe I switched vessels while he was ragdolling slightly, honestly no idea.

Out of curiosity, what unusual things are you seeing in there?

[Claw]

This:

[Part]: PartModule ModuleKerbalDebrisFix at kerbalEVAfemale, index 9: index exceeds module count as defined in cfg.
Looking for ModuleKerbalDebrisFix in other indices...

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

...no ModuleKerbalDebrisFix module found on part definition. Skipping...

But I see you have other EVA plugins in there. So I don't know if something is interacting badly or what. I'll have a poke around my code to see if I can find out, but this error makes me think the Fixer module was somehow deleted and can't find itself. Though I don't think this particular error is directly attributed to what you're seeing.

Cheers,

~Claw

Edited July 17, 2015 by Claw

[smjjames]

This:

[Part]: PartModule ModuleKerbalDebrisFix at kerbalEVAfemale, index 9: index exceeds module count as defined in cfg.
Looking for ModuleKerbalDebrisFix in other indices...

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

...no ModuleKerbalDebrisFix module found on part definition. Skipping...

But I see you have other EVA plugins in there. So I don't know if something is interacting badly or what. I'll have a poke around my code to see if I can find out, but this error makes me think the Fixer module was somehow deleted and can't find itself. Though I don't think this particular error is directly attributed to what you're seeing.

Cheers,

~Claw

The only other EVA plugin (besides the KIS+KAS functions) that I have is the EVAManager.dll from TweakableEverything. However, I haven't noticed this happening before until now. Then again, I didn't start messing around with KIS+KAS more until recently, so it could be something that has been lurking for a while.

I also noticed that with the female kerbal, if you're swimming underwater for whatever reason and you bump against something, you'll go ragdoll and sink to the bottom of whatever body of water you're in, then get back up and swim more. Didn't test with male kerbals though. The kerbal that glitched out though in the screenshot is Bill.

Edit: Oh yeah, MKS does add an option in the right click menu to scrap or salvage parts while on EVA, but I'm pretty sure it doesn't touch the EVA itself.

Edited July 17, 2015 by smjjames

[HafCoJoe]

Sorry to be nosy but I had a question regarding memory and lag of your plugins. I've been using both iterations of your mods and I'mcurious what all they do in terms of system tax. Do Stock Plus or Stock Bug Fixes have any considerable effect on lag or memory cap on loading with stock KSP? I'm trying to categorize my mods in terms of lag and I want to see how this fits in. See ya around!

[Claw]

I've been using both iterations of your mods and I'mcurious what all they do in terms of system tax. Do Stock Plus or Stock Bug Fixes have any considerable effect on lag or memory cap on loading with stock KSP? I'm trying to categorize my mods in terms of lag and I want to see how this fits in.

Well, I haven't done any hard testing in regard to these. As far as memory consumption, they shouldn't really eat up too much. I'm not really shuffling around any memory or grabbing any memory for textures, parts, etc. So should just be code space, which is pretty small for most of them. SymmetryActionFix might be the longest plugin of the bunch. The rest are smaller modules.

As for lag, it'll likely vary a little based on the module. Something like SymmetryActionFix will induce a small amount of lag when connecting a part if the part trees are large or are using excessive amounts of symmetry (by excessive I mean 64x, which is possible).

Most of the "in-flight" modules use very little CPU overhead because they tie into the Stock modules and make some minor changes (so not a lot of cycles spent running code). There are a few modules that I had to increase the overhead on in order to maintain compatibility with other mods (ModuleControlSurfaceFix comes to mind). But other than that, I generally try to make efforts to keep the modules lean. If they have to run "slow" procedures, I try to limit the number of times they need to run, or try to run them at already slow times (like scene transitions, coming off rails, etc.).

Not sure if that helps you out or not.

Cheers,

~Claw

[HafCoJoe]

Well, I haven't done any hard testing in regard to these. As far as memory consumption, they shouldn't really eat up too much. I'm not really shuffling around any memory or grabbing any memory for textures, parts, etc. So should just be code space, which is pretty small for most of them. SymmetryActionFix might be the longest plugin of the bunch. The rest are smaller modules.

As for lag, it'll likely vary a little based on the module. Something like SymmetryActionFix will induce a small amount of lag when connecting a part if the part trees are large or are using excessive amounts of symmetry (by excessive I mean 64x, which is possible).

Most of the "in-flight" modules use very little CPU overhead because they tie into the Stock modules and make some minor changes (so not a lot of cycles spent running code). There are a few modules that I had to increase the overhead on in order to maintain compatibility with other mods (ModuleControlSurfaceFix comes to mind). But other than that, I generally try to make efforts to keep the modules lean. If they have to run "slow" procedures, I try to limit the number of times they need to run, or try to run them at already slow times (like scene transitions, coming off rails, etc.).

Not sure if that helps you out or not.

Cheers,

~Claw

Thanks! It does help