Ship is instantly destroyed and launched out of solar system (Linux 64)

[Zowlyfon]

I have seen similar issues reported before on this platform. When I go to launch a space ship, it instantly launches out into space, ripping it apart. To me it simply seems like the command pod is being teleported out of the solar system, but inspecting the logs I see otherwise.

I have tried not running it through steam and using the 64-bit versions (With and without launcher).

I have use both the latest official release and the git master.

FAR was the only installed mod, (aswell as the mod manager dll)

I am running manjaro linux 64 bit (Basically Arch linux).

[ferram4]

At this point, I'm lost on this. ViscountStyx's workaround from #31 might be helpful, but since I haven't been able to get any information on the differences in libraries between the Linux 64 versions having the issue and everyone else, I have nothing to work with. The only constant seems to be that Arch Linux is implicated somehow.

[Topperfalkon]

I had a similar experience in Linux Mint 64-bit (based off Ubuntu), it might not be just Arch Linux.

I haven't tested it recently though, and I had other mods running at the time. I might have another look at it this weekend and see if it's still happening and if I can find anything more out about the issue.

[Zowlyfon]

After looking into it some more, It seems to be that all the physics calculations might be out of proportion. I managed to make a plane which does not instantly "rocket" itself into space, by adding some supports to the bottom, however when I turned it on it destroyed itself and the pod floated down "like a feather".

Ill look into it some more.

edit: I tried compiling FAR myself using mono, same problem.

[ferram4]

After thinking on it a bit, there are only two places that I can see any serious issues cropping up:

The first is in the math itself, which would mean anything from System.Math is borked. If that's the case, replacing all instances of Math with UnityEngine's Mathf (and adding the appropriate casts to float where necessary) should result in things being fixed.

The second is that it's throwing a fit over the code used to detect and disable itself for win64; in that case, removing the code from CompatibiityChecker.cs isWin64() method should fix it. Why would that be the cause? Not sure, to be honest, but it is one of the few recent BIG changes, and so it should be checked just in case.

If neither of those are the cause, then there is a deeper error in Unity / KSP somewhere that I'll have to work around.

[Zowlyfon]

Ill have a fiddle, see if I can make it work. I have heard of floating point errors occuring on the ARM distrubution of arch with mono with system.math.

edit: removing the win64 checker does not fix it.

I just checked, arch linux seems to use a much more up to date version of mono than windows or Ubuntu. Ubuntu uses 3.2.8 whereas arch uses 3.10.0

[ghost]

I'd like to clarify that I do not have mono-runtime installed in Ubuntu x64 14.10. In steam KSP is set to opt in to include the win64 beta, and then launch arguments are: LC_ALL=C %command%_64

There are no other mods installed and ferram functions flawlessly for me.

The change that fix's / breaks the build for me are the launch arguments.

[ferram4]

Interesting. I'll have to see the exact changes that occur with LC_ALL=C %command%_64 and see what that translates to in code.

[ghost]

Let me know if you need me to test anything

[ferram4]

The search that I've done makes me think this is actually caused by something deep inside Unity / KSP itself, since I have no idea why changing locale settings would change any of what I do (that's what the LC_ALL=C is doing). I'll keep investigating, but I worry this might require workarounds just like some stock Linux installs require.

[Zowlyfon]

Does Ubuntu use the free or non-free graphics drivers by default? I am using the non-free Nvidia drivers at the latest version. Ill see if I can get it to work using wine, however I expect this to cause more problems than it solves.

[ghost]

By default it uses nouveau

[Zowlyfon]

Nice Graphics Card, I am using the proprietary driver, version 343.22.

It must be a problem with the dependencies of unity / mono. If it works on one version of linux and not the other, I cannot see it directly being a problem with unity / mono, only an incompatibility.

I may be completely wrong, but this is what my instincts tell me.

Also, this is the only mod I am having an issue with, however I have no other mods which I believe to use the maths libraries so much.

[yoos]

Another 64-bit Arch Linux user here - can confirm.

