Kerbal Space Program

I tried that persistence file as well and got the crazy torque/self destruction version of the NullReferenceException bug easily enough, but the frozen orbit version didn't trigger on all ships. I could only reproduce it using one craft (Goliath VIII-2).

Here is the backup persistence file from when I first stress-tested the frozen orbit bug, in case it's useful (I used Goliath VIII-2):
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/Persistent%201/persistent.sfs

It's strange that some ships will trigger the "frozen orbit" version of the NullReferenceException bug, but others trigger torques/disassemblies/explosions. My best guess is that to trigger the “frozen orbit” version, the ship needs to be at a specific distance and/or velocity relative to Kerbin. Could be something related to the ship design though.

I agree that there seem to be multiple methods of initiating the bug, and it may not be asteroid/claw specific. The method I outlined above is simply the first way I've been able to reliably reproduce the bug.

Here are some screenshots to walk through the exact process I used just now to replicate the bug again, using the backup persistence file linked above:

#1 – Select Goliath VIII-2 in space centre
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/Persistent%201/screenshot389.jpg

#2 – Load Goliath VIII-2
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/Persistent%201/screenshot390.jpg

#3 – First physics warp + torque + quicksave
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/Persistent%201/screenshot391.jpg

#4 – First reload
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/Persistent%201/screenshot392.jpg

#5 – Second physics warp + torque + quicksave
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/Persistent%201/screenshot393.jpg

#6 – Second reload (first appearance of NullReferenceException, though not yet freezing in orbit with nonphysical timewarp)
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/Persistent%201/screenshot394.jpg

#7 – Third physics warp + torque + quicksave
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/Persistent%201/screenshot395.jpg

#8 – Third reload (another NullReferenceException)
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/Persistent%201/screenshot396.jpg

#9 – Immediately after hitting nonphysical timewarp this time, a huge list of NullReferenceExceptions came up, and the “frozen orbit” bug was activated
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/Persistent%201/screenshot397.jpg

(Sometimes it takes a few more than 3 iterations to get there, but it always happens eventually.)

Aha! Finally managed a breakthrough.

I’ve just done some more testing with the persistence file linked above to try to narrow down the conditions triggering the bug. One new crucial thing I noticed is that the craft is never exactly “frozen” in its orbit – the altitude is changing at the same rate as if no timewarp were being used, but the velocity remains constant. Of course a constant velocity in an elliptical orbit is effectively a phantom acceleration as you change in altitude. I saw a bug report from someone else who triggered the NullReferenceException during a launch and waited long enough to be eventually flung out of Kerbin’s SOI without any throttle. On a hunch I tested what happened if I waited for a while after triggering the bug myself, and I got a craft on a collision course with Kerbin to raise its periapsis out of the ground with no throttle.

So I’d reclassify the “frozen orbit” and “phantom acceleration” bugs as different manifestations of one bug:

- Nonphysical timewarp has no effect for the craft you’re focussed on, instead you experience regular time (though all other objects will timewarp)
- Your craft’s velocity is locked at the value it had when you pressed nonphysical timewarp in the bugged state

Here are the results of my tests with the particular orbital inclination and eccentricity of Goliath VIII-2, using the persistence file and steps above. Each test begins with exiting and restarting the game to remove the bugged state.

Test #1 – altitude 5300 km, velocity 982 m/s -> “frozen” orbit (repeated 6+ times)
Test #2 – altitude 29000 km, velocity 67 m/s (apoapsis) -> catastrophic explosion (repeated twice)
Test #3 – altitude 19950 km, velocity 331 m/s -> catastrophic explosion
Test #4 – altitude 9950 km, velocity 659 m/s -> catastrophic explosion (repeated twice)
Test #5 – altitude 8950 km, velocity 710 m/s -> catastrophic explosion
Test #6 – altitude 7850 km, velocity 780 m/s -> “frozen” orbit (repeated three times)
Test #7 – altitude 6900 km, velocity 840 m/s -> “frozen” orbit
Test #8 – altitude 5500 km, velocity 960 m/s -> “frozen” orbit
Test #9 – altitude 2500 km, velocity 1430 m/s -> “frozen” orbit
Test #10 – altitude 880 km, velocity 2126 m/s -> torqueing followed by gentle disassembly or explosive disassembly, depending on the orientation of the spacecraft to the asteroid (repeated four times)

The first thing to note is that there seems to be a clear cutoff point around 8000-9000 km where the “frozen” orbit doesn’t happen, at least for this particular inclination and eccentricity. I rechecked what happened at the 9950 km altitude if I changed the orientation of the craft, thinking that maybe the catastrophic explosions were a result of the direction the craft was facing in its orbit. However, there was no such effect – I tried about 10 different orientations at ~60 degree intervals everywhere along the navball, and always got the catastrophic explosion. So it seems the altitude and/or velocity of the orbit matters in terms of whether you get the “frozen” orbit version of the NullReferenceException.

