SteamVR Input Actions and ActionSets stop Skyrim from receiving input events

[artumino]

Using OpenVR 1.0.16 lets us define custom actions and action sets that can be handy for having different control schemes (menus, world, etc.).

Registering an Action Manifest currently works but stops the game from receiving input events. This is probably because once an app calls SetActionManifestPath the method PollNextEvent doesn't return any event cause they are expected to be parsed with UpdateActionState and GetActionData. We should try and wrap GetActionData calls into PollNextEvent so that Skyrim can still register those input events.

[Odie]

Using ActionSets sound really interesting.

Actually, now that we can get raw VR controller state into scaleform, I'm now looking at having to write an abstraction layer and various mapping on said data to make event handling more reasonable.

Obviously, if openvr already provides such an abstraction it would save a lot of work.

One additional wrinkle is that if we use ActionSets, I'm not sure how (as in, when, and on which thread) the event signal would be sent to scaleform. Currently, pushing controller states to scaleform looks okay. I'm assuming this is because when the game is querying the controller state, we happen to be in the right thread where input event can be pushed to scaleform without a problem.

Another way to go about this might be to have actionscript setup its own input polling loop. Then, at least in the menus, we'd be able to process action signals/events from openvr.

Lastly, I don't really know what other roadblocks we might be looking at, even just in the menus. Normally, scaleform plays a part in focus management. We've created a pathway that basically bypasses all of that. More experimentation is required. x_x

[artumino]

I'll probably have time to test this in the following days. If you want to give it a try be prepared to edit your .vrsettings file in the Steam/config folder to delete the manifest file location from SkyrimVR or your game will be broken even if you roll back OpenVR versions.

That leads to another problem: When we solve the input problems, If we start using Actions and ActionSets the users can't disable PapyrusVR or their game would stop accepting inputs (unless they remember to delete the entries from the steamvr.vrsettings file).

I'm also not sure how the workshop handles binding files made for different kinds of ActionSets (currently the only ActionSet used is the legacy one).

So yes, this needs a lot of experimentation.

[Odie]

Yikes.. It almost sounds easier to just create a separate abstraction layer. It really shouldn't be that hard... (famous last words?)

[artumino]

With the new Action system we would need two main layers.

1. The Action Handling layer which is the highest one and listens for actions through the new Input API and sends these events to every plugin, papyrus script and scaleform menu that requested them. Every mod author would be allowed to define their actionsets and we would merge everything together to generate the manifest that Steam Input expects. Switching to the proper actions sets would be left to Mod devs (for example if you register a menu with special actions you would need to change the ActionSet to your custom one on menu open and then on menu close you would have to switch it back to the Legacy/PreviouslyActive one). The default action set would be the Legacy one (that contains bindings for all the older titles that are not using the new Input API).

2. The translation layer which would take all the actions coming from the legacy action set and build the old VRControllerState_t struct to send to the game on each GetControllerState call, since SteamVR stops to respond to these calls when a SteamVR Input manifest file is declared.