Project

General

Profile

Feedback #5150

NullReferenceException: Phantom Acceleration, Claw Glitches, Frozen Vessels, Spontaneous Deconstruction

Added by LittleBlueGaming over 9 years ago. Updated over 8 years ago.

Status:
Closed
Severity:
Low
Assignee:
-
Category:
Physics
Target version:
-
Version:
Platform:
Any
Expansion:
Language:
English (US)
Mod Related:
No
Votes:
Arrow u r green
Arrow d r red

Description

I've found a way to reliably replicate the problems associated with the claw, phantom acceleration, frozen vessels, and spontaneous deconstruction of a vessel in flight.

This is all tied to a NullReferenceException error which can be triggered as follows:

  1. Load the attached save file.
  2. Go to the tracking station and fly the Claw Debugger 1.
  3. Turn on RCS.
  4. Turn on 4x physical warp.
  5. Alternate between A and D to get the vessel flexing relative to the asteroid.
  6. During maximum deflection, press F5. Debug log should post an error like this: '[Log]: Active Vessel is under acceleration (G = 0.829280703246545). Cannot save.'
  7. Continue to spam F5, this seems to be tied to an overload of the 'Cannot Save' error. On some attempts it's taken 20-50 of those errors, on others its taken more.
  8. Press F9 and look for the NRE error. If you've done Step 7 enough, there can be two NRE errors in a row upon quickloading.
  9. Activate 5x warp. If the error has occurred enough, NRE errors will spam the log.

This triggers the problem. From now on, activating non-physical timewarp on any vessel will cause the problem to manifest, as long as the program isn't restarted. Upon closing and restarting the program, the above steps need to be repeated. The problem manifests by causing NRE errors to spam in the log, and locking a part of the vessel in its frame of reference, and no forces will act upon it.

Vessels on the launchpad will simply freeze around the root part.

Vessels in orbit will either accelerate indefinitely, or the root part will break away from the rest of the craft and accelerate on its own. This seems to be dependent on the orientation of the craft when the bug is triggered. The part will travel in a straight line in the direction it was moving when the bug was triggered.

Vessels in orbit around Kerbol can appear to be frozen in space. If the acceleration is in line with the joints, the vessel won't break apart, but firing engines won't change the orbit.

A few things I've noticed while playing around with this bug:

  • The error isn't attached to save-files in any way. Restarting KSP, and loading either the persistent, quicksave, or a named quicksave from when the bug was triggered won't work, the bug will have to be triggered again.
  • I wasn't able to replicate the bug on the launchpad with a flexible vessel(Fuel tank with 4 large girders stacked on top, vernor engines at the top of the last girder, and spamming F5 along with alternating A/D. In this case, the save-error is different: '[Log]: Active Vessel is moving (sqrVel = 0.09146346153177). Cannot save.'. It seems only the acceleration version causes the bug to trigger.
  • I believe failed auto-saves contribute to the problem, which is why the error can be so hard to replicate. Most instances involve long playing sessions where enough of these save errors have the time to build up. Specifically causing them to happen quickly allows reliable replication in a matter of minutes.
persistent.sfs (93.1 KB) persistent.sfs Persistent LittleBlueGaming, 06/21/2015 03:38 PM
quicksave.sfs (93.1 KB) quicksave.sfs Quicksave LittleBlueGaming, 06/21/2015 03:38 PM
composite.png (371 KB) composite.png Composite image showing probe core path. LittleBlueGaming, 06/21/2015 04:04 PM
output_log(1).txt (836 KB) output_log(1).txt [email protected] LittleBlueGaming, 06/24/2015 11:53 PM
6866

Related issues

Related to Kerbal Space Program - Bug #2753: New kraken: all ships accelerate randomly and are uncontrollable when time warp is engagedClosed07/12/2014

Has duplicate Kerbal Space Program - Bug #5137: Spontaneous Acceleration and explosionDuplicate06/15/2015

History

#1 Updated by LittleBlueGaming over 9 years ago

Still reproducible in 1.0.4

#3 Updated by Squelch over 9 years ago

  • Related to Bug #2753: New kraken: all ships accelerate randomly and are uncontrollable when time warp is engaged added

#4 Updated by Starwaster over 9 years ago

Unable to repro with these instructions.

Suggestion: reproduce the error again then locate your output_log.txt file (KSP_win/KSP_Data/output_log.txt) if on Windows. If Linux or Mac then you want player.log (see here for instructions on locating it: http://forum.kerbalspaceprogram.com/threads/92230)

Attach it to this bug report

#5 Updated by LittleBlueGaming over 9 years ago

Sorry, I put the output log on the forum but forgot it here.

The replication can take some patience, the last save I tried I had to build up 200 of those cannot save errors.

Also, there won't always be two NRE errors in step 8, sometimes it's just one, but the bug still triggers.

#6 Updated by LittleBlueGaming over 9 years ago

Just tried again twice, took 400 and 650 failed saves to trip. It seems to be harder to trigger with this method than it was in 1.0.2

#7 Updated by Squelch over 9 years ago

  • Status changed from New to Not a Bug
  • % Done changed from 0 to 100

We did have a bug where the persistence of certain game variables was carried over from game load to game load, and only a restart would fix it.

Speculation:

The symptom described here look remarkably familiar. Spamming the quicksave may cause gamestate variables to fall out of sync during file I/O processes.

However, the action of spamming the save button under warp is not really a normal thing to do, and it is questionable whether this would qualify as a bug. The actual save is not being corrupted, so I will close this report as "Not A Bug"

#8 Updated by LittleBlueGaming over 9 years ago

I know the process I outlined isn't something that would normally be done, it's just a way to quickly and reliably trigger the error. I could provide steps to replicate it through normal gameplay, it would just take something like 1-2 hours of play to replicate it each time, rather than 5 minutes.

The auto-save function is constantly triggering that save error, whenever a craft is doing a burn, and players contribute whenever they quicksave during a burn.

It could be something else that's happening in the sequence, but I figured the logs and reproduction steps would be helpful.

#9 Updated by Squelch over 9 years ago

  • Tracker changed from Bug to Feedback
  • Status changed from Not a Bug to Need More Info
  • % Done changed from 100 to 0

LittleBlueGaming wrote:

I know the process I outlined isn't something that would normally be done, it's just a way to quickly and reliably trigger the error. I could provide steps to replicate it through normal gameplay, it would just take something like 1-2 hours of play to replicate it each time, rather than 5 minutes.

The auto-save function is constantly triggering that save error, whenever a craft is doing a burn, and players contribute whenever they quicksave during a burn.

It could be something else that's happening in the sequence, but I figured the logs and reproduction steps would be helpful.

Thank you for your efforts on this. They truly are appreciated. I was hesitant in closing this for the very reasons you give regarding phantom accelerations. However, the fix to how persistence is handled looks to have alleviated or even squashed this phenomenon, so a synthetic reproduction such as this may be moot. The reproduction unfortunately does not uncover the root cause as it is lays somewhere deep in Unity. All we can do is take steps to mitigate the symptoms.

I will reopen this issue as feedback and needing more info, and we can use it for reference if more reports of the other symptoms surface.

#10 Updated by Squelch over 9 years ago

  • Has duplicate Bug #5137: Spontaneous Acceleration and explosion added

#12 Updated by sal_vager about 9 years ago

  • Status changed from Need More Info to Resolved
  • Severity changed from High to Low
  • % Done changed from 0 to 100

No longer reproducible in 1.0.5, build 1028, the attempts made to fix this appear successful.

#13 Updated by TriggerAu over 8 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF