Comments (20)
I concur.
Simply having environment variables akin to STEAM_RUNTIME_PREFER_HOST_LIBRARIES or STEAM_RUNTIME would be a good start, or maybe a variable that points to the location of the Wine binary.
from proton.
If you read the readme, you can put custom proton builds in the compatibilitytools.d folder, restart steam, and they will show up in the drop down. However, they must be -proton- builds - either a fork of proton built as a whole or by some means which incorporates all of the necessary elements, such as my proton build or tkg's build. Wine literally needs to be compiled with some proton elements patched into it, this is why you can't just grab a random wine build and try to use it in proton.
from proton.
I'm a regular Wine user, but now for most things I'd like to just use regular Proton where possible. However there are some games that simply won't work using Proton 3.7 but work perfectly under Wine 3.14. Eg. Darksiders Warmastered Edition.
I custom build Wine myself using a winebuilder script I wrote some years back, and the result is basically a drop-in replacement for the Steam common/Prototon 3.7/dist
directory. Ideally I'd like to be able to browse and select this from the Steam Play settings menu to have the option appear in the Compatibility tool menu. Additionally, I would like the option to have the Compatibility tool selection overridden on a per-game basis.
If this were implemented, I could trivially use Wine 3.14 to play Darksiders Warmastered Edition in Steam, but just have everything else default to Proton.
from proton.
We can open PRs against it and file issues. I just wanted to mention other work is being done due to these issues.
from proton.
Don't forget LD_LIBRARY_PATH="/path/to/proton/dist/lib64":"/path/to/proton/dist/lib", I think it needs that as well.
from proton.
There is a specific option, inside steam play settings in the steam client...
Which judging by compat_log.. Seems to load a list from "AppID 891390" (wherever it mat be).
In turn that points to proton_37. compatibilitytools.vdf
is also mentioned, but I really cannot figure out anything else.
from proton.
I cannot find that file :/
A file is also not great as Steam may rewrite it later.
from proton.
I am unfortunate owner of old graphic card that doesn't have vulkan support, wine-staging with d3d11 patch is the only option for me to play dx11 game
from proton.
@rezzafr33 on the very bottom of README in repository root, there is a paragraph about runtime options, and there is one that allows using d3d11 instead of dxvk. Try using those?
from proton.
There is a specific option, inside steam play settings in the steam client...
Ok, I now see that's more about Valve's own thingies than anything.
On the other hand I think I veeeeery half assedly figured out how this works.
Valve makes to depend the various proton versions on the "ownership" of steam package number 0.
Every user get therefore to "buy" them automatically.
Same thing for steamplay manifests, "extended game id" compat_tools
, entirely stored in appinfo.vdf
.
These are then loaded and abided by steamclient.so (which is what should care of all those STEAM_COMPAT_ variables) that will assign the various proton tools paths to each respective game - unless otherwise forced in the steam settings (ie "name"
).
Again, the most straightforward method seems understanding which format steam expects the LocalToolList I mentioned above to be loaded.
from proton.
I went so far for my issue posted: #692 as to replace all the bin files in the Proton directory with my configuration from my working Lutris install. However, for me that did not fix the problem.
For those who do want to do such a thing, just copy all your files from your wine install, eg: ~/.local/share/lutris/runners/wine/staging-3.12-x86_64/
to where your steamapps are, eg: ~/.steam/steam/steamapps/common/Proton\ 3.7/dist/
And you will use those binaries.
Proton also will set the prefix to: basedir + "/dist/share/default_pfx"
, eg: .steam/steam/steamapps/common/Proton 3.7 Beta/dist/share/default_pfx/
, so you can do modifications with exporting your WINEPREFIX to that same directory for winetricks (Presuming you also override your PATH environment to use the Proton bin directory over default path. Same should be done with lib)
Example environment vairables for winetricks:
LD_LIBRARY_PATH=/home/USERNAME.steam/steam/steamapps/common/Proton\ 3.7/dist/lib64/:
PATH=/home/USERNAME/.steam/steam/steamapps/common/Proton\ 3.7/dist/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/wine
WINEPREFIX=/home/USERNAME/.steam/steam/steamapps/common/Proton 3.7 Beta/dist/share/default_pfx/
You could easily modify the python for proton, it is a really simple script, if steam were to respect environment variables properly, which I'm inclined to believe it does.
/home/USERNAME/.steam/steam/steamapps/common/Proton 3.7/proton
< basedir = os.path.dirname(sys.argv[0])
---
> env = dict(os.environ)
> dlloverrides = {}
>
>
> basedir = env.get("WINE_BASEDIR", os.path.dirname(sys.argv[0]))
104,105d107
< env = dict(os.environ)
< dlloverrides = {}
this is just a quick throw together. There are considerations with how the script works I did not at all care about for a quick example:
- Different wineprefix directory from wine bins
- Preventing override of the system wine bin directory
Creation of a new prefix shouldn't be a big deal, so i'm not worried about that.
From there it would just be a case of setting your WINE_BASEDIR or something similar in the game launch options as WINE_BASEDIR=/home/USERNAME/.local/share/lutris/runners/wine/staging-3.12-x86_64/ %command%
from proton.
I was able to get Darksiders Warmastered Edition working with Proton by following the instructions for Wine 3.7 on the appdb entry, however it's a really hacky solution (needing to chase down random dlls and run unofficial scripts in addition to winetricks) and far more work than simply dropping in a clean Wine 3.7 build.
I agree the Proton python script can be extended easily, but I'd rather not touch it unless I can get my changes upstream. Perhaps it can be extended to read a user-defined ini file for advanced users where some of the discussed functionality could be defined on a per-application basis? That would be a sufficient approach for many should Valve not wish to adjust the Steam GUI.
Heck, I just noticed #697. Not as nice as a set-and-forget GUI option or .ini file IMO, but a good start!
from proton.
Well in the simple example, it could enable for the WINE_BASEDIR
or some similar variable name to be set before the %command%
(right click game, go to properties, go to set run command). Maybe something specifically for the prefix, because the proton script SEEMS to also create it if it does not exist. I've done an initial poke testing if it "works" and it did for me. But WIP it and hope for community help to get something decent.
I figure if I at least poke the bear with a PR that is semi-functional I can get help to making an acceptable solution.
Would be cool if there was a separate steamclient interface for interacting with settings for the wine configuration, even giving you a way to also set winetricks if you're running it manually.
from proton.
Oh yeah that's a great point. The %command%
thing had slipped my mind, but that also works as a set-and-forget kind of solution I'm after too. Nice work!
from proton.
From a user on the reddit linux_gaming slack: https://github.com/Sirmentio/protontricks
makes dealing with winetricks x proton a lot simpler.
from proton.
Interesting. I can see a few problems with it however. It won't work for me since my .steam
directory is in a completely different location, and my games are installed in yet another location. All the == False
comparisons and "string"+var+"string"
concatenations aren't very Pythonic, but those are minor gripes.
The main thing I would like to see is to have winetricks executed using the Proton wine build instead of whatever is found in the current user's PATH, in order to keep the existing game wineprefix as clean as possible. I'm not sure if there are any technical issues in running that outside of Steam however - I haven't yet tried.
from proton.
Heya, I'm the guy that made Protontricks! I'm not really too professional with programming, so I can admit that I'm kind of sloppy with stuff and my code can sometimes be spaghetti (Plus I usually don't bring my code otu to the public so I don't think about how pretty it looks or how pythonic it is). What you can do is export STEAM_DIR to the directory "steam/steamapps/..." is and you'll be good to go with using it. I recently had fixed a bug that I also missed with subprocessing. Is there any general issues you have besides what you mentioned?
from proton.
@Sirmentio That's cool. You took the initiative and it does the job.
If you're interested in improving the script, my suggestion would be to run it through pylint. You will likely get feedback on the types of things I pointed out, and more.
I'm not at my home computer right now with Steam installed, but somewhere from within the Steam Settings it's possible to set a custom game directory. I have a spare HDD which I have mounted under /mnt/gaming, so I have some of my games installed somewhere under there. However, my /.steam
directory lives in a firejail environment so the path to that is different. I could set ${STEAM_DIR}
to the actual path of ~/.steam
on my home machine, but your script assumes steamapps
is directly under that, which is not the case in my setup.
Having said that, it doesn't look like your script actually does anything with anything else under .steam
so I could just set STEAM_DIR
to wherever the game in question happens to be and that would work. But it might be nice to read the Steam configuration data to determine the correct location automatically. As it stands I need to look up the root installation path and game ID anyway, so it's easier for me to just change to the directory and run WINEPREFIX="$(pwd)" winetricks [some arguments]...
.
For a script such as this, I'd personally just stick to shell scripting. It actually simplifies things for these kinds of basic tasks, and is what winetricks already uses, thus introducing no additional dependencies (although I understand Proton uses Python anyway).
What I'd like to do is see if PATH="/path/to/proton/bin:${PATH}" WINEPREFIX="${PWD}" winetricks [some arguments]...
works. I'll have to test that next time I think of it and need to use winetricks.
from proton.
"Alternate builds" means you aren't using proton anymore, so if any this would be a bug of steam-for-linux.
As I was saying in my two posts above though, there already seem to be a mechanism for extensions.
And I'm delighted to report it is being used in the wild, see e.g. here.
from proton.
I don’t know about anyone else above using alternative builds, but the only alternative build I ever used was based on a fork of the Proton code base, so it was still technically Proton compatible.
from proton.
Related Issues (20)
- Red Dead Redemption 2 on Framework 13 AMD 7840U HOT 2
- Once Human (2139460) HOT 22
- The First Descendant: After 1.0.2 patch refuses to launch HOT 1
- Civilization VI starts in offline mode HOT 1
- Unreal Engine 5 Games are Unable to play on Laptops. It is not using GPU
- Unreal Engine 5 Games are Unable to play on Laptops. It is not using GPU
- Alan Wake's American Nightmare (202750) HOT 2
- [nvidia] Games not working in fullscreen mode
- Nvidia+Wayland+Proton+Vulkan , Some games locked to refresh rate
- Envelope (2717480)
- Brotato (1942280) HOT 2
- unable to use make install HOT 2
- AutoForge (1960480)
- Random crashes in games due to SIGSYS HOT 1
- Incorrect mouse capture area with fullscreen games when secondary monitor is left of the primary monitor
- Vampire Dynasty HOT 2
- deus ex revision NVIDIA error HOT 1
- duplicate call to `xrCreateInstance` when using OpenComposite + Monado
- Fullscreen sub-native resolutions cause checker artifacts in GNOME Wayland HOT 6
- VKB Gladiator NXT badly handled as xinput controller (default) and Proton experimental breaks HID compatibility
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proton.