Recommended Posts

My Win-x64 KSP installation seems surprisingly stable, except for one intermittent bug which keeps cropping up when high part count ships explode. After a LOT of testing today I've been able to isolate that it only occurs when ALL of the following are installed:

Windows 64-bit version of KSP

Kerbal Alarm Clock 3.4

Alternate Resource Panel 2.7.3

Although the issue is intermittent, I can reproduce it with reasonable frequency under the conditions above. But if any ONE of these three is taken away, it never happens. i.e. I can run 64-bit KSP, with one (but not both) of your mods, and even add my other 50 or so mods back into the mix, and no matter how hard I try cannot reproduce the issue. As soon as both mods are in place, I can reproduce it within about 1 to 5 tries.

Spoiler

I recognize this is a hazardous landmine of unsupported misery, and that a lot of modders are (with good reason) simply refusing to deal with anything that bears the scent of Windows 64-bit. But I'm hoping you might nevertheless have some ideas. I'm not afraid to go hacking at the code myself, if you point me in the right direction.

Here's the craft file I've been testing with, and in case that doesn't reproduce it, here's a more complete Environment.zip which also includes my:

GameData directory, minus the Squad subtree. (Consists of just the two mods)

Just after liftoff, activate the first stage (space) to try and cause an explosion. The more destruction the better. Seems to happen more often when the noses of the released pylons crash in toward the center stack, rather than when they drift outward.

Freeze occurs pretty quickly into the explosions. If it doesn't occur within a few seconds, revert to the launchpad and repeat up to 10 times. I can usually get it to happen within about 1 to 5 tries. You can also try wobbling the craft a bit just before staging.

Some other things I've tried / observed:

Spoiler

The behavior is identical under both KSP 1.0.4 and 1.0.5.1028. I've only tested on Windows (no convenient access to a Linux box).

Haven't been able to reproduce with low part count ships.

Seems just as easy to reproduce immediately after launch of KSP as it is after a long time of playing

FPS always crawls right before it happens (around 0.5 FPS if measured using GCmonitor)

Happens regardless of whether any alarms are set

Happens even when x64 version of the game is moved out of the C:\Program Files (x86) directory (thought it might be some kind of weird thunking special handling thing).

Tried updating my graphics drivers, no help

Reproduced on two different computers with different nVidia cards

Happens whether or not you launch directly from KSC or from VAB Editor

Alt+Tab behavior to/from game does not seem to affect the issue (no worse / better)

Using or not using command line arguments (-force-d3d11, -popupwindow) also seems to have no impact

VSync setting doesn't affect

Doesn't seem to matter whether the mod windows are shown/hidden.

Here are some anomalies I've noticed in my logs over the course of my testing, although after investigation I haven't tied any of them explicitly to the issue:

NullReferenceException: Object reference not set to an instance of an object
at KerbalAlarmClock.KerbalAlarmClock.UpdateDetails () [0x00000] in <filename unknown>:0
at KerbalAlarmClock.KerbalAlarmClock.RepeatingWorker () [0x00000] in <filename unknown>:0
at KSPPluginFramework.MonoBehaviourExtended.RepeatingWorkerWrapper () [0x00000] in <filename unknown>:0

NullReferenceException: Object reference not set to an instance of an object
at UIManager.Update () [0x00000] in <filename unknown>:0
at UIManager.DidAnyPointerHitUI () [0x00000] in <filename unknown>:0
at SpaceCenterCamera2.InputCamera () [0x00000] in <filename unknown>:0
at SpaceCenterCamera2.Update () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

11/27/2015 12:40:19 AM,KerbalAlarmClock,Searching for KER

I also noticed some messages about VOIDWrappers etc. Are you using generic exception handlers and dynamically wrapping KSP or Unity types (like VOID, KER)? Is it possible that due to either 64-bit or due to using 1.0.4 dll's for compile, there are typename differences resulting in them not being wrapped?

Appreciate any help you can offer.

I'd also be grateful if another intrepid Windows x64 Kerbalite out there could test this out and confirm whether they see similar behavior.

Quote

They told me this was a bad idea. That it couldn't end well. But did that ever stop Jeb? I say, Judge me not by the size of my bits, but by the fervor of my Kerboneering spirit! --Fwiffo, just before launching his "Windows x64 Mk1" toward the NullReferenceException Void

Edited December 1, 2015 by FwiffoFixed post after new forums made it look horrendous

Share this post

Link to post

Share on other sites

@TriggerAu I have a feature request: A Quarter Burn option on the Maneuver Node would be useful for longer burns using Dawn or NERV. Sometimes you just have to do the whole maneuver in two orbits, having the alarm one quarter before the node (with Margin) would be nice for these situations. (i.e. Burn 1/4 before, 1/4 after, orbit once, burn 1/4 before, 1/4 after)

