wine-proton
wine-proton copied to clipboard
kakra
Just Cause 3 issue
Hello first thanks for your work :)
I tried your wine-proton build, it runs on my LinuxMint 19.1 after installing some of the deb files you listed. I play JustCause 3 over Lutris Wine-Steam using Wine 4.0 Staging + Esync + DXVK 0.96 without issues, so i was hoping that with your wine-proton i would be able to kick wine steam and use Steam with proton-wine, but the Game doesn't even launch, so i think it is missing a patch from the staging, but i have no idea which one. As i searched around i saw that Just Cause 3 is using Denuvo and this can only work with wine staging because it has some patches which makes them working. I attached also the log i get using your build.
This line looks strange:
0025:err:winediag:wined3d_dll_init Setting maximum allowed wined3d GL version to 0.0.
Do you happen to run the game in the same prefix created by wine-staging? Could you clean the prefix and try again? Note: This may wipe out your saved games.
The prefix is stored in the compatdata folder, in a folder named by the gameid.
I have to check if I have access to a Steam lib having this game to try out myself. If it is really the Denuvo copy protection, I'd probably need to run this locally on my system to figure out which patch is missing.
Hi kakra,
thanks for the reply, do you think it would help if i make also a log from running Just Cause 3 on the working Steam for Windows running inside Wine. Or would it be even better if i would make a full log, not only fixme? Some one over at the proton github said he thinks it is related to proton patches, so i am not sure if it is fixable at all.
https://github.com/ValveSoftware/Proton/issues/682
It doesn't start with a wine 3.19 + staging + dxvk + Proton patches(*), running steam-for-linux, on nvidia.
But it does run fine without Proton patches (so wine + staging + dxvk, at least on nvidia), so with steam installed manually inside wine. (actually the only Proton patch to disable to get it working with steam-in-wine is the load_library's steamclient-lsteamclient swap)
FWIW, my guess is that Proton's
lsteamclientis not enough for Just Cause 3: it might be looking for something else in the Steam install (it's not gameoverlay, you can disable it from steam and it still works with steam-in-wine, and I don't the see the "load module gameoverlay" anymore with Proton).
(I did not test without wine-staging)
(*): "Proton patches" as in Proton's wine fork steam hacks and patches
A log comparing to the working version could give me first clues, so it could help. I'm not a core wine developer, so a full log with traces might not help me seeing where the problem is because I don't know much about which values logged in a trace are to be expected. But as the game crashes very early, a full log is probably short enough for a quick investigation, so feel free to post it. I may have time to look into this deeper in the weekend (that's when I get access to another Steam lib via family sharing).
sure no problem i will make a log tonight, also not a big issue if you won't waste time on it, because it runs without issue inside Wine with Steam for Windows, i was just wondering and interested why it really doesn't work even with your updated wine included into proton. Is the wine you include just with some selected staging patches by you, then maybe it really miss only another patch.
Just Cause 3 crashing even w/ wine-proton+staging, at least for me when I tried it earlier.
So the problem somewhere in the Steam client itself (or in Steam.dll, lsteamclient, the patch for lsteamclient, ...).
There are some known problems with different copy protections, and there are some tricks to load failing games, but none of them was applicable to Just Cause 3, e.g.:
- re-downloading executable under Steam client in Windows/WINE, and use it to launch a game in Proton (see Alien vs Predator)
- shifting date using
libfaketime(see Just Cause 2)
Actually I have current fork built w/ all wine-staging patches, but unfortunately Just Cause 3 was uninstalled from my library by one of recent Steam client Beta update.
@pchome do you mean you have a proton based on wine 4.x with all staging patches included? So if you could upload the proton folder somewhere then i could test it out if you want. I started to make backups of my games, i was also affected that after a steam beta update a game was deleted and again downloaded :) I have a backup of Just Cause 3 :)
I have a couple of shell scripts to generate such patch, but I should update them for 4.1 (later).
Here is the patch generated for current branch: 0001-Proton-Staging-4.1.patch.gz
Use $ patch -p1 < /path/to/0001-Proton-Staging-4.1.patch.
i don't use the branch, i only use the released pebruilt ones https://github.com/kakra/wine-proton/releases because i just wanted to test it out if this fixes the Just Cause 3 issue :)
Well, I can't share my build, cause it was built using custom CFLAGS and won't work for you.
:man_shrugging:
Ok thanks @pchome maybe @kakra can use your patch and built one for me :)
I'm currently installing the game, I'll try to reproduce the problem here... No need for logs currently.
I started to make backups of my games, i was also affected that after a steam beta update a game was deleted and again downloaded :)
I do too. But I found that re-downloading here is faster than restoring from backup: 120 MBytes/s download rate ;-)
Well, I can't share my build, cause it was built using custom CFLAGS and won't work for you.
Mine is built with custom flags, too... But for a pretty common combination of CPU features because my platform is somewhat older (Ivy Bridge). If JC3 works for me with my build, I figure we should look into changing CPU flags of my build.
@WernerAUT Okay, crashes for me too, tho I'm not having the d3d warning in the log:
0025:fixme:heap:RtlSetHeapInformation 0x490000 0 0x24e810 4 stub
0025:fixme:debug_buffer:RtlCreateQueryDebugBuffer (0, 0): stub
0025:fixme:debug_buffer:RtlCreateQueryDebugBuffer (168, 0): returning 0x98e90
0025:fixme:debug_buffer:RtlQueryProcessDebugInformation (37, 14, 0x98e90): stub
0025:fixme:debug_buffer:RtlDestroyQueryDebugBuffer (0x98e90): stub
0025:fixme:thread:NtSetInformationThread info class 7 not supported yet
002b:fixme:thread:NtSetInformationThread info class 7 not supported yet
002b:fixme:thread:NtSetInformationThread info class 7 not supported yet
Setting breakpad minidump AppID = 225540
Steam_SetMinidumpSteamID: Caching Steam ID: 76561198086800809 [API loaded no]
pid 23133 != 23132, skipping destruction (fork without exec?)
I'm now trying to figure out which patches are missing. But you probably need to find why you're having the d3d warning about the max GL version = 0.0.
@kakra i think i have the d3d warning because i am testing with the Nvidia 418.30 driver, i wanted to try out freesync with my monitor :) on Linux Mint which is just in a testing repo. I will go back to 415.27 and will retest and look if the log shows something else
@WernerAUT You should use the latest NVIDIA vulkan beta driver to fully support DXVK. I'm using 415.22.05, this actually has more features and extensions related to Vulkan than 415.27, so the older version number is actually the newer version (minus support for GPUs introduced after 415.22).
ok the 418.30 was not the reason, i know about 415.22.05 but i won't use it for now without a ppa were it is available
And okay here: ntdll-NtSetLdtEntries from staging doesn't fix the problem. Still investigating.
Ok thanks @pchome maybe @kakra can use your patch and built one for me :)
Sorry, no monolithic patches accepted as outlined in the README. But I'm in for trying to isolate the patches needed to get this running so we can concentrate on getting those specific patches upstreamed. Do you have any hints which patches would be needed? Info on JC3 in wine is very sparse except "use lutris" or "use staging". That's not very helpful if we want to get support for getting it run under Proton.
@kakra
Sorry, no monolithic patches accepted as outlined in the README.
You can change --backend=git-am in mentioned scripts to get separate commits.
--backend=git-apply was good for testing and investigation.
The difference for 4.1:
# Applied! 4.1
SKIP="${SKIP} -W httpapi-HttpCreateServerSession"
SKIP="${SKIP} -W ntdll-Hide_Wine_Exports"
SKIP="${SKIP} -W ntdll-NtContinue"
SKIP="${SKIP} -W ntdll-User_Shared_Data"
SKIP="${SKIP} -W winebuild-Fake_Dlls"
SKIP="${SKIP} -W wined3d-Silence_FIXMEs"
SKIP="${SKIP} -W wined3d-CSMT_Main"
Okay, that's messy because it contains the logs of the steam client itself. Let's try different:
Run Steam with WINEDEBUG=-all but still capture the logs generated as you previously did.
Now, with the Steam client running, please run the game exe directly and also capture the logs:
export WINEDEBUG=fixme+all,+timestamp,+pid,+tid,+seh,+debugstr,+module,+server,+loaddll
cd /path/to/game/exe
WINEPREFIX=/path/to/prefix wine NameOfGame.exe
I'm not sure if that would work but let's see. One of the captured logs should have logs of the game only, except Steam does something magic and hands over launching of the game back to the running steam client (which, apparently, games sometimes do). I no longer have such a setup (I ditched my WineSteam prefix months ago) but if I remember correctly I was able to capture logs clean of Steam client logs that way.
The difference for 4.1
@pchome All those are in my branch (minus CSMT because wine-4.x should have an inferior implementation and the other is the older one). See https://github.com/kakra/wine-proton/blob/rebase/proton_3.16/docs/patches/staging.yml
Some of those have been cherry-picked from the queue at https://source.winehq.org/patches/ so those are not yet listed there. I'll do that when I'm seeing rebase conflicts.
Current research tells me that concentrating on Denuvo may be a dead end. First glance of the logs @WernerAUT provided more looks like it's another component, probably handling certificates or crypto, or some runtime library stuff. Denuvo compatibility has been proven working for multiple titles meanwhile suspecting Denuvo first, but it turned out to be something else.
BTW: I'm doing this "just cause" I wanted to play it too for some time now :-)
All those are in my branch
Yes, -W mean skip. I'm applied them (Staging-4.1 patches) on top of your branch.
"All" w/o "listed".
@pchome Ah okay. I'm not familiar with using the patchapply script from staging (it failed me several times and I gave up). But you seem comfortable with it. Maybe we can join efforts to isolate the required patches. Could you remove all staging patches you applied on top of my branch which are obviously not related to this problem and then try the game (I'm pretending you're owning the game and could run it).
This way we can probably reduce the footprint a lot. Combined with the logs @WernerAUT hopefully will provide, it should be more easy to find what's needed. Thanks.
FWIW, my guess is that Proton's
lsteamclientis not enough for Just Cause 3: it might be looking for something else in the Steam install (it's not gameoverlay, you can disable it from steam and it still works with steam-in-wine, and I don't the see the "load module gameoverlay" anymore with Proton).
@WernerAUT I don't expect any of the Steam client requirements have something to do with it. There's another couple of patches you might want to remove: The patches replacing the Linux user name with "steamuser" so that the profile path is the same, no matter how your user is named. I think this is needed for the cloud sync to work correctly, and for when you restored your library from a backup but to a different user. It gets messy if you run the same prefix with alternating wine implementations (Proton vs non-Proton) because you end up with two user profiles in the prefix.
But other than that, we need to isolate the patches missing from my branch but existing in staging, or more exactly: we need to isolate the specific missing patches in that set of patches. Staging is a lot of patches, I really do not want to carry around all of these during rebase. It will backfire hard once Proton upstream rebases to a newer wine base version (I did that once, don't want to repeat that, that's when I threw away a lot of patches to carry around).
Also, just applying all staging and "then it works" doesn't help anyone to get it upstream (either in Proton, or even in winehq upstream). Please do not read as critique, I just wanted to explain my reasoning why I'm picky about which patches to accept. :-)
@kakra
Could you remove all staging patches you applied on top of my branch which are obviously not related to this problem and then try the game
Before isolating specific patch we need to launch the game with success. Then, for sure, I'll help you to isolate some patches. So for testing purposes you can apply attached monolithic patch on your local testing build.
Also, it maybe worth to look close into following patches:
kernel32: Don't force-load Steam.dll
HACK: kernel32: Load hard-coded Steam.dll path if relative load fails
HACK: kernel32: Return steamclient instead of lsteamclient during GetModuleHandleEx
HACK: kernel32: Swap requests for steamclient.dll with lsteamclient
Maybe add some additional traces to figure out why (if it should) Steam.dll wasn't loaded.
I'm pretending you're owning the game and could run it
I need to free some additional disk space and re-download the game. I'll do it later.
@kakra no that didn't work, for sure because i installed it using Lutris, maybe you can see in this log more, i started Lutris in debug mode lutris_debug.log