Fixed in 2.16.1, which is out (in the beta branch)
Spot checking this with an HTC Vive / mesa RADV 26.0.4 and SteamVR 2.16.2, and there's still a gremlin near here. Main menu capsule scene works, new game - campaign puts the right eye on the left eye and the HMD stops on that stalled frame. Desktop window for the game continues to work along with game audio.
Ooh. The right eye on left eye thing sounds like a different bug that I'm trying to track down. If you change the resolution to 100% in the SteamVR settings, does the problem go away?
As far as I can tell, the global render resolution setting was set to Auto, switching that to custom 100% did not have an effect. Looking in the per-application section, Carrier Command 2 had 100% and rechecking that while the game was running had wineopenxr test instance at 100% resolution.
Fixed in 2.16.1, which is out (in the beta branch)
Hello, I have changed to the beta branch and I am using 2.16.2 now connecting from the Meta Quest 3, Steam Link application from the Meta Store.
The same thing happens in the game (Carrier Command 2), as soon as I select new game the view gets garbled and stops updating. I saw no change whatsoever.
Is that something on my end? Should I change anything? Should I send updated logs and my system configuration?
@Patola - If you have new logs, yeah, send them. Any details are helpful. The original reports seemed like the same issue as BeamNG.drive, Superhot VR, etc., which is fixed in 2.16. But if C&C still instantly locks up for you, there's evidently something else wrong that we'll need to look at.
@kisak-valve - Oof. So maybe not the same issue as Walkabout Mini Golf, then, or maybe some new aspect of the same. I may want to try to pick your brain for more details on Monday...
@Patola - If you have new logs, yeah, send them. Any details are helpful. The original reports seemed like the same issue as BeamNG.drive, Superhot VR, etc., which is fixed in 2.16. But if C&C still instantly locks up for you, there's evidently something else wrong that we'll need to look at.
It's not exactly a lock-up, the game window is still working on the screen, it even responds to the controls. It's just the VR window that gets garbled with no updates.
I will get the exact same data I got when opening this bug report. This can take 1-2h
Ok, all the data I could gather:
Steam logs:
steam-logs.tar.gz
Steam minidumps:
steam-minidump.tar.gz
Steam Runtime Diagnostics
System Information
proton log from launch parameters: PROTON_LOG=+vrclient,+openxr,+file %command%:
steam-1489630.zip
video of the bug when generating the above log: https://youtu.be/8Axn1Up3R6k
Notice in the video that the screen (actually the game window) does not appear. Earlier today it was appearing for this very game. I even rebooted to try and see if it would appear but it did not. I have this issue on SteamVR, the screen view is moody, it appears sometimes but doesn't appear in most others, with no recognizable pattern. And apparently this has no bearing on the VR games, they continue to work (or not) regardless of the screen being shown.
I was trying to do this to show that the game screen was still running, but as it wouldn't show the screen in VR view, I activated the passthrough on my Quest 3 so it could film the screen and you can see that it is still running there, although it is not responding to the controls.
If you need more data, please let me know and I will try to provide this ASAP. It is in my best interest to get this resolved as soon as it can be so I can showcase the game in my Linux VR channel.
It's not exactly a lock-up, the game window is still working on the screen, it even responds to the controls. It's just the VR window that gets garbled with no updates.
Oh, okay! Yes, that's definitely different than the BeamNG.drive, Superhot VR, etc. lockup then -- those locked up on the host, and in fact locked up vrlink itself as well. I can see in your video that VRLink is quite clearly still working, but the game itself seems to have frozen, visually at the very least.
I notice you're using a specific Proton version with it -- I assume it behaves the same with other versions as well?
Oh, I think I see what's going wrong. I do not think we'll have a fix for 2.16.3 because that's already mostly locked-in, but I think I know what I need to dig into at least for @Patola's lockup situation.
It's not exactly a lock-up, the game window is still working on the screen, it even responds to the controls. It's just the VR window that gets garbled with no updates.
Oh, okay! Yes, that's definitely different than the BeamNG.drive, Superhot VR, etc. lockup then -- those locked up on the host, and in fact locked up vrlink itself as well. I can see in your video that VRLink is quite clearly still working, but the game itself seems to have frozen, visually at the very least.
I notice you're using a specific Proton version with it -- I assume it behaves the same with other versions as well?
Yes, it behaves the same on all proton versions. I usually test with at least three different versions, cleaning the prefix and shadercache between attempts as to not pollute results. For this particular test if I recall correctly I used Proton Experimental, the latest GE-Proton and Proton 10.0-4 (the latest stable). The logs are from the gameplay with Proton 10.0-4.
Well, that was certainly a fun one to track down.
Not sure when it'll make it over into the beta builds, but I'll see if we can't scoot it over into one of the next ones. :)
I am definitely very curious to test it!!!
I just tested with SteamVR 2.16.4 beta and the game now seems to work fully. I need to test it thoroughly but even the pad on the left hand renders correctly, I don't think there will be any issue. So many thanks for that!
This issue is closed and gone, no one will ever see this note, but I'm so freaking happy this problem was resolved. Carrier Command 2 is an incredible game, I am enjoying every second of it in VR, and I flaunted it with pride on my youtube channel. https://youtu.be/Qn5xZwLPTZI
proton 10.0-4x1 2026-04proton experimentalx1 2026-04PROTON_LOG=+vrclient,+openxr,+filex2 2026-04
Describe the bug
Using SteamVR via Steam Link, the game Carrier Command 2 starts ok, but right at the moment that it should start a game it stops updating the VR view and thus becomes unplayable. The window on the flatscreen continues updating and shows that it is even responding to the controls.
This behavior can be seen on this video: https://www.youtube.com/watch?v=bHCDESpE88Y
This bug was reported in proton here: https://github.com/ValveSoftware/Proton/issues/8009 but it's not a proton issue, since the game RUNS with proton with WiVRn, another openxr/openvr backend for Linux.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Game should continue working after start game is chosen.
System Information (please complete the following information):
SteamVR beta is at the same version as steamvr stable, so steamvr stable 2.14.5 should be ok.
tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs]tar -zcvf ~/Desktop/steam-minidumps.tar.gz /tmp/dumps]steam-logs.tar.gz
steam-minidumps.tar.gz
Note
There are recent proton logs on the proton issue, including one generated with options
PROTON_LOG=+vrclient,+openxr,+file %command%which give very detailed information on the openvr calls, so be sure to consult that bug report.Additional context
A proof that the problem is not in proton, since it's playable in the same proton when the openxr/openvr backend is different, can be seen in this gameplay: https://youtu.be/iDA_cOLFCtg