Closed coreybruce closed 6 months ago
Hello @coreybruce, as a basic check, can you go the game in Steam's library view, click on the ⓘ symbol on the right side, and verify that there's no line with something like Runs on this computer via Steam Play. Proton # selected by you for this title.
before you restart Steam, and is visible after you restart Steam?
Sure, I also had to turn on and off proton to get it to download the correct version, waiting to see what this "update" does
Here is a couple screenshots
I'm having the same issue on linux mint with tf2
Can confirm as of today's set of hotfixes for TF2, it's suddenly started downloading the Windows version instead, and I have to explicitly force the Steam Linux Runtime to get the native version back.
EDIT: Once the native version is installed again, it stays installed until the next update is pushed.
I’ve been having the same problem with X4: Foundations and a few other games. Toggling the “Force the use of a specific Steam Play compatibility tool” checkbox in the game’s properties twice will cause Steam to update back to the native Linux binaries.
In the Steam settings, on the Compatibility tab, “Enable Steam Play for supported titles” is checked while “Enable Steam Play for all titles” is not. In the past I have used the latter setting to play games using Proton which were not at the time officially supported by it, but at the moment I am not.
Steam Version: 1690583737 Steam Client Build Date: Fri, Jul 28 11:44 UTC -08:00 Steam Web Build Date: Fri, Jul 28 15:21 UTC -08:00 Steam API Version: SteamClient020
Came back to report that the issue has been resolved for me but is anyone else still having issues?
I am experiencing the issue still (Arch Linux) on War Thunder. Toggling "Force compatibility tool" fixes it on every Steam startup.
I am experiencing the issue still (Arch Linux) on War Thunder. Toggling "Force compatibility tool" fixes it on every Steam startup.
Damn that's annoying
Hello,
We have not been able to reproduce. It is possible to create a similar problem by doing the following:
The next time you start Steam, it will think it has the native version and will launch the .exe without any proton wrappings (that may or may not work, the rest of your OS might pickup the slack if you some have some sort of standalone wine/proton).
This can be fixed by toggling the runtime override and waiting for the full content update. It's not a persistent issue though, contrary to what @RA3236 reports this doesn't persist in a future steam client launch.
While what I'm reporting above is a bug, I'm more concerned by a situation where this becomes persistent somehow. @RA3236 would you be able to email your content_log.txt and compat_log.txt files to me? (ttimo@valvesoftware.com)
We haven't been able to create a situation where the content system would download the windows version when you hit play (@coreybruce) , or switch to windows when the title updates (@FuzzyQuills).
This can be fixed by toggling the runtime override and waiting for the full content update. It's not a persistent issue though, contrary to what @RA3236 reports this doesn't persist in a future steam client launch.
I have somehow just fixed the issue by launching the Arch steam
package rather than the steam-native-runtime
package once, so it's possible it's a library issue.
What happened is that immediately upon opening Steam downloads the Steam Common Redistributables and then immediately downloads the Windows version of WT (which was around a 500MB update). Once that was done, I could fix it until the next Steam startup by hitting "Force the use of a specific Steam Play compatibility tool" twice and doing the 80MB update straight afterwards. The issue started around when I tried using the Windows version via Proton GE, though I cannot remember the exact steps required.
I will email you the log files in case that helps at all however.
EDIT: The issue has started again, and won't go away by switching runtime libraries.
Thanks, got the logs will look through. We don't recommend using steam-native-runtime
, Arch's modifications are likely to cause more problems and hide real issues from us. Although in the case of this bug I don't think it matters.
This has started happening for me on stable Steam with The Talos Principle. I forced the Steam Linux Runtime on the Compatibility page while trying to get gamescope to do work. I later disabled it and Steam promptly downloaded content for Windows. Enabling/Disabling 2x as described earlier in the thread returns me to Linux content. I think the start-downloading-immediately if this checkbox is ticked is a terrible idea and a waste of bandwidth.
Edit: This is Ubuntu 23.10, new install. Intel/Nvidia.
This is happening for me with Project Zomboid after trying to run it with Proton. Prior to that it had always been the Native version.
I had selected Force the use of a specific Steam Play compatibility tool
, and Steam switched the installed version of the game to the Windows one. Ran it, and after deciding to switch it back to the Native version I unchecked the force compatibility option and Steam switched it back.
After that, Steam switches Zomboid to the Windows version after every Steam restart with the force compatibility option unchecked. Show more details
doesn't have anything anything for Runs on this computer via Steam Play.
while the force compatibility option is unchecked.
Setting the forced compatibility option to Steam Linux Runtime 1.0 (scout)
keeps it on the Native version.
I can confirm the exact behavior described by @DonKatsu for Dwarf Fortress on Gentoo. Was running DF with Proton before the native version of the game was released. (Steam Support accidentally directed me to the wrong project.)
I've had that issue with Corruption of Champions 2 (AppID: 1292690).
A fresh download of the game on my machine installs content from depots 1292691 (the game's platform-independent assets) and 1292692 (the Windows-only binaries). When clicking "Play", the game will try to run using my system-wide Wine (where it'll fail because it can't initialise the Steam API as Steam isn't running in Wine either). When the game is in this configuration, there's no "Runs on this computer via Steam Play." line showing like there would be for a game using Proton or forced to use the Steam Linux Runtime.
Forcing the game to use the Steam Linux Runtime deletes the Windows binaries from depot 1292692 and does download the Linux binaries from depot 1292693. I do have problems running the game on both my desktop PC and Steam Deck (which might be caused by the fact only the Scout runtime is selectable in the dropdown), but this is off-topic for this issue.
EDIT: this issue started appearing with the release of the game's build ID 12527428. The previous (public) build, ID 12448794, wasn't affected.
EDIT 2: it seems forcing Proton and then unchecking "Force the use of a specific Steam Play compatibility tool" then downloads the Linux files as expected. The game will then run as normal (though it's very slow to start up, which might be an issue caused by the latest build), unlike when forcing SLR, though I've noticed Steam doesn't seem to always pass the command-line arguments specified by the developers (SteamDB says the game is supposed to be passed --in-process-gpu
, but using a process monitor revealed that wasn't the case when I tried).
I do have problems running the game on both my desktop PC and Steam Deck (which might be caused by the fact only the Scout runtime is selectable in the dropdown), but this is off-topic for this issue.
It seems this bug is hard to replicate and might therefore take a while to be fixed. Maybe it could be worthwhile to add the latest release of the Steam linux runtime to the list of compatibility tools, making this workaround apply to more/recent games? @TTimo any chance of this happening?
This has happened to me a few times, most recently with Psychonauts (3830). I generally use the Linux version, but during one Steam session, I switched to the Windows version and then back to the Linux version for comparison purposes, and then closed Steam with the Linux version (i.e. no compatibility tool) selected. The next time I started Steam, it had updated it to the Windows version (despite still having no compatibility tool selected). Checking and unchecking the "Force the use of a specific Steam Play compatibility tool" box, and then updating the game, fixed it. I thought clearing Steam's download cache would prevent it from happening again, but when Steam restarted, it silently updated the game to the Windows version anyway; I had my file explorer open this time and saw the files change as I logged back into Steam. Just for good measure, I cleared the download cache again and restarted Steam again (expecting to see the same result), and this time it didn't happen, so it seems a bit random.
Disabling the overlay in the game's settings and in Steam causes TF2 to crash.
OS: Gentoo Linux Kernel: 6.1.55-gentoo-dist Display Server: X11 DE: Gnome 45.0 WM: mutter 45.0 CPU: AMD Ryzen™ 5 5600 × 12 GPU: AMD Radeon™ RX 6600
Steam logs when running TF2:
/bin/sh\0-c\0/home/roland/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=440 -- /home/roland/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- '/home/roland/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Team Fortress 2/hl2.exe' -steam -game tf -vulkan\0
chdir "/home/roland/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Team Fortress 2"
ERROR: ld.so: object '/home/roland/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/roland/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/roland/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/roland/.var/app/com.valvesoftware.Steam/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
/home/roland/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Team Fortress 2/hl2.exe: /home/roland/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Team Fortress 2/hl2.exe: cannot execute binary file
WARNING: discarding _NET_WM_PID 148233 as invalid for X11 window - use specialized XCB_X11_TO_PID function!
WARNING: discarding _NET_WM_PID 5 as invalid for X11 window - use specialized XCB_X11_TO_PID function!
WARNING: discarding _NET_WM_PID 151951 as invalid for X11 window - use specialized XCB_X11_TO_PID function!
WARNING: discarding _NET_WM_PID 148233 as invalid for X11 window - use specialized XCB_X11_TO_PID function!
WARNING: discarding _NET_WM_PID 5 as invalid for X11 window - use specialized XCB_X11_TO_PID function!
WARNING: discarding _NET_WM_PID 151951 as invalid for X11 window - use specialized XCB_X11_TO_PID function!
Hello
Same issue here.
I wanted to try the compat "runtime (scout)" on Stellaris, not proton, but when I selected "Force the use of a specific Steam Play compatibility tool" the UI automatically selected "proton experimental" !!! Not What I wanted at all. Then in background, the update to windows proton version began... Then I selected "runtime (scout)" and after I unselected "Force the use of a specific Steam Play compatibility tool". Game switched to linux version but at each steam client restart, the game is updating to windows version and is not staying to native version even if "Force the use of a specific Steam Play compatibility tool" is not selected and completely reverted to linux native version.
If having the "Force the use of a specific Steam Play compatibility tool" unselected is not enough to have Linux Native version downloaded, what should I do ?
It seems I found a workaround as it is not reproducing for now (let's wait for next Stellaris update to be sure).
What I did:
It worked for me but I don't know if it's reproducible.
Had the same issue with Euro Truck Simulator 2. Steam would overwrite the native version of the game with Windows files every time the Steam client (Arch Linux, Steam Runtime) was restarted. Launching the game resulted in Wine generating a prefix in $HOME
, so Steam at least seemed to know that I did not intend to run the game with Proton.
Enabling Steam Play and then disabling it was a temporary workaround, but didn't persist when restarting the Steam Client.
What I did:
* Force to native by toggling multiple times "Force the use of a specific Steam Play compatibility tool", wait for game to update to Linux Native in background. * Uninstall the game * Restart steam client * Toggle "Force the use of a specific Steam Play compatibility tool", select "runtime (scout)" and then let it unselected. * Restart steam client again * Install the game and verify it is linux version installed. * Restart steam client * Steam is not updating automatically to windows version of the game.
It worked for me but I don't know if it's reproducible.
These steps do indeed seem to work, Steam is working again as intended in my case. I'm inclined to say that the first 3 steps won't be necessary, but can't confirm if this is the case.
Before trying these steps I checked if a compatibility entry in ~/.steam/steam/config/config.vdf
could have been the cause for this issue, but was able to rule out this possibility, since the issue persisted after removing the corresponding entry.
Same issue with Last Epoch ( 899770 ). For me at least it is reproducible when I first install native, then switch to proton/windows and then back to native. After restarting steam the game downloads the Windows version again. I previously fixed it by manually uninstalling, reinstalling, deleting folders related to that game and eventually got native to stick again. This time the steps mentioned above by LinLo helped but it's not a good user experience.
I just came across the following comment : https://steamcommunity.com/app/975370/discussions/0/3878219568770973564/#c4038102936191705383
Now, to make the change permanent, before restarting Steam, edit the file ~/.local/share/Steam/userdata/
/config/compat.vdf. Search for this clause associated with the Dwarf Fortress app id: "975370" { "dest" "linux" "src" "windows" }
This seems to have resolved the issue for me.
Latest beta has a change that will prevent the Steam client from getting into the bad state observed here.
For titles in your library that are already in this bad state, toggling the compatibility setting once more with this beta should reset things correctly to a point where the incorrect version of the depot no longer 'sticks' after restarts.
After that beta patch went up, my Zomboid stopped downloading the Windows version with compatibility unchecked. However, while troubleshooting a problem with Brigador native where I set it to Steam Linux Runtime (scout), that is now downloading the Windows version after Steam restarts.
Steam Version: 1702667398
I really wish checking the forced compatibility box didn't apply until you close the window, since the first entry is always Proton.
Well, after toggling the forced compatibility a couple times it seems to be sticking to native again...
I just came across the following comment : https://steamcommunity.com/app/975370/discussions/0/3878219568770973564/#c4038102936191705383
Now, to make the change permanent, before restarting Steam, edit the file ~/.local/share/Steam/userdata//config/compat.vdf. Search for this clause associated with the Dwarf Fortress app id:
"975370" { "dest" "linux" "src" "windows" }
This seems to have resolved the issue for me.
This seemed to work for me as well. I tried switching to the Steam beta, but that just didn't do anything for me. For what it's worth, I'm on Nobara 38 KDE, which is based on Fedora 38.
I'm on Steam Beta version 1705720677 and the issue still happens with TF2 (440). Toggling compatibility setting on and off fixes.
Haven't seen this mentioned here yet but restarting Steam is not required for the issue to manifest for me. It reappears every time I lock my session (or it locks due to inactivity) with Steam running, and then I login again. Using SDDM, KDE Plasma, X11, in case that's relevant.
I'm on the latest stable branch of the Steam client as of writing (1705108172).
And I have been observing the same issue with Total War: WARHAMMER III, with which I initially started playing with the default native app. Shortly afterwards I decided to test the Proton/Windows version to check for performance disparity, after finding they were exactly the same I decided to switch back to native by unchecking the force compatibility tool setting and now after any subsequent Steam launches it will automatically download the Windows version with no Proton version forced.
What I've tried: Complete uninstall of the game and install with no Proton forced it will still decide to overwrite after subsequent Steam launches regardless, and I've also tried deleting the app manifest and re-downloading as well to no avail.
I've resorted to forcing Steam Linux Runtime 1.0 as that works in the meantime but just wanted to put in my experience anyway in hopes it can help fixing this.
Edit: This is with the Steam Flatpak.
~Issue does not seem to happen anymore after completely uninstalling steam-native-runtime
, running Steam beta 1706731428. I wasn't using steam-native
for launching Steam however so not sure what effect it should have.~
Edit: nevermind, the issue came back.
Hi all. I resolved the issue! At last! So, what i do? I just uninstall all Proton versions but leave only Proton 8.05. Uninstall all Solder sniper - all things that have proton words. Proton anticheat and all. Then go to Proton folders and delete all remainings for all unused proton's. Also delete all unused and uninstalled games remainings in folders. Then add compability mode for all games to Proton 8.05. Restart steam, make all updates to my games and restart more 2 times steam client to be sure if some games need updates. Then play my Borderlands: The Pre-sequel with native version - no problem. Exit game, exit steam again. Launch steam again, no problem with all games. Restart again - no problem. Also steam launch much faster with one Proton installed. If you have bunch of Protons, steam will slow more and more. So all try this and report if is ok.
EDIT: This break Proton games, and for fix then you need force re-download missing protons and soldiers or anti-cheat. To do that, go to the game properties and check files for integrity. This will force download all needed files for the game and should run this Proton game.
So if steam client will provide one cleaning tool... will be great.
I've changed to Steam Beta version, at 1708985249, and it's currently fixed!
(i will write here again as my issue #10648 has been closed and this issue is marked as "needs retest").
i recently observed this behavior in the current steam beta version 1710786209
, it seems like only Stardew Valley
(413153) is affected for me.
The workarounds i found are:
Steam Linux Runtime
, which will update it to linux again, then disable again for native library usage (but gone again on client restart)Steam Linux Runtime
, which will update it to linux again and dont disable it again (not possible for me, as somehow Stardew Valley refuses to open in steam linux runtime)1709846872
Thanks, an additional fix is pending for next beta update.
Latest beta will reset from Proton back to native correctly now.
I stopped having the problem a long time ago but left it open as other people were experiencing the problem with different games, I'm glad to see some progress and fixed for everything 🙂
can confirm my issue (from https://github.com/ValveSoftware/steam-for-linux/issues/9875#issuecomment-2012380635) as been fixed with beta update 1711139618
Steam Beta Branch: Stable Client
Steam Version: 1709846872
Steam Client Build Date: Wed, Mar 6 2:28 PM UTC -08:00
Steam Web Build Date: Thu, Mar 7 3:17 PM UTC -08:00
Steam API Version: SteamClient021
This problem still occur for me for appid 1593030
, Tera Nil.
It consistently downloads depot 1593031
(Windows) instead of 1593033
(Linux). Toggling the compatibility setting to any proton under game property will temporarily force steam to "update" to the Linux depot until the steam client is restarted, upon which the client will revert and "update" the game back to the Windows depot.
A workaround this "sticky" problem is as follows
1/ Set "Only update this game when I launch it" in game Property > Updates
2/ Under Property > Compatibility
, check "Force the use of a specific Steam Play compatibility tool", and select Steam Linux Runtime 1.0 (scout)
. Close out the property. If you see an upate for the runtime, click on the download and update it. Do not update Tera Nil if it's already on the Linux depot, otherwise update it.
3/ Close steam. Edit ~/.steam/steam/userdata/#/config/compat.vdf
and remove the lines
"1593030"
{
"dest" "linux"
"src" "windows"
}
and save. 4/ Start steam again. The problem should be gone after you "update" the app. It will not download anything and will immediately finish and should not revert again.
@Fatmice you need to be using the beta client, you're on stable.
@Fatmice you need to be using the beta client, you're on stable.
Yes, I'll wait for beta to be come stable. In the meantime, I will use the work arounds just edited my previous post. Thank you.
Just to add another use-case here that I haven't seen described, I have seen this (Windows version being installed when a Linux version is available without me explicitly setting a compatibility tool) happen in cases where I've been working on a Linux build/helping other devs out with Linux packaging - times where I've gained a licence for the game before a valid Linux config existed.
Since I never notice this until after I've set up a valid Linux config, it's been difficult to reproduce/get useful information on. It's possible that bringing up the install dialog while checking to see whether my Steam client can see the Linux depot is enough to get a compatibility tool set (Kisak and I were speculating this might be the case), but I can't say for sure that I'd done that every time I'd encountered this.
@TTimo, is the beta fix you mentioned likely to address this too? I don't currently have an app with a pending Linux build that I could check with. It's a bummer to think that Linux users who buy a game in anticipation of a forthcoming Linux build might end up unknowingly missing it.
@Cheeseness no the changes made here would be completely unrelated. This is for user initiated compatibility tool overrides.
If I understand what you are describing correctly, a game would be released with support for Windows first, then Linux is added later as a supported platform. People who had it already installed before Linux availability would have the Windows depot locally, I don't think there's any mechanism that would switch them over.
If it gets reviewed and gets a compatibility report to native rather than Proton, then it would switch I think (assuming that the user has not applied a local override). Same thing would happen if we get a request to map the native version to the sniper runtime (e.g. an entry in the app info on the backend).
@Cheeseness no the changes made here would be completely unrelated.
No worries. Next time I'm in a situation where this might happen, I'll take closer note.
People who had it already installed before Linux availability would have the Windows depot locally, I don't think there's any mechanism that would switch them over.
In the cases I've experienced, the games were never installed before a valid Linux config existed.
Same thing would happen if we get a request to map the native version to the sniper runtime (e.g. an entry in the app info on the backend).
Where in the backend is this configured? I've been looking over the partner site and haven't been able to find a relevant setting. Or is that specific to Steam Deck compatibility review results? Kisak tells me this isn't configurable on the partner site at this time.
I'm in the process of releasing a game https://store.steampowered.com/app/2730680/Learn_Japanese_Yuke_and_the_Book_of_Yokai/ and was hitting this bug.
The workaround that @db48x proposed, toggling the "Force the use of a specific Steam Play compatibility tool" on and off worked for me. Since then, the game is downloading the Linux depo. But of course, this is not a proper solution since I doubt a normal player will do/know this.
Just retested this issue with three games on the current Steam beta after encountering it again on the stable release. Seems to be fixed on the beta. In each case, Steam did download Steamworks Common Redistributables and scheduled an update to the game while I held the drop-down list open. After selecting Steam Linux Runtime 1.0 (scout) and going to Manage Downloads, Steamworks Common Redistributables had already completed and starting the download for the game immediately aborted it. Restarting Steam did not result in anything being downloaded each time I enabled or disabled use of Steam Linux Runtime 1.0 (scout). The timing on when anything is downloaded still seems wonky to me.
Closing per "Fixed a situation where Steam would attempt to execute the Windows version of a title without using Steam Play" in the 2024-05-07 Steam client update.
Your system information
Please describe your issue in as much detail as possible:
Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist
Steam will download the Windows version of 7 Days to die and if I do get it to download the correct native Linux version the next time I open Steam it will say it's updating Steam but will change it to the Windows version even tho I didn't tick the box to use proton on the game.
Now I am forced to update when I already have the game files and I can no longer play the game though proton due to them breaking EAC in Alpha 21 which I have also reported..
https://community.7daystodie.com/topic/33156-7-days-to-die-alpha-21-broke-eac-linux-proton/