xbox controller not working on webview2 export latest build

I just want to update this thread with the latest from the r472 release. Unfortunately we have been waiting for some time now for the underlying WebView2 bug to be fixed. To help get us by for the time being until it is fixed, there is a new workaround in r472 for Steam games: the Gamepad plugin now includes a wrapper extension (scirra-gameinput-x64.ext.dll) to directly read gamepad input from the modern Windows GameInput API and send the inputs to JavaScript bypassing WebView2. Essentially it's our own custom C++ implementation of gamepad input to work around this issue.

For non-Steam games, you can still use the workaround described earlier in this thread: add "allow-host-input-processing": false to package.json, and also delete scirra-gameinput-x64.ext.dll from the exported files, since if it exists it will use the GameInput workaround which has some limitations (described below). This should restore gamepad input using the fully-featured browser built-in Gamepad API.

For Steam games you cannot set "allow-host-input-processing": false as it will break the Steam Overlay. Instead you can now use the GameInput workaround, which is used by default for all Windows WebView2 exports. GameInput should have good controller compatibility as it is a superset of all prior input APIs, covering XInput, DirectInput, Raw Input, HID, and WinRT APIs - for example I have successfully tested both Xbox controllers and a PS4 controller (which was not historically supported out-of-the-box on Windows). Note however the GameInput workaround currently has a couple of limitations:

• Due to a GameInput bug currently only a single gamepad is supported. Input from multiple gamepads simultaneously is not supported when using GameInput - the only active gamepad will be the last connected one.
• Haptic feedback (rumble) is not currently supported
• GameInput should work out-of-the-box on some Windows systems, but you need to install the GameInput redistributable installer to guarantee support. This can be made part of the install process for Steam.

To get the GameInput redistributable installer, download the GameInput NuGet package (click 'Download package' on the right), rename .nupkg to .zip, open the zip, and extract redist/GameInputRedist.msi. This is the file that needs to be run as part of an install process (or locally for testing purposes) to ensure GameInput support is available.

GameInput diagnostic messages are logged to the browser console, so you can check there to see the status (such as whether it loaded OK and which devices its detected, or any error messages).

Remember if you test with app ID 480 (Space war) you may need to disable Steam Input in its settings until you get your own app ID. (This is just because of the configuration of Space war and isn't really anything to do with GameInput.)

I appreciate GameInput isn't as straightforward as using the built-in support but the idea is this will provide basic support for gamepad input until the WebView2 issue is fixed, at which point we can delete all the GameInput code and just go back to using standard browser-based Gamepad API input like everything else uses, and then we won't have to worry about any of this. So hopefully this helps in the mean time.

Thanks for informing us Ashley, and for the workaround! Very odd that it only detects the single gamepad input.

The problem is actually that sometimes it detects a single physical gamepad as two gamepads, in a way that is impossible to distinguish from actually connecting two gamepads. So until they fix that, there's no way to tell apart one gamepad incorrectly appearing as two gamepads, or actually having two gamepads. Our workaround is to only support the last connected gamepad so this doesn't cause a problem.

As we're probably going to be supporting this workaround for a while, there are a couple more changes in r473 to try to make gamepad support work better in Windows WebView2 exports. There's a new 'Export for Steam' setting for the Windows WebView2 exporter. This does the following:

• Unchecked (default): sets "allow-host-input-processing": false in package.json. Gamepad input should work normally (using browser-provided gamepad input).
• Checked: sets "allow-host-input-processing": true for compatibility with the Steam Overlay, and then includes the GameInput wrapper extension to work around the WebView2 bug that stops the browser-provided gamepad input working in this mode.

The GameInput wrapper extension is also updated in r473 to support multiple gamepads as Microsoft were able to fix the GameInput bug that was preventing us supporting that. Note however as per the previous post, haptics (rumble) are still not supported with GameInput, and you must still install the GameInput redistributable installer to ensure support is available (be sure to use at least v3.2.138 as that has the fix allowing for multiple gamepads).

Nice work on this!

Would it be possible to add a gamepad scripting interface, so it works independent of what's used internally?

Mike at BrashMonkey If you have issues with the official exports, there's also Pipelab which uses Electron and supports multiple platforms. It also has a good plugin with more file and Steam features.

Mike at BrashMonkey If you have issues with the official exports, there's also Pipelab which uses Electron and supports multiple platforms. It also has a good plugin with more file and Steam features.

thanks for the heads up, I'll look into it, but I'd much rather find a solution without third party processes if possible. Hopefully with Ashley's help it can be done.