[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[GorillaZilla]

heres the Steps to reproduce far gimbal bug, so far 100% occurance rate.

Delete local content from steam

Delete folder from steamapps/common to ensure no possible leftovers

Reinstall Kerbal 1.0.4 from steam

Download fresh new up to date FAR zip

Copy FerramAerospaceResearch and ModularFlightIntegrator folders from FAR zip along with the included Module manager 2.6.5 into Gamedata folder

Start Kerbal Space Program from KSP.exe in root folder

Just continue for the squad info sender... For consistency.

don't change any settings just for consistency.

New Game, just default sandbox

Go to VAB Start with Mk1-2 pod stick a clampotron docking port on top

then a 2.5 meter heatshield underneath.

then decoupler

then 2.5m inline battery

then FL-R1 2.5m RCS tank

then Rockomax x200-32 fuel tank. then poodle engine on the bottom

then launch

Hack gravity and infinite fuel ect, 4x timewarp for main burn... to speed up test and get to a circular orbit of 150km

when stable 150km orbit reached with gravity unhacked, F5 quick save and turn infinite fuel off again. Turn retrograde, via SAS retrograde hold.

Then start burning Retrograde. 4x timewarp with ALT + . for physics timewarp out of atmosphere, just to speed up the test, bug happens whether timewarping or not.

Under 750ms orbit is where the bug happens, but it sometimes won't happen the first time, once accelerated retrograde to under 20ms, and bug has not happened. Load Quicksave F9

and repeat the process and bug will usually happen. Once the bug happens it will always happen from then on.

Load quicksave, then space center and exit game.

Restart game, load default save. Tracking station. Fly the gimbal/Far bug test ship again. Face and burn retrograde and repeat the experiment, at around 750ms the bug occurs again, No need for the quickload.

Its almost like the act of quicksaving and quickloading changes something either in Far, the save or the game itself that gets the bug going, as it does not usually happen on the first launch.

Quickload and return to space center and quit the game so the ship is back in testing position for next game restart

Quit Kerbal space program

Now remove The FerramAerospaceResearch and ModularFlightIntegrator folders from GAMEDATA. Leaving Module manager and it's files intact.

Now start the game again. Load default save, Tracking station, fly Test ship. And repeat experiment.

Now after Removal of the FAR folders the bug will never happen again.

Now I'm continuing to test to see if deleting the save and starting new makes the bug not happen like the first time before quickload, See if I can figure out where the change is that then makes that install of KSP have gimbals that are allergic to FAR.....

Edited July 1, 2015 by GorillaZilla

[ExEvolution]

You know, I had a ship act weird with gimbaling too, it started happening after I switched the direction of my orbit

By switching the direction, I mean I went up to apoapsis, then fired retrograde until I came back along my orbit in the direction I had just come from. I had to lock gimbaling on the engine to prevent the ship from spinning out of control after that. The engine was firing in a different direction than the ship's heading

[GorillaZilla]

You know, I had a ship act weird with gimbaling too, it started happening after I switched the direction of my orbit

By switching the direction, I mean I went up to apoapsis, then fired retrograde until I came back along my orbit in the direction I had just come from. I had to lock gimbaling on the engine to prevent the ship from spinning out of control after that. The engine was firing in a different direction than the ship's heading

Might be related. The bug seems to happen in the orbital speed range between Over 200ms and under 750ms atleast when doing the test in kerbin orbit at 150K

If you reversed your orbit, You would have slowed yourself down into the speed range where the bug happens for your particular orbit at the time.

Take it you are using KSP 1.0.4 and Newest FAR?

[ExEvolution]

Correct

Although the version number is correct, and even after multiple reinstalls it is correct, it still says 0.15.3.1 "Froude" instead of 0.15.3.1 "Garabedian" in the subtitle of the FAR window.

I hope that's just an oversight in the current version, because I've manually redownloaded the archive and completely deleted the FAR directory, and ModularFlightIntegrator 4 times just to make sure

Also, not sure if this is a FAR issue, but my small stack separator is not working. When I try to launch something using the small stack separator, one of the parts attached to the separator is instantly overheating on the launch pad and exploding

Edited July 1, 2015 by ExEvolution

[BudgetHedgehog]

Although the version number is correct, and even after multiple reinstalls it is correct, it still says 0.15.3.1 "Froude" instead of 0.15.3.1 "Garabedian" in the subtitle of the FAR window.

I hope that's just an oversight in the current version, because I've manually redownloaded the archive and completely deleted the FAR directory, and ModularFlightIntegrator 4 times just to make sure

Also, not sure if this is a FAR issue, but my small stack separator is not working. When I try to launch something using the small stack separator, one of the parts attached to the separator is instantly overheating on the launch pad and exploding

1. I noticed that issue - it's fixed in the dev build

2. not a FAR issue, small parts overheat quickly (stock bug).

[GorillaZilla]

Ok I've spent a couple of hours testing this issue, more information and test results.

Turns out that the change, whatever it is, is affecting the save. And not the whole save, just on a per ship basis.

And the ships engine gimbal works fine in the presence of FAR during the certain velocity range where it would usually have the issue until the change to the ship actually happens. When the change happens, that then makes that ships engine gimbal react badly to far but the "change" only seems to occur upon leaving and returning to the ship in any way, including returning to space center then comming back to it via the tracking station as well as quick-save/load, they both do the same thing.

Also, Removing only the FerramAerospaceResearch folder alone does not stop the "changed" ship wigging out after restarting the game, returning to it and re-running the Standard test outlined earlier.

But removing only the ModularFlightIntegrator folder and leaving the FerramAerospaceResearch folder in place DOES stop the gimbal bug happening, so the issue may have a connection to the ModularFlightIntegrator folders contained functions.

Heres the notes I jotted down detailing each step and wave of testing and test results up to these conclusions in case theres anything that might give a clue to the cause of the problem to more knowledgable minds than my own.

New save and new FAR, Test Result: bug doesn't happen 1st time again but after quickload it happens every time

Same save, but new far, Test Result: bug happens 1st time

New save and same Far, Test Result: Bug does not happen 1st time but happens after quickload

Taking away ModularFlightIntegrator folder, Result: stops bug, far breaks

{{{Taking away FerramAerospaceResearch folder, Interesting Result! only breaks FAR, or atleast it's Icon is not showing up. But the bug remains in testing, So it's something to do with ModularFlightIntegrator folder perhaps? }}}

{{{ Download fresh new KSP without installing FAR or Dependencies, Run game and make save, launch test ship into 150k Orbit, QuickSave and Load then exit game THEN Add far And then restart game, switch to test ship from tracking station and run experiment again.. Test result: Bug happens first time! }}}

Conclusion: Far is not making the Change, the change, whatever it is, that causes the gimbal bug every time in the presence of far even occurs when FAR is not present, Perhaps quicksaving or quick loading causes the change and the change then gives gimbals their FAR allergy... Which then only flares up when FAR is present.

See what happens if Quicksave is deleted, Result: Bug still happens

What if another test ship is launched after the first has been quicksaved, loaded and bugged out? does it also bug out first time? Test Result: It does not bug out First time! Its per ship rather than per save!

Ok now if after first test of new craft and no bug out, what if return to space center to in order to discard changes and restore to starting position WITHOUT using quick-load, and then returned to via tracking station does it bug out ala as if it had been quickloaded? Test result: Yes it still wigs out, it had been quicksaved, but not quickloaded....

Conclusion: Quickload is not directly causing the change to the in flight craft that breaks it's gimbal at certain speeds in the presence of FAR

What if again but no quick-load OR quicksave? Test result: Gimbal works just fine from launch to test ending in one take without leaving craft and returning via quick load or tracking station , but once left to space center without saving and reloaded and test run again it wigs out under 750ms, Confirmed 2x

Conclusion: Quicksave and quickload are not alone in causing the change. Leaving the craft and reloading at all causes the change... Do not know if it is the leaving or the returning that causes the change that then causes gimbal's issue with far. But cannot test if leaving is the sole cause because would have to load back in to test theory so both conditions would be met on any test. Perhaps examining The ship in save file previous to leaving, then comparing again after leaving ship in game and looking for changes...

Granted, the apparent frequency at which we'd find ourselves dumpster-diving was a big part of why. Anyhow, as you've probably figured out at this point, we now need your help.

Edited July 1, 2015 by GorillaZilla

[ferram4]

Alright, so here's the tests you're gonna do. You're gonna test:

1. Whether this also affects control surfaces. Make sure you check against the normal deflection angle to be sure.
   
2. Whether the control input indicators in the bottom left move as they should.
   

If it doesn't affect the control input indicators then the error is somewhere in the stock gimbal code, which means that there is nothing I can do to fix it.

You're also going to post your logs the complete logs, nothing stripped out at all, as well as a complete and exhaustive modlist with versions. No CKAN, if that's involved at all, you're on your own.

[GorillaZilla]

Alright, so here's the tests you're gonna do. You're gonna test:

1. Whether this also affects control surfaces. Make sure you check against the normal deflection angle to be sure.
   
2. Whether the control input indicators in the bottom left move as they should.
   

If it doesn't affect the control input indicators then the error is somewhere in the stock gimbal code, which means that there is nothing I can do to fix it.

You're also going to post your logs the complete logs, nothing stripped out at all, as well as a complete and exhaustive modlist with versions. No CKAN, if that's involved at all, you're on your own.

Will do. Also the bug happens on fresh newly downloaded 32 bit 1.0.4 KSP with fresh new sandbox save and with only "FAR 0.15.3.1 Garabedian" installed and does not happen without FAR installed.

No CkAN, would not touch with barge pole, Much prefer manual install of Mods, making a new folder of KSP with each addition/change build 1, build 2 ect...

[JeeF]

Just to confirm I'm having the same problem as GorillaZilla on my builds.

[GorillaZilla]

Alrighty then!

Results are in...

1. Is not affecting control surfaces, Came down backwards into the atmosphere so the control surfaces would activate. Control surfaces were deflecting in the right direction as expected, Gimbal was always dead wrong opposite to the control surfaces (yes I know about the control surfaces are also going to be trying to push ships heading wrong due to going backwards but their deflection is as expected wheres the gimbal is opposite of expected) and if engine was turned on would flip the rocket out of control. Gimbal was as usual only becomming reversed when facing prograde with the back of the ship facing into the current vector. About 20 degrees from facing directly prograde is when the Gimbal becomes reversed.

And the gimbal always flips back to normal function when you turn far enough away from retrograde wheres the control surfaces remain consistant at all times.

2. Seems not, the control indicators always align with my input or the SAS trying to turn the correct way to face retrograde. The gimbal is reversing on it's own accord separate from the reaction wheels in the pod.

Heres the log.

https://dl.dropboxusercontent.com/u/85344120/KSP.log

Was as usual a fresh install of KSP 1.0.4 from steam. With only FAR's 2 folders and Module manager 2.6.5 in the gamedata folder alongside the Squad folder. Contents of the log are from First game start, New save. VAB, build test rocket. Launch rocket, Infinite fuel on then hack gravity on launchpad, throttle up engine start. achieve 150k circular orbit then disable hack gravity and infinite fuel and a couple quick saves. Then First retrograde burn to under 750ms for the first time for that ship, where the bug never happens. Then quickload and repeat the retrograde burn down to the 750ms mark where the bug now starts and always happens from that point test after test. Then impact with the Sea.

As Ferram says, this may be an issue we have discovered with the current stock gimbal code that breaks the stock gimbals when FAR is present.

Aye, wierd bug isn't it Jeef? How are you being effected by it in your game?

Also don't let anything like this get you Down Ferram, Your work on this Aerodynamics model replacement in Kerbal Space Program is amazing, and I see you everywhere in the forum generally kicking butt and making the "leaky bucket" that is KSP better a Bit at a time. I'm not very good at saying things like this, always a bit awkward. But I just want to let you know how much what you do is appreciated, And don't let anyone who makes light of your hard work, or feels a false sense of entitlement as if they have paid you to make this mod for them ect get you down either aye

This goes for all the Talented dedicated modders who work on KSP and other games also :-)

