Steamworks.NET
Steamworks.NET copied to clipboard
rlabrecque
Steam hijacking controller input
I'm encountering an issue where initializing Steamworks in Unity causes my Xbox One controller to become unresponsive within the editor. No input data from the controller is registered until I close Steam. However, when building the game and launching it through Steam, I'm able to resolve the issue by accessing the Steam overlay, navigating to controller configurations, and selecting the generic gamepad profile. Once applied, the controller functions as expected.
Is this behavior intentional, or could there be a compatibility issue between Steamworks and Unity's input system for Xbox controllers?
Same exact problem here. This is definitely BLOCKING and should be assigned and fixed asap.
Happens with Unity's New Input System.
Easy way to check the issue is running this code in an Update() callback:
for (int i = 0; i < Gamepad.current.allControls.Count; i++) {
InputControl ic = Gamepad.current.allControls[i];
if (typeof(float).IsAssignableFrom(ic.valueType)) {
float v = (float) ic.ReadValueAsObject();
if (v > 0) {
Debug.LogError(" [" + i + "]: " + ic.shortDisplayName + " = " + v);
}
}
}
Before initializing Steamworks, this code will output a line to Unity console for every button or trigger pressed. After initializing Steamworks, all inputs will be 0 and nothing will be output to Unity console anymore. Only way to resume normal gamepad operation is quit&restart Unity and avoid initializing Steamworks.
Same exact problem here. This is definitely BLOCKING and should be assigned and fixed asap.
Happens with both Unity's Old and New Input System.
Easy way to check the issue is running this code in an Update() callback:
for (int i = 0; i < Gamepad.current.allControls.Count; i++) { InputControl ic = Gamepad.current.allControls[i]; if (typeof(float).IsAssignableFrom(ic.valueType)) { float v = (float) ic.ReadValueAsObject(); if (v > 0) { Debug.LogError(" [" + i + "]: " + ic.shortDisplayName + " = " + v); } } }Before initializing Steamworks, this code will output a line to Unity console for every button or trigger pressed. After initializing Steamworks, all inputs will be 0 and nothing will be output to Unity console anymore. Only way to resume normal gamepad operation is quit&restart Unity and avoid initializing Steamworks.
I've been messing around with it personally, And i dont actually think this is a steamworks.net issue. I think that engaging steam redirects input. Its just a fundamental compatibility issue with steam and unity. From my test, Actually building to steam servers and playing works just fine. Its just the quirk of testing controller inputs with steam initialized which is difficult. If anyone has a better solution, Or maybe i'm completely wrong about it being a steam issue and not a steamworks. Please let us know!
I agree this can be a Steamworks SDK issue, and not the .NET wrapper. It could also be a Unity bug (I filed a bug report with Unity too). Hope someone can tell us what's happening.
I agree this can be a Steamworks SDK issue, and not the .NET wrapper. It could also be a Unity bug (I filed a bug report with Unity too). Hope someone can tell us what's happening.
I've mostly fixed this issue. I'm not entirely sure how i did it. Try adding unity, the actual executable(not the hub) to steam and start unity through steam.
Again i do believe this to be a pretty bad bug. But at this point i have no idea how to replicate it nor do i want to.
Thanks for the feedback. I am afraid to use your workaround, as I want to be sure the game works regardless of the way the executable is started. By the way, a standalone build has the same issue, so it's not only the editor.
I double-checked the Old Input System, and it now seems to be working for me. For example, I can read the controller buttons using:
Input.GetKey(KeyCode.JoystickButton0)
It now looks more and more like a Unity bug to me. And it's so disappointing to realize that the New Input System (v1.0.0) is not being tested against one of the most obvious use cases (Steam games).
Thanks for the feedback. I am afraid to use your workaround, as I want to be sure the game works regardless of the way the executable is started. By the way, a standalone build has the same issue, so it's not only the editor.
Thats a little confusing. If your game is a steam game. You want it to launch with steam. When its built and distributed through steam. Steamworks will automatically close and relaunch your game through steam if it was started without steam. It doesnt do this if you have your app_id in the root folder such as when your developing. But otherwise it does. If its started without steam you wont be able to use steam features.
It now looks more and more like a Unity bug to me. And it's so disappointing to realize that the New Input System (v1.0.0) is > not being tested against one of the most obvious use cases (Steam games).
When i started targeting steam as my release partner i was absolutely shocked that steam doesnt officially support unity. Make no mistake though. This is on steams end, not unitys. Since steam is the distributor of the games, They are the ones whose responsibility it is to release plugins that support their distribution platform. Its my guess that they dont support unity because unity targets C# programmers while steamworks uses C++. Because they do officially support unreal engine.
Until they officially support unity, we have to deal with annoyances like this.
https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2936869850608535686
Improved support for games using Windows raw input APIs Unity games using the Rewired plugin should upgrade to the latest release, version 1.1.36.1.
Did this Steam update improve things at all?
Hi Riley,
Thanks for the update. Unfortunately, this update has the same problem. I am attaching the source Script to replicate this bug (be sure the New Input System is enabled in Unity).
I contacted Unity, and they said they know about this bug and are tracking it here: https://issuetracker.unity3d.com/product/unity/issues/guid/1280203
Keep on the good work. Best, .dan
On Thu, Oct 22, 2020 at 1:18 PM Riley Labrecque [email protected] wrote:
https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2936869850608535686
Improved support for games using Windows raw input APIs Unity games using the Rewired plugin should upgrade to the latest release, version 1.1.36.1.
Did this Steam update improve things at all?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rlabrecque/Steamworks.NET/issues/380#issuecomment-714737130, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMCN5EBZRWUK4COJTDV6ITSMCHQFANCNFSM4SCDKWKQ .
using System.Collections; using System.Collections.Generic; using UnityEngine; using UnityEngine.InputSystem; using Steamworks; using UnityEngine.InputSystem.Users; using System;
public class ReproduceBug : MonoBehaviour {
public bool ENABLE_STEAM = false; GameObject go_steam;
public InputActions input_; public InputUser input_user_;
// Start is called before the first frame update void Start() { Debug.LogError("Found " + Gamepad.all.Count + " controllers."); setup_InputSystem(); Debug.LogError("Press START on the controller to verify that the action is working."); }
// Update is called once per frame void Update() { // Print how manu controllers we have found.
if (ENABLE_STEAM) {
if (go_steam == null) go_steam = new GameObject("Steam");
SteamManager sm = go_steam.GetComponent<SteamManager>();
if (sm == null) {
Debug.LogError("ENABLING STEAM NOW");
sm = go_steam.AddComponent<SteamManager>();
if (SteamManager.Initialized) {
Debug.LogError("Found " + Gamepad.all.Count + " controllers.");
Debug.LogError("Press START on the controller. If the bug is present, you won't get any confirmation message from the callback anymore (you need to restart Unity).");
}
else {
Debug.LogError("FAILED TO INITIALIZE SteamManager");
}
}
}
//Debug.LogError("Gamepad status: ");
for (int i = 0; i < Gamepad.current.allControls.Count; i++) {
InputControl ic = Gamepad.current.allControls[i];
if (typeof(float).IsAssignableFrom(ic.valueType)) {
float v = (float) ic.ReadValueAsObject();
if (v > 0) {
Debug.LogError(" [" + i + "]: " + ic.shortDisplayName + " = " + v);
}
}
}
}
void steam_OnGetAuthSessionTicketResponse(GetAuthSessionTicketResponse_t pCallback) { //if (pCallback.m_eResult == EResult.k_EResultOK) { Debug.LogError("Steam authentication result: " + pCallback.m_eResult); //} Debug.LogError("Found " + Gamepad.all.Count + " controllers."); }
void setup_InputSystem() { Debug.LogError("Setting up New Input System..."); input_ = new InputActions(); int player_num = 0; if (Gamepad.all.Count > player_num) { input_user_ = InputUser.PerformPairingWithDevice(Gamepad.all[player_num]); input_user_.AssociateActionsWithUser(input_); input_user_.ActivateControlScheme("Default"); }
input_.Gameplay.Start.performed += ctx => { Debug.LogError("PRESSED: Start"); Debug.LogError("Now enable Steam using this script's boolean property \"ENABLE STEAM\"."); };
input_.Gameplay.Enable();
Debug.LogError("New Input System callback enabled.");
}
}
Hey,
I'm a Unity software engineer and currently investigating this issue (Unity bug link).
From my investigation, the problem seems to be Steam itself is (for lack of a better word) "hijacking" XInput. Unity's internal calls to XInputGetState() fail with ERROR_DEVICE_NOT_CONNECTED once the Steam API is initialized. I suspect it's actually the Steam Overlay that may be causing the problem as I found we stop getting input once this DLL is loaded.
'Unity.exe' (Win32): Loaded 'C:\Program Files (x86)\Steam\GameOverlayRenderer64.dll'.
Since it's the Windows API itself that's failing, I don't think there's anything Unity nor Steamworks can do about it, However, I'd like to find a confirmed work around which I can paste into the bugs resolution notes.
Hey,
I'm a Unity software engineer and currently investigating this issue (Unity bug link).
From my investigation, the problem seems to be Steam itself is (for lack of a better word) "hijacking" XInput. Unity's internal calls to XInputGetState() fail with ERROR_DEVICE_NOT_CONNECTED once the Steam API is initialized. I suspect it's actually the Steam Overlay that may be causing the problem as I found we stop getting input once this DLL is loaded.
'Unity.exe' (Win32): Loaded 'C:\Program Files (x86)\Steam\GameOverlayRenderer64.dll'.Since it's the Windows API itself that's failing, I don't think there's anything Unity nor Steamworks can do about it, However, I'd like to find a confirmed work around which I can paste into the bugs resolution notes.
From my test the inputs arent reaching unity and its not unity's fault for that. I found two ways of getting it working. You have to be able to open the Overlay in the editor. If you can do that, You can set the gamepad within the overlay and then it will work normally.
What is really strange is when you do get that overlay open. all you need to do is set the gamepad, The default gamepad works just fine but you still have to set it to something else. after you set it to something else you can then set it right back to default and it works. That means its default gamepad profile works just fine. Its just a matter of resetting it every time the game is started
I've mostly stopped messing with steam for the time being. But my trail of thinking was, If we programmatically unset the default controller profile then set it right back, It might work without needing the overlay.
You can also add unity to Steam as an external program. It will inject the overlay into unity and that works.. sometimes.. Its not dependable at all. so I wouldn't suggest that being a workaround.
Thank you for the reply, I'll add this information to the Unity bug.
As I've dug deeper into this problem I've discovered...Steam iterally is hijacking XInput! When the Steam Overlay module is loaded, it actually modifies the XInput API call to redirect it to it's own code; basically what a virus would do.
From Unity we call into XInputGetState() which looks like this in the disassembly:
errorCode = s_XInputGetStateFn(userIndex, &state);
00007FF78DDFAD4C mov rax,qword ptr [win::XInputDevice::s_XInputGetStateFn (07FF79E320148h)]
00007FF78DDFAD53 mov qword ptr [rsp+88h],rax
00007FF78DDFAD5B lea rdx,[state]
00007FF78DDFAD60 mov rax,qword ptr [this]
00007FF78DDFAD68 mov ecx,dword ptr [rax+8]
00007FF78DDFAD6B call qword ptr [rsp+88h] => 00007FFF40B816F0 (XInput DLL address)
...
From here the disassembly (should) look like this:
XInputGetState:
00007FFF40B816F0 mov qword ptr [rsp+8],rbx
00007FFF40B816F5 push rsi
00007FFF40B816F6 push rdi
00007FFF40B816F7 push r14
00007FFF40B816F9 sub rsp,30h
...
Now, start Steamworks in the Editor and break into XInputGetState again:
XInputGetState:
00007FFF40B816F0 jmp 00007FFF62590E4A
00007FFF40B816F5 push rsi
00007FFF40B816F6 push rdi
00007FFF40B816F7 push r14
00007FFF40B816F9 sub rsp,30h
...
Notice the mov instruction from before has been replaced by a jmp
That jump takes us to some other place in memory where we encounter these 2 instructions:
00007FFF62590E45 jmp XInputGetState+5h (07FFF40B816F5h)
00007FFF62590E4A jmp 00007FFEFA7F0790
The 1st jmp instruction, which we do not execute, takes us back to XInputGetState, and continues to execute the API normally.
The 2nd jmp instruction, which we end up calling, takes us here:
00007FFEFA7F0790 mov r8,rdx
00007FFEFA7F0793 xor r9d,r9d
00007FFEFA7F0796 mov edx,ecx
00007FFEFA7F0798 mov rcx,qword ptr [7FFEFA8EE1D8h]
00007FFEFA7F079F jmp 00007FFEFA7F07D0
...
Using the module info, this instruction address occurs within Steam's GameOverlay:
(Module) GameOverlayRenderer64.dll (Addr Range) 00007FFEFA730000-00007FFEFA911000
I'm unsure exactly what this Steam function is doing but it ultimately dumps out the error code for ERROR_DEVICE_NOT_CONNECTED before returning.
So basically Steam is deliberately overriding XInput to block input for other callers (in the same process) once the Overlay DLL has been loaded unless you do something special.
Based on the comment above, my guess is Steam redirects the XInput API call depending on the state of things. If you do the "right" thing it injects the jmp instruction to point to the 1st address (00007FFF62590E45 in this case) and everything works fine, but if you don't do the magic thingy you get the 2nd address (00007FFF62590E4A, what we're currently seeing) and Input no longer works.
So anyway, not much we can do unless we add our own hack to counteract Steam.
Hey @timkeo, thanks for the confirmation.
Could you try out your repro case with the latest beta of steam too?
This seems to be in very active development the last few weeks again.
https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896339990517078189
Improved support for games that use raw input for controllers
https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896340624042995521
Disabled experimental support for more than 4 Xbox controllers pending further testing
cc: @slouken
Hi guys, I'm one of the engineers at Valve who works on input. @timkeo, nice to meet you!
The problem is that when you initialize the Steamworks API, Steam probably doesn't know what kind of input you need. If you don't have an appID, it's giving you the desktop configuration, which defaults to disabling controller input or mapping it to keyboard and mouse. If you're using steam_appid.txt to specify your appID and have 480 in there, you're telling Steam that your application is SpaceWar, which actually has Steam Input mappings and controller input is redirected to Steam Input instead of XInput.
If you have a real Steam game, then you should make sure you're specifying that appID in steam_appid.txt, and then go to the Steam Input settings on the partner page for your app and select the "Generic Gamepad" template.
If you're just doing prototyping and don't have a Steam appID yet, you can put 1456390 in steam_appid.txt, which is an appID set up for game controller testing.
Cheers!
Thanks @slouken for the response and detailed explanation! I haven't actually developed on the Steam platform before and still learning how things work.
I'll share this information on the Unity forums so others will have better chance of seeing it.
Steamworks.NET does seem to have some role to play here then. As we do set the default AppId to 480 for a good out of box experience.
I'm hesitant to just switch right to 1456390 as the default though as a lot of the examples we have utilize content and permissions that 480 has, such as Lobby and Workshop which 1456390 may not have enabled.
Better documentation around this and pushing people to use their own AppId sooner may help.
If you test it and find things that are missing, let me know and I can enable them.
@timkeo You're welcome! We've been improving our raw input controller support so it works better with Unity. If you have any troubles with the current Steam beta client, please let me know, and I'll take a look.
@slouken @rlabrecque Curious if there is a fix, workaround or solution here?
I have been trying to figure out an issue with a game that I'm playing where it seems that the controller input gets into a broken state either when it starts the game outside of steam or if at any time during play the controller disconnects and reconnects, or if the player connects the controller after the game starts. This is with the Unity Legacy Input System if it matters. The game where I'm hitting this issue is Vaheim. I've helped them figure out fixes to other controller issues with Steam/Unity but this one has me stuck. :(
I am also testing with an Xbox One Wireless Bluetooth Controller if that matters, but I'm pretty sure I've repro'd this with a wired 360 controller, though I'll follow up if need be though pretty sure that's not a variable here. And it doesn't solve the issue for those who, like me, use that type of controller.
I wrote a simple unity app that repros the behavior only when SteamWorks.NET is being used. Even starting my app inside or outside Steam without SteamWorks.NET as part of the test app, it does not repro the issue. I've used both the default 480 and 1456390 app ID and they both repro the issues I'm seeing.
The side effect of this is that the Left and Right Trigger end up getting swapped. Normally the Left Trigger should return -1 to 0 and the Right Trigger should return 0 to 1. But when SteamWorks.NET is being used the reverse is true. And also in some situations Steam ends up telling Unity that there are two different controllers connected. It seems like when Steam starts up it uses a default of an Xbox 360 controller, but if you disconnect and reconnect it sees an Xbox 360 controller connected and an Xbox One controller. But it's the same controller. And I can see it sending the swapped data for the trigger and what it should actually be. So in the game I'm playing if you pull the Left Trigger down the game registers both the Left and Right Trigger being pulled down.
It also doesn't seem to have Axis 9 and 10 registered which are the Left and Right Trigger, but separated. So with Axis 9 you get 0 to 1 for LT and for Axis 10 you get 0 to 1 for RT.
Also are there examples somewhere that I can look at for how to use SteamWorks.NET with controller input? That might help me narrow down the issue more.
Or any other things to test out here?
@timkeo Not sure you've looked at this any more since you last mentioned finding what was going on, but do you have any ideas on what could be done here? This issue causes bugs in games that use this library with unity when using controllers. Especially when you don't have the controller plugged in before the game starts or the controller disconnects and you reconnect it. You have to restart the game and sometimes steam to get it back to working. :(
@slouken @rlabrecque I've tried a few different things like stopping SteamInput to see if it'd release messing with XInput, but didn't seem to work. I don't see any ways in the API to do anything else that might help remove what timkeo discovered it was doing, guessing that's deeper in the SteamWorks API than the csharp "shim" for the SteamWorks unmanaged library.
I can try more things out but at a loss for what to do here. I am not a game developer, though learning, so I don't have access to the SteamWorks discussion group on the Steam forums to ask there or report the issue.
Can someone see if this can be fixed at a lower level in Steam? Even just unity + steam alone without this library seems to have issues where when you first start up the game with the controller connected it reports a Xbox 360 controller when it's really an Xbox One controller, and if you disconnect and reconnect the controller by say removing and putting the battery back in it then Unity seems to think that there are both an Xbox 360 controller and an Xbox One controller connected. :/
Unfortunately there's nothing Unity can do about this problem either.
Since Steam is deliberately violating the API contract with XInput, there's no way to prevent this in the XInput implementation, and since XInput is a Microsoft library, we can't change the XInput API to prevent the hack. The only possible work-around is to hack Steam's hack and change the machine code back. Unity absolutely cannot make this kind of change.
This is something Valve will have to fix.
I can take a look at this, can you give me repro steps for a Unity noob? :)
Unfortunately there's nothing Unity can do about this problem either.
Since Steam is deliberately violating the API contract with XInput, there's no way to prevent this in the XInput implementation, and since XInput is a Microsoft library, we can't change the XInput API to prevent the hack. The only possible work-around is to hack Steam's hack and change the machine code back. Unity absolutely cannot make this kind of change.
This is something Valve will have to fix.
Figured as much, was hoping to see if I could figure out something in the API wrapper but found nothing.
I can take a look at this, can you give me repro steps for a Unity noob? :)
For sure! Gotta work for about 8 or so hours but after work I'll give you a simple steps for creating a simple project and some project code to repro a few of the things I've mentioned. Thank you!
Thank you both!
@slouken Ok, I redid everything and put it here and made it pretty much just a project you follow the log instead of all the UI. https://github.com/mle-ii/ControllerSteamWorksNet
Readme with how to build and repro. Unity package if you want to build it on your own. Along with the 2 most important files if you want to created it manually from scratch.
Also a zip file that contains the version already built.
@slouken A couple of comments on things. If you want the version of the "game" repro that shows on screen things rather than just in the logs let me know. On reason I created the console log only version was to make it easer for you to build instead of using the binaries I built myself. And I see in my repro steps I left comments about the text box, I'll fix that.
Finally, if you use a wired Xbox 360 controller it does the same things, you just have to unplug it and plug it back in to simulate the disconnect. It even seems that Unity is being told there are 2 Xbox 360 controllers connected, when it's only that one connected.
Oh and it still repros in the latest version of Steam, don't see a newer version of this Steamworks.NET library, but then I do think it's at a lower level than this library now.
On-screen feedback would be useful. I noticed that this build still uses appid 480, which is guaranteed not to work properly.
I'll upload that version, describing how to build it for someone who didn't know unity was... hard. So I gave it up.
It doesn't matter what id is used, I tried both they behave the same. I thought I had the copy for id 1456390 but I must have not put that in my build. It's easy enough to add though.
Actually, it seems I might need to rebuild it as it's now crashing after the update I just installed for steam today. :/
@slouken Huh, well it seems steam changed a behavior, the app works but only if run through steam now. Running outside of steam it crashes unless I run it from the Unity Editor. Works in the unity editor I just cannot run it by double clicking it in Explorer.
Here's the repro that logs on screen, it has the app id I believe that was mentioned was needed, that same file can be added to the other one as well, but regardless it behaves in the same way. https://github.com/mle-ii/ControllerSteamWorksNet/blob/main/OnScreenDisplayControllerSteamWorksNetMinimalRepro.zip
Can you add me as a Steam friend so we can work on this interactively? My username is slouken
These are the APIs I'm using in that repro: https://docs.unity3d.com/2019.4/Documentation/ScriptReference/Input.GetAxis.html https://docs.unity3d.com/2019.4/Documentation/ScriptReference/Input.GetJoystickNames.html
I (and the game I'm playing that has issues) is using the Legacy Input system.