Following Test #10, I waited to see what happened in the game following the disassembly. Aside from the constant “stuck” velocity raising my periapsis out of the ground, the spacecraft actually disassembled a second time as it moved closer to Kerbin, leaving it with only a couple of structural elements and a remote guidance unit. This makes me suspect that only part of the spacecraft is locked at constant velocity, and as the discrepancies build up between the velocities different parts want to move, the ship develops an irreversible torque and/or rips itself apart.

(By the way, the length of time to trigger the NullReferenceException using the steps above is still pretty random. Occasionally it happens on the first quicksave/reload, sometimes it takes 15-20 iterations. On one occasion, the first two times I reloaded to a NullReferenceException it didn’t trigger any bugs with nonphysical timewarp, only entering the bugged state after the third NullReferenceException.)

After more testing with different spacecraft in the persistence file linked above, I have a few more notes.

#1 – The steps from http://bugs.kerbalspaceprogram.com/issues/2338 seem to trigger the same bugged game state as the steps listed above. Whether the apparent effect of the bugged game state is “frozen orbit”, “frozen launch”, “phantom acceleration”, “catastrophic explosion”, “gentle disassembly”, “phantom torque”, or a combination thereof appears dependent on the orbital parameters and current position of the spacecraft. All of the different effects can be triggered by switching to a spacecraft and hitting nonphysical timewarp after the bugged game state is initiated. The consistent factor always seems to be (1) locked velocity, and (2) nonphysical timewarp having no effect for the selected craft (or sometimes being unusable due to acceleration/gyrations).

#2 – For Goliath VIII-2, on the way up to the apoapsis the “frozen orbit” can be triggered up to 8264 km, while the “catastrophic explosion” is triggered from 8265 km upwards. I tested this several times and was surprised how consistent it was. Whether or not the craft explodes, the two consistent factors are always (1) the velocity of the craft/remote guidance unit is locked, and (2) time passes at the normal rate regardless of nonphysical timewarp.

#3 – For most other spacecraft the boundary between “frozen orbit/phantom torque” and “catastrophic explosion” seems to be at lower altitudes than for Goliath VIII-2, around 3000-6000 km.

#4 – Going into physical timewarp below about 1000 km with a craft that’s already been torn apart from its asteroid shows the “phantom torque” still in effect on the remnants of the craft.

https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/screenshot471.jpg
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/screenshot472.jpg

#5 – While in a “frozen orbit”, entering another SOI will tear apart the craft. I suspect this may be because entering another SOI changes the relative orbital velocity, but at least one part of the craft tries to maintain its locked velocity. In the screenshots below I got a craft into a region near the Mun’s orbit, then triggered the NullReferenceException and nonphysical timewarped until the Mun’s SOI was close by.

https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/screenshot476.jpg
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/screenshot477.jpg
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/screenshot478.jpg

#6 – When physical timewarping ahead with a craft in a “frozen orbit” attached to an asteroid, the asteroid-craft system soon starts oscillating. My suspicion is that this is the result of the craft trying to maintain its locked velocity, which consequently applies a force to the asteroid which is trying to move in a “normal” orbit. If these oscillations continue for a while, the craft will sometimes clip through the asteroid to an absurd extent.

https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/screenshot481.jpg
https://dl.dropboxusercontent.com/u/87213001/KSP/Frozen%20orbit/screenshot482.jpg

I just realised that talking about "locked velocity", "phantom torquing" and "phantom acceleration" is actually missing a much simpler way of thinking about the problem.

When the bug is triggered, gravity stops acting on at least one part of the spacecraft.

I think the reason I didn't come to this conclusion sooner is because the map screen still draws the projected orbit for the spacecraft based on its current velocity and altitude. But after the bug is triggered, the spacecraft (or what's left of it) isn't moving along an orbital path at all - it's moving in a straight line. This would be more noticeable if the ability to nonphysical timewarp didn't happen to be broken at the same time.

A lack of gravity on at least one part of the spacecraft would neatly explain the locked velocity, phantom torqueing, phantom acceleration, and frozen launchpad issues. Broken nonphysical timewarp explains the illusion of "frozen" orbits. The only thing I can't explain are the catastrophic explosions at high altitudes (above ~5000-10000 km) - a lack of gravity alone shouldn't cause this, so I'm guessing it has to do with something else.

Okay, so I've given your grappling the decoupled tank a go, Claw. Can't say I spotted any odd behaviour there - other than the target velocity being quite wrong.
Going to test the other notes in this issue further.

Ted: Good to know. Let me know if I can help in any way. :)