Makes sense to support those who fight to make your world better aye?

Edited July 2, 2015 by GorillaZilla

[ferram4]

Alright! So that points to something related to how the stock gimbal code works. No exceptions in the log, so nothing's terminating early to cause the issue.

Try this: Build a rocket with some engines in a conventional pusher arrangement, and some engines in a tractor arrangement (make sure it's well in front of the CoM), both to push the vehicle prograde. Also add a set of pusher and tractor engines for retrograde. See what happens, just for completeness; this will help exclude any CoM-related issues.

So part of me wonders if this is due to something being shifted to Flight Integrator that Modular Flight Integrator doesn't include. I'll investigate the code, but I have no idea at this moment.

[sumghai]

ferram4, just a heads-up that Jeef's a KSPwin64 user.

[GorillaZilla]

Alright! So that points to something related to how the stock gimbal code works. No exceptions in the log, so nothing's terminating early to cause the issue.

Try this: Build a rocket with some engines in a conventional pusher arrangement, and some engines in a tractor arrangement (make sure it's well in front of the CoM), both to push the vehicle prograde. Also add a set of pusher and tractor engines for retrograde. See what happens, just for completeness; this will help exclude any CoM-related issues.

So part of me wonders if this is due to something being shifted to Flight Integrator that Modular Flight Integrator doesn't include. I'll investigate the code, but I have no idea at this moment.

Ok interesting results for the first test, Slapped on a set of Tractors on the Standard test ship

When under 750 ms orbit after the ship has "changed"

If pointing retrograde, The Poodle on the bottom reverses and tries to turn the ship out of control away from retrograde, But the 2 MK55s remain functioning normally have almost the same thrust but higher gimbal range, and I've put their nozzles an equal distance from the center of mass as the poodle. So they overpower the misbehaving Poodle and keep the ship pointing retrograde.

Now heres the interesting bit, if you try to turn to prograde, now the Mk55s misbehave and reverse when your nose nears pointing prograde. and its the poodle that behaves and functions normally but is overpowered by the stronger thrust vectoring on the MK55s... And the ship's nose is repelled from pointing Prograde.

As for the " Also add a set of pusher and tractor engines for retrograde. See what happens, just for completeness; this will help exclude any CoM-related issues." bit does that mean you also want a ship like this tested?

Edited July 2, 2015 by GorillaZilla

[ferram4]

@sumghai: I'm aware; I was involved in the latest win64 thread in General Discussions. Thanks for the heads up anyway.

@GorillaZilla: Umm.... what?! Okay, wait, the actual orientation of the vehicle matters? Oh, that's bad. That's real bad. It's measuring something from a bad CoM, I think. If you're shooting it straight up to test, you should be able to get the results to reverse after going around the planet 180 degrees. Or nearly. Depends on where the coordinate system origin is located, I think.

Yes, please test that rocket as well.

[Torih]

Just to confirm I'm having the same problem as GorillaZilla on my builds.

Me too

[GorillaZilla]

I'm starting the test at a 150K eastwards orbit and just burning retrograde till I hit 750ms and the gimbal bug kicks in.

Rightio this is the last test for tonight, need to get up in the morning

The puller + pusher + puller + pusher Mostly cancels out all the forces as the gimbals all seem to counter each other and you almost end up crabbing a little. This view is down looking down on the Upper side of the Mk1-2 capsule, The tanks are empty and I'm using infinite fuel so I have an unchanging COM

Poor gusfred isnt happy with this gimbal problem either, Can't blame him either as the thing is shaking like it's doing the truffle Shuffle.....

Edited July 2, 2015 by GorillaZilla

[ferram4]

Alright, thanks; still no idea, but we'll see. When you get a chance, can you summarize all of it in a bulletpoint format for causing it and how things react? If I manage to find a fix I wanna have all the possible variations to test simply.

[OddFunction]

Hey ferram4,

I am also having the gimbal bug. My thread is here:

http://forum.kerbalspaceprogram.com/threads/127386-v1-0-4-Gamebreaking-Gimbal-Bug-with-Video

I included logs and a video. I won't clutter your thread further but I wanted to say if you need any help from me resolving this bug then I'd be happy to help.

Cheers.

[ExEvolution]

I'm not though and I've experienced the same gimballing issue

[NathanKell]

Mod Note: Just a note that any issues CKAN users encounter should be posted in the FAR via CKAN Thread not here, and that mods will be moving any such posts made here.

[mjn33]

I just want to add, doing a quick test on a fresh install, I was able to reproduce this issue using the following mods at the time:

• ModuleManager
  
• ModularFlightIntegrator
  
• HyperEdit
  

It required reloading a quicksave made before the retrograde burn. To me this suggests an issue with ModularFlightIntegrator since I never used FAR for that install at all, and removing ModularFlightIntegrator allowed me to load the save without the issue occurring. Can anyone also verify this?

One other thing, the fact that this issue happens at about 750m/s makes me think Krakensbane might be related in some way.

[GorillaZilla]

I can confirm that mjn33, removing the ModularFlightIntegrator stops the bug happening....

Also I don't think module manager is involved, The bug happens with just the ModularFlightIntegrator folder and the squad folder without module manager or files in GameData.

[abowl]

Someone (Squad) should find the time and/or means to give this guy some money/award. The mod is several years old. And its always super maintained it seems. If squad went out of their way to do this, or set up a small program/event/award for similar modders it will be a world first. And i think it will reflect positively on sales etc. Hows that Maxmaps? Instead of conjuring deals with the devil (curse, sony etc.) for mo money flows why not do something that really affects the community and would give positive PR? Thanks

[Wanderfound]

Someone (Squad) should find the time and/or means to give this guy some money

Never rely on a corporation to do something that you can do for yourself: https://www.paypal.com/us/cgi-bin/webscr?cmd=_flow&SESSION=lPmsxS51MVW9-J63DiEy065rWDARfuSYTSKrLCFZ3UJDBSMvVTmQVZgn3mS&dispatch=5885d80a13c0db1f8e263663d3faee8de6030e9239419d79c3f52f70a3ed57ec

[GorillaZilla]

+1 Aye, Most mods have a donate button on their opening post.

Its a great way of saying,

"Yes I like this, Make it better and keep it updated and working when kerbal updates break it!"

makes so much sense to voluntarily support those who work hard just to make the world better for you :-)

Cut out the exploitative middle men and get the money straight to the people actually WORKING hard and creating tangible wealth for our civilization....

Reminds me of this, Just for other things than music too...

http://potholesinmyblog.com/the-state-of-the-music-industry-in-comic-form/

- - - Updated - - -

Ok heres an interesting thing, If you make a Symetrical ship like this, with the center of thrust and center of mass line up perfectly....

When the bug happens the thrust vectoring Gimbals at one end counter perfectly the thrust vectoring at the other end... Equalling no net rotation force, Just disable the reaction wheel in the command pod...

When your under 750ms and over 200ms, whenever your nose aproaches either retrograde or prograde you loose all turning power and your rotation just drifts gently across the area near pro/retro grade untill it gets to the other side and you regain rotation force control as the gimbals begin to function normally again

It seems that when in the bug speed range, if you face retrograde then the gimbals behind the center of mass misbehave and reverse vectroring direction but the gimbals ahead of the COM continue to function normally, so top gimbals try to turn you left, and bottom gimbals try to turn you right and cancel each other out.

Same thing for pointing prograde, then the gimbals AHEAD of the center of mass misbehave and its now the gimbals behind the center of mass that function normally. again canceling each other out.

For a bug, this thing is really elegant and precise X-)

This isn't just any bug..... This is an M&S bug

Also, you can start this bug soon after launch. Just launch. Quicksave then load. Now when you Get over about 100ms the bug kicks in.

Kicking myself for not thinking of it as soon as I knew it was Loading the ship either from quicksave or tracking station that enabled the bug, and could do that on the launchpad even before taking off....

I noticed it only needs a min speed of 100ms for the bug to kick in while low in the atmo, like just after launch

Edited July 2, 2015 by GorillaZilla