[v1.0.4] Gamebreaking Gimbal Bug with Video

[OddFunction]

-------------------------------------------------------------------------------------

Workaround: Remove FAR Mod

-------------------------------------------------------------------------------------

When leaving Kerbins sphere of influence the craft will freak out, SAS + RCS will become meaningless, and engines will accelerate in random directions making the craft unusable.

Current reproduction steps:

-Make a 2 stage rocket. Stage one gets you into orbit. Stage two will transfer you to Minmus. Make sure stage 2 uses a terrier.

-Make sure you are on course with Minmus, I usually put my low orbit around 20km.

-When you get to Minmus and are about to burn retrograde in order to establish a good orbit then very soon after burning retrograde the craft will spin out of control rapidly.

This occurs with both manned and unmanned craft. I seem to have gotten to the Mun fine but I cannot do anything except fly past Minmus because of this glitch.

KSP.Log

https://mega.co.nz/#!cF0RBQBS!VG8TwTAGAzWSmBz5wG4qejKcPOP4y9st7uqe1yvVn2I

Output log

https://mega.co.nz/#!QV1HUBbJ!q7lqpAaWcaUwZcgvOyUU8h9N8yhZDjD4hOkYs-Q5YLw

I had to use Mega because pastebin has rediculous file size limits.

Linux Mint 64bit

KSP 1.0.4 64bit

New gamesave as of today

List of my mods:

http://i.imgur.com/clo63be.png

http://i.imgur.com/KuUyve7.png

http://i.imgur.com/ZZOtSBz.png

I can provide more info if needed.

- - - Updated - - -

Here is a video. I tried twice to upload it to youtube, but apparently it is 'too long' (even though its only 20 mins). So I uploaded the video to Mega. You can view it with VLC player... or really any video player made this decade.

Link to Video:

https://mega.co.nz/#!5MkxxIaI!gGtbYem6oDgBQ9ltpsNC2s1x1YLPmE0E6cS1ExNA5so

Video is MKV format coming in at 150mb

Key:

@ 18:15 I start my Minmus orbital burn

@ 18:23 you see the glitch for the first time

@ 19:13 you can see that SRS does nothing

@ 20:00 youll see a gimbal test

Gimbal Locked = No glitch

Proven @ 20:15

Gimbal Free = Glitch

Proven @ 20:30

Edited July 2, 2015 by OddFunction

[c4stor]

Hi, i can confirm this bug. Experienced it with the Terrier like you while landing on the Mun but also while slowing down final descent on Kerbin. Seems like the gimbal deflects the oppossing way as the pod-internal gyro torque while heading retrograde which spins the vessel out of control above a certain thrustlevel. Locking the gimbal helps.

KSP 1.0.4 32bit on Win7

Also using some mods, but none which alter the engines.

[Torih]

I was getting this and removing FAR seems to have stopped it. However it wasn't occurring all the time, so its hard to tell if its definitely fixed..

[OddFunction]

Hi, i can confirm this bug. Experienced it with the Terrier like you while landing on the Mun but also while slowing down final descent on Kerbin. Seems like the gimbal deflects the oppossing way as the pod-internal gyro torque while heading retrograde which spins the vessel out of control above a certain thrustlevel. Locking the gimbal helps.

KSP 1.0.4 32bit on Win7

Also using some mods, but none which alter the engines.

Are you using FAR? I'm going to test removing FAR in a bit.

EDIT: Seems to be confirmed by other people in the FAR thread.

Edited July 2, 2015 by OddFunction

[ferram4]

I think I have a possible mechanism for this.

So, we're looking at ModuleGimbal PartModules, that determine how they should react based on the vessel CoM, which is set in the FlightIntegrator (for stock) or ModularFlightIntegrator (for FAR and other mods that require it) VesselModule. The code between the two for setting CoM is identical, but the results affecting gimbaling but not control surfaces, reaction wheels, or control inputs indicates a CoM error. Further, that the error requires velocities < 750 m/s indicates that a relatively high world velocity is needed.

So, let's consider what happens if the VesselModule runs first: it calculates the CoM of the vessel, and then the PartModules come along to make use of the CoM calculated that frame; everything works as it should.

What happens if the PartModules run first? The CoM location used by the gimbal PartModules is the CoM location from the previous frame; below 750 m/s, when Krakensbane isn't active, that can be as much as 750 m/s * 0.02s per frame = 15 m away, which could be enough to cause issues on short vehicles. It should also vary with vehicle orientation, and tests in the FAR thread seem to indicate that.

Alright, so if this is the mechanism, it's an order of operations issue. Why would that happen? VesselModules and PartModules are both derived from Unity's MonoBehaviour class, which execute most of the code in the game. MonoBehaviours have each of their functions executed in the order that they were created, so if you get PartModules that exist before VesselModules, then the PartModules should run first.

If this is an issue, it should actually be reproducible in stock as well; undock a short vehicle from a station (read: create a new vessel and new VesselModule, but with old parts and PartModules) and then bring it below 750 m/s and the issue should appear. If that shows the problem, then ultimately this is just an exacerbated stock issue of relying too heavily on order of operations to get things done.

At the moment I'm not sure why ModularFlightintegrator is being added late though. It should be added in the same mechanism that FlightIntegrator is, so I'm a little stumped right now as to how to solve it. I should be able to get something together though.

[GorillaZilla]

I can confirm after watching the video, this is Exactly the problem I'm having also.... Burning retrograde, soon as speed goes under 750ish the gimbals start vectoring in exactly the wrong way. You can see this by turning off sas, and drifting around to retrograde, Firing the engine then using reversed controls to steer left to go right, up to go down ect.... And it will then steer where you want. Another thing is the speed has to be above about 200.

Also, in all my testing it never happens in stock. Quick loading back, quitting game removing FAR and doing the exact same braking manouver as before without FAR installed and the bug won't ever happen. But will definately test undocking a ship then testing in stock...

Re install FAR, come back and bug will happen every time again.

Funny thing is, if you launch the ship and don't leave it and return, or quicksave and quickload at any point, and fly all the way to where the bug would normally happen in one take. Then the bug won't happen.

But as soon as you leave and return, or quickload it enables the bug.

Something changes in the save file when you load the ship back in, and it's per ship rather than the whole save.

And it's this change that enables the bug.

Heres more detailed information in the FAR thread, tests and test results ect...

http://forum.kerbalspaceprogram.com/threads/20451-1-0-4-Ferram-Aerospace-Research-v0-15-3-1-Garabedian-6-22-15/page1043

Edited July 2, 2015 by GorillaZilla

[WeirdCulture]

FAR has nothing to do with this... i had this too and I am not using FAR

[OddFunction]

FAR has nothing to do with this... i had this too and I am not using FAR

I think what ferram was trying to say is that the problem does indeed exist in stock but using FAR will exacerbate the problem.

So, you had the same problem as us only without far? How similar was your encounter to ours? For example, does your engine start bugging out around 750m/s or another speed? If you post some information such a OS/Modlist/reproduction steps etc it would be interesting to have your case logged as well.

[ferram4]

Depending on whether Modular Flight Integrator 1.1.1 works with the current FAR, this issue should be fixed. If it doesn't that'll be fixed with the next FAR release.

[OddFunction]

Depending on whether Modular Flight Integrator 1.1.1 works with the current FAR, this issue should be fixed. If it doesn't that'll be fixed with the next FAR release.

Thanks for the update and the effort!