Kerbal Space Program

After further testing, I've found there's an even simpler method to trigger the "phantom torque" which involves no use of nonphysical timewarp.

1. Load quicksave
2. Switch to the asteroid while still at >200 m distance (using "[" or "]" or the map view)
3. Observe immediate phantom torqueing on the asteroid craft

Note if you switch crafts at <200 m distance (after the "unpacking" message in the debug log), no phantom torque occurs. The phantom torque also doesn't occur if you wait until passing the asteroid then switch at >200 m on the other side. Nor does it occur if you go back to the space centre and switch to the asteroid while the other craft is approaching (whether using nonphysical timewarp or switching crafts at >200 m or <200 m).

So it looks like the issue is confined to approaching a clawed asteroid with a second craft within physics range. Using nonphysical timewarp or switching crafts when the separation is >200 m results in the phantom torque.

I'm curious to test what happens when two clawed asteroids are approaching each other - my suspicion is the one you're not controlling will always experience the phantom torque. When I get a chance to test it I'll report my findings.

Hmm, this bug seems harder to trace than I expected. I got two clawed asteroids within physics range of one another, tried all sorts of variations with nonphysical timewarp and switching vessels, but never managed to trigger the specific bug where the other spacecraft develops a phantom torque. I got the NullReferenceException bug frequently through all the reloading, which tore apart the vessel I was controlling a number of times, but never got a phantom torque to appear on the other craft.

Screenshot of the situation:
https://dl.dropboxusercontent.com/u/87213001/KSP/Torquing%20another%20craft/Two%20asteroids/screenshot601.jpg

Quicksave with the two asteroids in physics range:
https://dl.dropboxusercontent.com/u/87213001/KSP/Torquing%20another%20craft/Two%20asteroids/quicksave.sfs

The bug described above still occurs every time when I use the quicksave from the first post.

Okay, I just got the “torqueing another craft” bug to reliably happen with two asteroid ships. Again this seems to present with no NullReferenceException in the debug log.

Persistence file:
https://dl.dropboxusercontent.com/u/87213001/KSP/Torquing%20another%20craft/Save%202/persistent.sfs

Steps to reproduce:
1. Go to space centre
2. Load asteroid ship “Daring Dave” (in physics range of asteroid cluster “Hairy Harry”, distance ~900 m)
3. Switch from “Daring Dave” to “Hairy Harry” (using “[“ or “]” or the map view)
4. Observe phantom torqueing

Screenshot at step 1:
https://dl.dropboxusercontent.com/u/87213001/KSP/Torquing%20another%20craft/screenshot640.jpg

Debug menu at step 2:
https://dl.dropboxusercontent.com/u/87213001/KSP/Torquing%20another%20craft/screenshot645.jpg

Debug menu at step 4 (after trying to switch back a couple of times):
https://dl.dropboxusercontent.com/u/87213001/KSP/Torquing%20another%20craft/screenshot648.jpg

Note that if you load “Hairy Harry” from the space centre there is no phantom torqueing on the craft. There is also no phantom torqueing if you switch (via “[“ or “]” or the map view) to “Daring Dave” after loading “Hairy Harry”.

Note also that quicksaving and reloading to “Daring Dave” or “Hairy Harry” in this situation almost always produces a NullReferenceException on the first try (possibly due to the number of claws in physics range). Trying to switch crafts after the NullReferenceException appears usually fails and instead results in phantom forces being applied to the craft you’re controlling (see http://bugs.kerbalspaceprogram.com/issues/2349).

Output logs from repeated tests:
https://dl.dropboxusercontent.com/u/87213001/KSP/Torquing%20another%20craft/Output%2021/output_log.txt
https://dl.dropboxusercontent.com/u/87213001/KSP/Torquing%20another%20craft/Output%2022/output_log.txt

No worries, happy to help.

Did the original save file from the first post also produce the issue for you? That was just a single ship approaching a single clawed asteroid - quite a typical occurrence - hence why I originally thought the issue might be higher priority. :) (Note in the original save file the bug is also triggered for me by using "[" or "]" or the map view to switch to the other ship at >200 m.)