I believe I've found the fix a large number of the 'loss of player control' bugs...
Short answer:
Enter 'enableplayercontrols 1 1 1 1 1 1 1 1 1 1' into the console.
Short answer:
I've made an Imgur album explaining the cause and fix for this issue: http://imgur.com/a/770N4
Here's a short textual summary of the fix:
-
During normal gameplay (not in VATS, a terminal, a conversation, a menu, etc.) , open the console and run the command 'DumpInputEnableLayers'
-
If you see a Layer there, note it's number. Not the hexadecimal one, the normal integer one -- such as '0'.
-
Run the command 'ResetInputEnableLayer [#]' to remove the restrictions that layer had.
Long answer:
The 'loss of VATS' version of this issue is caused by the failure of a vault door opening animation to play. Most people report this happening with Vault 114, but there have been other vaults mentioned by people with this issue.
Here's what the game should do when working normally:
1. Disable VATS
2. Play several related door opening animations
3. Re-enable VATS
But, for some unknown reason, the script that handles those actions crashes on the animation steps, and never executes the 'Re-enable VATS' step. This then leaves you without VATS, presumably for the remainder of the game.. (Although, I bet if you were able to successfully open a later Vault, you may get VATS back when the same script successfully completes.)
I believe the other sorts of loss-of-player-control issues are similar situations where a script disables a particular aspect of player control, and never re-enables it.
And, in case you are particularly curious, here are what all those '1's mean, per the help text of the 'enableplayercontrols' command:
[movement|fighting|pov|looking|sneaking|menu|activate|journal|vats|favorites]
Edit: I've gotten reports that there is also a 'forceenableplayercontrols' that takes the same 10 '1's. Please try that command if the normal 'enableplayercontrols' command does not work.
Edit 2: Please see the correct fix noted above.