After update game is forced into Legacy input mode instead of steamvr_input mode
KI2T opened this issue · comments
TLDR: @1runeberg if you could please provide any insight on what is a possible reason for the plugin not looking for SteamVRBindings manifest file? Assuming that the files are in place, they are not corrupted and no code to change Manifest path or name is executed.
More details on the situation:
The project I'm working on is a closed source so unfortunately I'm physically very limited in both my debugging and info sharing, sorry about that.
For the project itself all I have is a way to add BPs and custom assets, not code. Result of my work is cooked and packaged pak file. I dont have access to project in-editor and not even debugging symbols.
The target public build has SteamVR plugin added and packaged in. Assuming that no other additional actions are happening in that regard. Its known to be working successfully, tracking was working and bindings were hooked by the packaged project. (in SteamVR dashboard in bindings menu the action set was defined as it was in manifest file as well as actions themselves.
However after the project was updated bindings suddenly stopped being hooked by the game.
In the update SteamVR plugin dll, VR-related BPs and SteamVRBindings files were untouched!
Looking at steamVr system report I can see in VRCLIENT that the line :
[Input] Action Manifest Path set to 'M:\SteamLibrary\steamapps\common\Project\Config\SteamVRBindings\steamvr_manifest.json
is missing (was present in previous build)
As a result, headset tracking works in the project runtime, but controllers dont track and in bindings menu the actions set is "Legacy (Handed)" and actions themselves are generic and cant be used by me really.
What I tried (with no success):
- Getting SteamVR beta
- Verifying integrity of both project and SteamVR
- deleting steam_appid.txt
- Deleting Project folder in %localappdata%
- Adding SteamVRBindings in Project folder in %localappdata% in various subfolders just to be sure
- Deleted the relevant lines in Steam/Config/steamvr.vrsettings (after I tried adding bindings during project runtime the lines appeared there with matching steamapp key with things like "AutoUpdate Legacy binding: false"
- Made sure that Engine.ini has path to SteamVR plugin
- Adding a block for said project in steamapps.vrmanifest with defined manifest path. The block is getting deleted after steamVR launch.
- Project is x64.
I've run out of things to try, especially with such a difficult situation with limited capabilities.
If I were to know what exactly the guys on the project side could accidentally screw up then I could ask them to fix it but without exact directions its hard for them to do any research/debugging on their side.
Besides that, is there anything else I could try on my side? Maybe there is a way to define the path to the manifest file in some *.ini file in project config in appdata?
I have access to previous project release where it still works.
Sorry for the wall of text but it prevents some back and forth with obvious questions.
Hi @KI2T - thanks for the detailed info.
It sounds like the plugin isn't active in the build or something is preventing it from registering input properly. Is the new build breaking bindings for everyone or just a subset of users?
If it's the former, possible issues are:
(a) Configuration changes for input bindings in Steamworks - Under Application > Virtual Reality > SteamVRInput system, check if the settings and/or path to the manifest file is correct for the latest build.
(b) Change/s in how the bindings are packaged/cooked in the recent build - Check if the SteamVRBindings folder under Config are being packaged correctly.
(c) Check if the plugin is active and registering correctly during application startup. The plugin outputs detailed diagnostic information in a debug build and will output in the UE logs.
If it's the latter, other than the things you've already tried, possible issues are:
(a) SteamVR add-ons that might be conflicting with input - try disabling any that you have one at a time.
(b) Completely uninstall and reinstall the game/app from Steam entirely.
Failing these, perhaps the developers/publishers can post a debug build in a beta or private channel in Steam for you to try so you can get more diagnostic info with your setup? The SteamVR system report should've also included the exact issue, you can perhaps take a snippet of one entire game/app execution session from the logs and remove any sensitive info prior to posting for checking?
Cheers,
Rune
Hi Rune, thank you for reaching out!
Bindings do break for everyone.
Here is the full SteamVR report with altered names (id 123456 name MyProject). I'm not seeing any immediate red flags pointing to the reason but maybe you will?
SteamVR-2023-12-17-PM_07_09_23.txt
To answer your questions and comment on your suggested issue reasons:
a) Settings in SteamWorks
- Acutally looks like a possible reason. I'll ask guys on the project side to check it.
b) bindings packaging
- Bindings were never actually packaged or shipped with the project to start with. It goes as a separate package that users dragndrop manually in shipped build folder and it used to work.
c) whether plugin is active and registering correctly during startup
- I'd have to ask for a log from a debug build for that. However steamVR log suggests that the plugin is active during startup.
a2) SteamVR add-ons that might be conflicting with input
- Not exactly sure which add-ons you are talking about.
However it made me go and compare previous and current plugins list manually and I noticed one new binary included in the build. WinDualSense (DualSense5 API). As it is related to Input that may be another reason?
I'll see if I can get more info and will get back to you with results.
Thanks once again!
Cheers,
KITT
Replying to #199 (comment)
Hi Kitt,
Thanks for the logs - it doesn't seem like the application is starting up smoothly. Certainly not the input session that should have been initiated by the plugin. There also appears to be an input driver in your system that may not be working correctly.
If the project is related to new hardware or drivers not yet fully vetted by Valve, it would be best if the manufacturer contacts Valve directly via the official support channel if they haven't already: http://steamvr.com/newticket
At any rate, a debug build of the project would certainly be useful at this stage to help diagnose the VR_Init issues/retries. As it's happening to all users, the publisher should contact Valve (via link above) if they require help with diagnosing or stepping through SteamVR to see where and why it's tripping the vrserver retires. They may require access to the build to help repro.
Re: SteamVR add-ons, you can see them from (SteamVR [Hamburger icon on topleft] > Settings > Startup/Shutdown > Manage Add-Ons. Hardware manufacturers would oftentimes install an add-on when you install their runtime and/or drivers. At times, outdated ones can cause issues, so you can try disabling add-ons on this menu one at a time to check if one of them is causing a conflict with the new app build.
Cheers,
Rune
Hi Rune,
Here is the log from a session with an older build which still works.
SteamVR-2023-12-18-AM_08_49_25.txt
I'm seeing the same VR_Init fail and retry.
But after the successful connect in VRServer I see the following line:
[Input] SetActionManifestPath: Remembering call from steam.app.123456: file:///S:/SteamLibrary/steamapps/common/OLD_MyProject/MyProject/Config/SteamVRBindings/steamvr_manifest.json
Despite it says right after that
[Error] - [Input] steam.app.123456 (vive) has no configured binding. Input will not be available
it still tries and acknowledges the file (I think its just unhappy with me switching between bindings groups or whatever)
and at least it tracks controllers properly. Am I missing something else?
I do agree that Init fail is not something you want to see but apparently in this particular situation there is something else that prevents it from determining the steamvr_input type.
I'm still waiting for response from the team about all that, guys are just very busy with the project itself.
Regarding the addons, the only one present is "Gamepad support" that looks generic, I tried turning it off and restarting as suggested, made no difference.
One more question. Whats the chance that calling "SetManifestActionPath()" during app initialization fixes (walks around) the issue?
Cheers,
KITT
Case closed. Guys hardcoded a NoGamepad variable which is equivalent to -nogamepad. They did it for testing purposes and forgot to revert it. Thats why no logging traces were found.
Had to ask for help from a talented programmer to get into the memory heap to figure it out.
After we override said variable everything comes back to normal.