Share this post

Link to post

Share on other sites

I guess my question is, is importing alarms from v2 to v3 different then importing alarms from v3.4 to v3.5?

Ok, so I updated to 3.5 and my alarms were all kept, which is great, but im still getting infinite loading screens when "jump to ship" is clicked. I can navigate to the ship just fine using the tracking station, but yea clicking that, all of a sudden, now just "crashes" the game. this started right before i switched to 3.5

Share this post

Link to post

Share on other sites

My Win-x64 KSP installation seems surprisingly stable, except for one intermittent bug which keeps cropping up when high part count ships explode. After a LOT of testing today I've been able to isolate that it only occurs when ALL of the following are installed:

Windows 64-bit version of KSP

Kerbal Alarm Clock 3.4

Alternate Resource Panel 2.7.3

Although the issue is intermittent, I can reproduce it with reasonable frequency under the conditions above. But if any ONE of these three is taken away, it never happens. i.e. I can run 64-bit KSP, with one (but not both) of your mods, and even add my other 50 or so mods back into the mix, and no matter how hard I try cannot reproduce the issue. As soon as both mods are in place, I can reproduce it within about 1 to 5 tries.

Reveal hidden contents

I recognize this is a hazardous landmine of unsupported misery, and that a lot of modders are (with good reason) simply refusing to deal with anything that bears the scent of Windows 64-bit. But I'm hoping you might nevertheless have some ideas. I'm not afraid to go hacking at the code myself, if you point me in the right direction.

Here's the craft file I've been testing with, and in case that doesn't reproduce it, here's a more complete Environment.zip which also includes my:

GameData directory, minus the Squad subtree. (Consists of just the two mods)

Just after liftoff, activate the first stage (space) to try and cause an explosion. The more destruction the better. Seems to happen more often when the noses of the released pylons crash in toward the center stack, rather than when they drift outward.

Freeze occurs pretty quickly into the explosions. If it doesn't occur within a few seconds, revert to the launchpad and repeat up to 10 times. I can usually get it to happen within about 1 to 5 tries. You can also try wobbling the craft a bit just before staging.

Some other things I've tried / observed:

Reveal hidden contents

The behavior is identical under both KSP 1.0.4 and 1.0.5.1028. I've only tested on Windows (no convenient access to a Linux box).

Haven't been able to reproduce with low part count ships.

Seems just as easy to reproduce immediately after launch of KSP as it is after a long time of playing

FPS always crawls right before it happens (around 0.5 FPS if measured using GCmonitor)

Happens regardless of whether any alarms are set

Happens even when x64 version of the game is moved out of the C:\Program Files (x86) directory (thought it might be some kind of weird thunking special handling thing).

Tried updating my graphics drivers, no help

Reproduced on two different computers with different nVidia cards

Happens whether or not you launch directly from KSC or from VAB Editor

Alt+Tab behavior to/from game does not seem to affect the issue (no worse / better)

Using or not using command line arguments (-force-d3d11, -popupwindow) also seems to have no impact

VSync setting doesn't affect

Doesn't seem to matter whether the mod windows are shown/hidden.

Here are some anomalies I've noticed in my logs over the course of my testing, although after investigation I haven't tied any of them explicitly to the issue:

NullReferenceException: Object reference not set to an instance of an object
at KerbalAlarmClock.KerbalAlarmClock.UpdateDetails () [0x00000] in <filename unknown>:0
at KerbalAlarmClock.KerbalAlarmClock.RepeatingWorker () [0x00000] in <filename unknown>:0
at KSPPluginFramework.MonoBehaviourExtended.RepeatingWorkerWrapper () [0x00000] in <filename unknown>:0

NullReferenceException: Object reference not set to an instance of an object
at UIManager.Update () [0x00000] in <filename unknown>:0
at UIManager.DidAnyPointerHitUI () [0x00000] in <filename unknown>:0
at SpaceCenterCamera2.InputCamera () [0x00000] in <filename unknown>:0
at SpaceCenterCamera2.Update () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

11/27/2015 12:40:19 AM,KerbalAlarmClock,Searching for KER

I also noticed some messages about VOIDWrappers etc. Are you using generic exception handlers and dynamically wrapping KSP or Unity types (like VOID, KER)? Is it possible that due to either 64-bit or due to using 1.0.4 dll's for compile, there are typename differences resulting in them not being wrapped?

Appreciate any help you can offer.

I'd also be grateful if another intrepid Windows x64 Kerbalite out there could test this out and confirm whether they see similar behavior.

Id like to bump this inquiry if I may. I'm experiencing the same thing both on Win64 and the 64bit client on Linux as well.