Ship teleports in KSP 64-bit using either Nvidia driver 343.22 and Intel graphics. Happens even with things as small as a single probe core, though I do have one 50-part ship that somehow survives. The 32-bit executable doesn't have this issue.

How can I run KSP with a different version of Mono? Note KSP ships with its own copy of libmono.so. I tried pointing that to my system copy of mono as well as the etc config files, but I get a bunch of "function... not found" messages.

Setting the LC_ALL=C flag does not fix it for me. Invocation:

LC_ALL=C ./KSP.x86_64

[yoos]

Relevant logs:

[LOG 16:37:50.011] ------------------- initializing flight mode... ------------------
[LOG 16:37:50.012] Target vessel index: 0  vessel count: 1
[LOG 16:37:50.013] [FLIGHT GLOBALS]: Switching To Vessel Untitled Space Craft ---------------------- 
[LOG 16:37:50.013] setting new dominant body: Kerbin
FlightGlobals.mainBody: Kerbin
[LOG 16:37:50.013] Reference Frame: Rotating
[LOG 16:37:50.034] [Untitled Space Craft]: landed - waiting for ground contact to resume physics...
[LOG 16:37:50.035] Camera Mode: AUTO
[LOG 16:37:50.046] stage manager resuming...
[LOG 16:37:51.136] all systems started
[LOG 16:37:51.159] Look rotation viewing vector is zero
[LOG 16:37:51.186] [ScenarioDestructibles]: Started. 39 objects registered
[ERR 16:37:51.187] Cannot find a Module of typename 'KerbalAlarmClockScenario'

[ERR 16:37:51.187] ScenarioModule is null.

[LOG 16:37:51.193] Look rotation viewing vector is zero
[LOG 16:37:51.193] [VesselSpawner]: No new objects this time. (Odds are 1:2)
[WRN 16:37:51.419] [CurrencyWidgetsApp]: No live widgets to Despawn!
[LOG 16:37:51.421] [PlanetariumCamera]: Focus: Untitled Space Craft
[LOG 16:37:52.438] Flight State Captured
[LOG 16:37:52.438] Saving Achievements Tree...
[LOG 16:37:52.438] Saving Achievements Tree...
[LOG 16:37:52.438] Saving Achievements Tree...
[LOG 16:37:52.440] Game State Saved as persistent
[LOG 16:37:57.972] [Untitled Space Craft]: ground contact! - error: 0.053m
[LOG 16:37:57.972] Unpacking Untitled Space Craft
[LOG 16:37:58.056] [Progress Node Reached]: AltitudeRecord
[LOG 16:37:58.160] recalculating orbit for Mark1-2Pod (Untitled Space Craft): Kerbin
rPos: [-2685099340135.16, 1852307768463.66, -5517987291.1325]   rVel: [-67127474126947, 46307687268208.2, -137949659136] |81550712522347.5|
[LOG 16:37:58.160] recalculated orbit for Mark1-2Pod (Untitled Space Craft): the Sun
rPos: [-2676452607847.22, 1841803906118.02, -5517987291.1325]   rVel: [-67128012936371.3, -137949659136, 46306906207343.7] |81550712525334.8|
[LOG 16:37:58.160] setting new dominant body: the Sun
FlightGlobals.mainBody: Kerbin
[LOG 16:37:58.160] Vessel Mark1-2Pod (Untitled Space Craft) velocity resumed. Reference body: Sun vel: [-67128012936371.3, -137949659136, 46306906207343.7]
[LOG 16:37:58.173] dT is NaN! tA: NaN, E: NaN, M: NaN, T: NaN
[LOG 16:37:58.173] getObtAtUT result is NaN! UT: NaN
[LOG 16:37:58.173] dT is NaN! tA: NaN, E: NaN, M: NaN, T: NaN
[LOG 16:37:58.173] getObtAtUT result is NaN! UT: NaN
[LOG 16:37:58.173] nearestTT is NaN! t1: NaN, t2: NaN, FEVp: NaN, SEVp: NaN
[LOG 16:37:58.174] getObtAtUT result is NaN! UT: NaN
[EXC 16:37:58.177] ArithmeticException: NAN
    System.Math.Sign (Double value)
    Orbit.solveEccentricAnomalyExtremeEcc (Double M, Double ecc, Int32 iterations)
    Orbit.getRelativePositionAtT (Double T)
    Orbit.getPositionAtT (Double T)
    Orbit.getPositionAtUT (Double UT)
    Orbit.SolveClosestApproach (.Orbit p, .Orbit s, System.Double& UT, Double dT, Double threshold, Double MinUT, Double MaxUT, Double epsilon, Int32 maxIterations, System.Int32& iterationCount)
    PatchedConics.CalculatePatch (.Orbit p, .Orbit nextPatch, Double startEpoch, .SolverParameters pars, .CelestialBody targetBody)
    PatchedConicSolver.Update ()