sal_vager: I was surprised you said the bug remained for you even if KSP was restarted and reloaded, as that has not been my experience. I downloaded the file you uploaded to check - as far as I could tell the bug was not present in this save. Using nonphysical timewarp worked perfectly normally for me.

I presume you used Goliath VIII-2 as I did? Are you sure you're completely exiting all instances of the game? Maybe try restarting your computer and loading up the file again?

From my experience, exiting/restarting the game always removes the bug. It has to be re-triggered to reappear, and two methods seem to be (1) quicksaving and reloading a clawed asteroid after moving it multiple times, and (2) switching between multiple clawed asteroids in the map view. (One of my crazier save files triggers the NullReferenceException almost every time with just one quicksave and reload - it's in post #3 here: http://bugs.kerbalspaceprogram.com/issues/2367). As noted above, the exact effects of the bug - "frozen" orbit/launch, catastrophic explosion/disassembly, phantom acceleration/torque - seem to depend on the location and/or velocity of the craft.

Ted wrote:

Okay, so I've given your grappling the decoupled tank a go, Claw. Can't say I spotted any odd behaviour there - other than the target velocity being quite wrong.
Going to test the other notes in this issue further.

The issue you're mentioning about incorrect target velocity on clawed objects sounds like a different bug; When the object is grappled, it stops being a separate object and is now part of the active vessel. The target's ID no longer exists (although it'll reappear when ungrappled) and the game ends up referring to the last known position of that ID. What should be happening here is the same as when docking: the current target should be cleared.

Really wish I had input on how to solve the bigger issue here though. :(

For what it's worth, I'm also seeing this in the x86_64 Linux build.

I engage nonphysical time acceleration and the ship I'm watching just stops moving. Everything else continues on in its orbit, but my focus doesn't move at all. I'm seeing this pretty consistently with vessels from large fuel tanks docked to spaceplanes down to a tiny probe with nothing but an ion drive and a couple solar panels.

I experienced this problem and was as wits end trying to figure it out. I mean, I'd been playing for months and all of a sudden this starts happening? To every ship, every time I warp?

To make a long story short, I noticed that there were 128 mechjeb ship config files in C:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\MechJeb2\Plugins\PluginData\MechJeb2. 128 being a suspicious number, I deleted them all.

Poof. Problem gone.

Hi, I had the same issue. May I have workaround. I could reproduce the bug.
I am using the MKS Mod (The colony mod to build bases on moon for example)
I built a test colony with a test vehicle near my landing platform.

After I did that I had the problem with frozen spacecrafts when I go to warp (time warp).
After I deleted some debris in Space and deleting everthing near my landing platform on kerbal - I hadn't the bug anymore.

I hope this will help resolving the bug. Because this bug is really annoying.

I have some bases on moon. Not every time but very often I am switch from my base on ground to a space craft I could reproduce the bug. My Spacecraft explode or freeze after I use the time warp.

I have had the misfortune of this bug affecting my 1.0 save.

However, I happened to have made tens of dated quicksaves that may help investigations.

Mods include station parts expansion (http://forum.kerbalspaceprogram.com/threads/91814-1-02-Stockalike-Station-Parts-Expansion-%2804-05-2015-CTT-and-minor-fixes%29), RPM, Transfer Window Planner, and Distant Object Enhancement, although you should only need the first to load these saves. I think it was at (5-7 20+55 3 kerbals returning) that the bug repeatedly happened, although restarting the game seemed to fix that.

The zip file containing the quicksaves is here: https://dl.dropboxusercontent.com/u/55136631/GhostKrakenBugSaves.zip

I am experiencing this (or a very similar issue) in an unmodded 1.0 (steam) installation.
It mostly happens in career mode (which is a new game with default difficulty settings - so it doesn't seem to be an upgrade artifact) and seems to be related to being close to Kerbin (~10-200KM) and/or (and more likely) to be related to not having access to maneuver nodes and/or to direction selector (due to low pilot level/command module tech/upgrade level).
I don't need claw in the craft to reproduce it (but may be related to having activated the asteroid redirect scenario earlier), essentially, with those conditions, with some crafts, whenever I activate wrap, I get a can't wrap during acceleration message (even though no acceleration is active), and then see the constant orbit constant speed effect, usually ending with some parts of the craft going missing after some time.
Given the simple scenario, and since this is probably the configuration for most new career games, it probably deserves new attention.

I'm seeing the same behavior in Steam 1.0.4 install, mods on or off. 3 Different ships. All instantly explode during time warp, although with KJR installed, they don't explode, but they do remain entirely static and uncontrollable.

I'm new to KSP and bugtracking. let me know what I can post to help.

Hi, I have the same issue now with a other modul. If I use the extraplanetary launchpad. The launchpad for ground is causing this issue. The vessels explode by warping or freezing.

After the vessel explodes, you can see that every part has a different speed. some parts are escaping the planet or moon, some others flying on different places on the planet