[LOG 16:38:00.184] Game Paused!
[LOG 16:38:02.400] [FlightDriver]: Flight State Reverted to Prelaunch.
[LOG 16:38:02.401] Game State Saved as persistent

Check out that altitude record. :)

[Zowlyfon]

32bit version is the same as the 64bit for me.

logs from 32bit:

[LOG 01:04:00.273] ------------------- initializing flight mode... ------------------
[LOG 01:04:00.276] Loading ship from file: /home/zowlyfon/SSDGames/Kerbal Space Program Test/KSP_Data/../saves/default/Ships/VAB/Auto-Saved Ship.craft
[WRN 01:04:00.295] [Part]: PartModule FARBasicDragModel at mk1pod, index 7: index exceeds module count as defined in cfg.
Looking for FARBasicDragModel in other indices...
[ERR 01:04:00.295] ...no FARBasicDragModel module found on part definition. Skipping...

[WRN 01:04:00.304] [Part]: PartModule FARBasicDragModel at solidBooster, index 3: index exceeds module count as defined in cfg.
Looking for FARBasicDragModel in other indices...
[ERR 01:04:00.304] ...no FARBasicDragModel module found on part definition. Skipping...

[LOG 01:04:00.312] Untitled Space Craft loaded!
[LOG 01:04:03.233] putting ship to ground: 6.769351
[LOG 01:04:03.236] [Untitled Space Craft]: Ready to Launch - waiting to start physics...
[LOG 01:04:03.242] Crewmember Jebediah Kerman assigned to Command Pod Mk1, seat # 0 (crew seat index: 0)
[LOG 01:04:03.242] [FLIGHT GLOBALS]: Switching To Vessel Untitled Space Craft ---------------------- 
[LOG 01:04:03.243] setting new dominant body: Kerbin
FlightGlobals.mainBody: Kerbin
[LOG 01:04:03.245] Reference Frame: Rotating
[LOG 01:04:03.259] stage manager resuming...
[LOG 01:04:03.260] Vessel assembly complete!
[LOG 01:04:03.260] stage manager starting...
[LOG 01:04:03.260] all systems started
[LOG 01:04:03.364] [ScenarioDestructibles]: Started. 39 objects registered
[LOG 01:04:08.465] [VesselSpawner]: No new objects this time. (Odds are 1:2)
[LOG 01:04:08.559] [Progress Node Reached]: AltitudeRecord
[WRN 01:04:08.653] [CurrencyWidgetsApp]: No live widgets to Despawn!
[LOG 01:04:08.655] [PlanetariumCamera]: Focus: Untitled Space Craft
[LOG 01:04:09.004] Flight State Captured
[LOG 01:04:09.004] Saving Achievements Tree...
[LOG 01:04:09.008] Game State Saved as persistent
[LOG 01:04:10.205] [Untitled Space Craft]: ground contact! - error: 0.038m
[LOG 01:04:10.205] Unpacking Untitled Space Craft
[LOG 01:04:10.260] Stagnation Pressure Coefficient Curve Initialized
[LOG 01:04:10.276] [Progress Node Reached]: Landing
[LOG 01:04:10.276] [Progress Node Reached]: Kerbin
[LOG 01:04:10.276] [Progress Node Complete]: Landing
[LOG 01:04:11.468] [00:00:01]: Structural failure on linkage between Mk16 Parachute and Command Pod Mk1.
[LOG 01:04:13.625] Untitled Space Craft Debris Unloaded
[LOG 01:04:13.626] Packing Untitled Space Craft Debris for orbit

[yoos]

Oops, yeah it happens in 32-bit KSP for me, as well, though things just bounce up into the air really fast rather than teleporting to extrasolar space.

[ferram4]

And unfortunately, neither of those logs show anything distinctly wrong. I know from experience that the complaints about NaNs are likely a symptom of the issue, not the cause, so that's a dead-end.

@yoos: The 50-part ship that miraculously survives, what's different about it?

[yoos]

I can't say for sure. I created some test vehicles:

This is the krakenproof ship which I whittled down to this minimal working example that works on the airstrip. As soon as I get rid of either the nosecone or tail it explodes. It can be initialized in any orientation without falling victim to this bug.

Both this little guy and this thing initialize fine on the launchpad. However, retracting the gears, throttling up, or separating stages makes these explode. The gears on these ships cause them to initialize a small distance away from the launchpad instead of being in contact.

Finally, the kicker: I started using support towers to see if I could force ships to drop from a height, and it seemed to work until I realized this whole bug had actually just gone away. I could launch anything anywhere without things exploding. Bug came back after restart. Logfile saved for later perusal.

[Zowlyfon]

I have ships bounce into air really fast in 64bit sometimes, for me it usualy depends on the ship design. It would be interesting to see if this bug persists through to the next version of KSP.

[ferram4]

@yoos: Try building another version of your minimum-working example, but using different parts. I suspect that the issue may be related to how FAR handles open stack nodes for blunt drag; if the bug does not occur with all of those closed, but does occur with any open, then I have something I can investigate.

Also, please upload any of your confirmed crafts that don't run into the bug for everyone else here to test, just so we have completely identical test cases running around.

If that's the source, I'm not exactly sure how I'll address it, but it gives me something in my code that can be tweaked and fought with, so I guess that's good.

[yoos]

@ferram4 I think you're right about the open stack nodes. I can reliably reproduce the bug by leaving nodes open during build. Stage separation in an otherwise closed ship also invokes the bug.

I'll leave these five SPH ships on my Dropbox until this issue is closed.

[ferram4]

Awesome, we have reproduction steps! \o/

@yoos: A second idea: go into the FAR Debug Menu (Space Center Scene, the FAR button on the toolbar) and see if switching from spline interpolation of values to the exact formulas still causes the issue; that will help point out where the issue is exactly in that block.

@Zowlyfon, @Topperfalkon, @ViscountStyx, can you guys try reproducing the issue / proving the issue still occurs with no open stack nodes? Also, please look into the other thing I suggested to yoos as well. I want to make sure there is just one issue here, and not multiple issues with the same resulting behavior.

[yoos]

@ferram4 Spot-on! Switching to exact formulas keeps the bug away.

[ferram4]

Alright, I went over the code related to those particular splines, re-derived all the math, and made sure that the curves were as defined as possible. See if it breaks this time.

[willrandship]

Experiencing the same issue, Arch 64-bit, although both the 32-bit and 64-bit executable readily trigger the bug. With the 0.14.4 release, it goes nuts in various ways as described above.

Good news! Your patch fixed the bug. I pulled the GameData from the repo and plugged it in, and now my launches end catastrophically in a far more predictable way.

[kingand]

Bad news: I've been playing on Career with difficulty set to Hard so Kerbal's don't respawn, and I lost Bill to this bug. :(

Good news: the bug is squashed with the latest code. I simply replaced /GameData/FerramAerospaceResearch/Plugins/FerramAerospaceResearch.dll in my installation with the DLL file at repository revision c728931 (latest as of Dec. 8, 2014). Link to DLL file: https://github.com/ferram4/Ferram-Aerospace-Research/blob/master/GameData/FerramAerospaceResearch/Plugins/FerramAerospaceResearch.dll

[ferram4]

Well, in that case I'm going to close this, since everything seems to work now. I'll reopen if anyone trying the latest fix still has issues.