-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Elite Dangerous (359320) #150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
|
At the bottom of the log, I get this:
I think the terminal is asking a question and expecting a response. I tried running Steam in a terminal, but it didn't render this. I'm also not sure how to directly run the game itself in a terminal. Somehow, I think I just need to answer this question. Adding |
This simply means that the game didn't fork, spawn a new process to continue, so wine/steam didn't need to kill the child process. This almost always shows up once a game using proton closes, successful or not. A sort of rhetorical question for anyone reading the logs. |
also, Elite: Dangerous still doesn't correctly run inside wine environments. It's mostly there, but so-far only one of the tutorials has actually been run using wine. Unfortunately, it appears that the launcher for Elite is still not successfully running, which is what is crashing. In general, if a game doesn't launch with Steam Play enabled, there is a good chance it just doesn't work in a wine environment yet. |
I tried it with proton and lots of standalone wine setups with and without dxvk. None have worked, sadly... Hopefully, this will change some day. |
Here is a complete log file. Running Proton 3.7-5 Beta. |
Probably the most important part of that log, idk just trying to be useful `15872.052:0008:0009:trace:module:load_dll Loaded module L"Z:\home\neo\.local\share\Steam\SteamApps\common\Elite Dangerous\EDLaunch.exe" (native) at 0x400000 15872.052:0008:0009:err:module:LdrInitializeThunk Main exe initialization for L"Z:\home\neo\.local\share\Steam\SteamApps\common\Elite Dangerous\EDLaunch.exe" failed, status c0000017 15872.054:000c:0026:trace:module:MODULE_InitDLL (0x7feca1c40000 L"rpcrt4.dll",THREAD_ATTACH,(nil)) - CALL 15872.054:000c:0026:trace:module:MODULE_InitDLL (0x7feca1c40000,THREAD_ATTACH,(nil)) - RETURN 1 15872.054:000c:0027:trace:module:MODULE_InitDLL (0x7feca1c40000 L"rpcrt4.dll",THREAD_ATTACH,(nil)) - CALL 15872.054:000c:0027:trace:module:MODULE_InitDLL (0x7feca1c40000,THREAD_ATTACH,(nil)) - RETURN 1 15872.071:000c:0025:trace:module:MODULE_InitDLL (0x7feca1c40000 L"rpcrt4.dll",THREAD_ATTACH,(nil)) - CALL 15872.071:000c:0025:trace:module:MODULE_InitDLL (0x7feca1c40000,THREAD_ATTACH,(nil)) - RETURN 1 15872.072:000c:0028:trace:module:MODULE_InitDLL (0x7feca1c40000 L"rpcrt4.dll",THREAD_ATTACH,(nil)) - CALL 15872.072:000c:0028:trace:module:MODULE_InitDLL (0x7feca1c40000,THREAD_ATTACH,(nil)) - RETURN 1 15872.072:0018:001c:trace:module:LdrShutdownThread ()` |
I'd like to add some update on this, with latest Proton versions dotnet installing is fixed so using winetricks/protontricks with a version of wine where dotnet40 doesn't fail (in my case I got 3.17 staging as my system wine) you can install dotnet40 into the Proton prefix. i.e. 2/ WINEPREFIX=$PWD/pfx winetricks corefonts dotnet40 vcrun2012 quartz 3/ WINEPREFIX=$PWD/pfx winecfg - then set mode back to win7 After doing that launcher should open,but that's only the first half of the battle. There are a number of issues, first is openvr_api_dxvk.dll prevents the main game from displaying the splash screen. Second is a problem previously a roadblock in wine where the CRC check fails making the main game unplayable. Third is another new issue where even the previously playable combat demo would freeze despite working perfectly in standard wine. |
Update: Game is now working in wine but not proton, here's my compatibility report. Compatibility Report
System Information
SymptomsGame now works in Wine staging 3.18 with DXVK using a simple registry fix listed here: https://forums.frontier.co.uk/showthread.php/366894-How-to-install-ED-on-Linux-using-Wine-EXPERIMENTAL-NOT-OFFICIALLY-SUPPORTED?p=7082698&viewfull=1#post7082698 However game still freezes in Proton even after applying the same fixes, the login issue has been resolved but something "Proton specific" causes the game to freeze a minute after starting up. Here's it running under Wine staging: https://youtu.be/JcDY4WFENug ReproductionSimilar to the steps in this video: https://youtu.be/jG7TUOXZhng 1/ 2/ Navigate to HKLM/Software/Microsoft/Cryptography 3/ The above will make the launcher and game start in Steam/Proton and will also fix the authentication error, however game will freeze in about a minute (sometimes sooner). This doesn't happen under Wine staging therefore issue is to do with Proton. Also @byte1024 post from other thread:
I've tried this and it doesn't work, it seems Proton itself uses a builtin rsaenh library and doesn't launch when you try to use a native version. Also I'm not sure Cryptography is the issue anymore as this freeze occurs even on the combat demo which was working perfectly fine in wine before the registry fix. |
Another update: Thanks to RedMcG again on the frontier forums I have now got into the game in Steam Proton... BUT using anymore than one CPU core will freeze the game. Simply follow the winetricks, regedit & winecfg steps in the post above, to get into the game without it crashing "taskset -c 0 %command%" needs to be set in the launch options. Obviously not very playable but it works. Bu the question is why using more than one thread cause issues with this game in Proton yet not with Wine Staging? |
The esync patch set is probably the first diff that comes to mind.. |
I'be already tried PROTON_NO_ESYNC=1 %command% , tried older versions of Proton too no difference. Tried WineD3D instead of DXVK still freezes up. Maybe some implementation Wine has which Proton's missing? |
I'm having trouble with your solution. I feel like I could be missing something obvious, considering I'm new at troubleshooting Proton, but perhaps this may come in useful anyways. I tried the following on two distributions (Solus 3.9 & Ubuntu 18.04):
After doing that, launching the game has no effect. There is no launcher, and no game. Here are the log files: |
At least with Ubuntu you're getting: I'm not sure why though. The log doesn't have anything immediately noticeable to me. Comparing it to Solus is the only difference I notice:
Perhaps bad exe on Ubuntu or the storage location doesn't work well? If there's something else in the log, I don't feel like trying to find it =) With Solus: |
I should be clearer as you don't appear to have mscoree listed in your log. First thing needed is having at least wine staging 3.17 or higher installed on your system to install dotnet40, along with installing winetricks. Assuming you have steam installed in the default place open terminal and type (replacing yourusernamehere with yours): WINEPREFIX=/home/yourusernamehere/.steam/steam/steamapps/compatdata/359320/pfx winetricks corefonts dotnet40 vcrun2012 quartz Install those clicking on the accept when installers pop up then: WINEPREFIX=/home/yourusernamehere/.steam/steam/steamapps/compatdata/359320/pfx regedit Edit the keys as stated above then: WINEPREFIX=/home/yourusernamehere/.steam/steam/steamapps/compatdata/359320/pfx winecfg Change to win7. All done the launcher should work, you might get rundll32.exe errors but just continue on. |
This was a full fix. Thank you. |
After using all the winetricks and changing the values in regedit as proposed here, the game crashes in the shader loading stage. When I'm lucky I can see the shaders loading until 10% and then the game crashes. I tried both with DXVK and with Wine D3D11, tried setting video memory in regedit to 128 MB and to 2048 MB but had no luck. The errors using DXVK and Wine D3D11 are different but seem related: Wine D3D11:
DXVK
The complete logs: steam-359320-d3d11.log On Windows, both host and iGVT-g guest, shader loading takes 1 or 2 seconds. |
I get the same thing with Haswell desktop integrated graphics: cpuinfo: vulkaninfo: glxinfo: I had put it down to being Intel graphics specific (there's a warning about the vulkan driver being incomplete), which you also appear to be using. |
I don't think it's Vulkan, more specifically Intel ANV, the problem. If it was, the bug that happened when using Wine D3D11 translation to OpenGL would be different. Notice how the addresses from the error messages are very close, it seems to be some common code between i965 and ANV or even the i915 kernel driver. |
I looked in to that and found the answer lies with a single patch in wine-staging: I patched Proton 3.16-4 Beta with this patch and now it runs fine without needing any tweaks to the launch options. I just created a fork which, in addition to the above, fixes a few other things with ED in Proton 3.16:
I'm happy to share the binaries if anyone knows a decent place to upload them. I haven't tested them on another machine yet, but I compiled against the Steam Runtime - so I think they should work on distros other than Ubuntu 18.04 (on which I compiled). |
In case anyone comes here with "preparing planet generation system" issues on Horizons, there are some AMD-specific DXVK issues along with some work arounds. Check out doitsujin/dxvk#36. |
This game apparently can run pretty well but it requires wine 3.19 staging. Requires dotnet452 vcrun2012 to run correctly. https://www.youtube.com/watch?v=XsirDkR6ZQw @redmcg why don't you create a pull request for proton's wine with that patch? |
I have now (see ValveSoftware/wine#33) - but taking a look at the ones that are there I don't see much success (after all - these patches are for one game tested on a single machine). But I do think Valve cherry-pick the ones that interest them from upstream - so this may bring the individual patches some attention. |
This patch was upstream in wine staging right? They'll probably apply it then, if it was good enough for wine-staging, it's probably good enough for proton. |
I've created a Git 'release' that includes a tarball with the binaries from my fork. It's compiled on Ubuntu 18.04.1 but against the steam runtime - so I think it should be fine on other distros. I'd be interested to hear how it goes (on other machines and potentially with other games). You can find instructions and the release here: |
I fixed my issue by installing |
Welcome to the "Arch" club :D |
@foresto It's highly recommended you turn off shader caching in the steam settings. |
Do you mean shader pre-caching, in the global Downloads section? Recommended by whom? Thanks for the suggestion. I'll give it a try as a workaround, but I think this still ought to be fixed, since the problem is only affecting one game and it would be nice to take advantage of shader pre-caching in other games. |
Yes. It affects many games, not just Elite. I forgot who recommended it to me exactly, a YouTuber if memory serves, but modern hardware compiles the shaders so quickly pre-caching is just not needed, it uses a ton of space and it makes you wait to play the game. |
I don't think this is true. But modern drivers provide a way to handle shaders differently for caching, so DXVK and vkd3d can more efficiently cache the shaders by themselves instead of relying on a collect/distribute/replay system like fossilize to pre-compile shaders. Pre-compiling is still able to prevent stutters happening the first time. For me, ED does only precompile shaders if the drivers or the kernel changed. If it does it more often for you, and also creates more than twice the amount of shader cache than expected, your cache may be broken an you should delete it. Stop Steam completely, then: rm -Rf ~/.steam/steam/steamapps/shadercache/359320 # <- this is the Steam ID of Elite Dangerous Then start Steam again, check for game downloads, it should download the shader files, and re-compile those once when you start the game. It may do another round of pre-compiling after the next start of the game but then it should not happen again until you update your drivers or kernel. For me, this directory holds 2.5GB of shader cache data:
You can purge old stale shader cache data with this command (not touched in the last 180 days): find ~/.steam/steam/steamapps/shadercache/* -type f -mtime +180 -delete If you want to preview the list first, drop |
Elite Dangerous crashes (again) on Planetary Generation (359320) Issue transferred from #8427. System Information
I confirm:
SymptomsThe game immediately freezes or crashes at the "Planetary Generation" screen. Reproductionlink to the Steam system infos
I tested with Proton 6.x and older, the game WILL load but within 3 minutes into the game, it will freeze my entire X session, i need to switch tty to kill the process. |
Hello @AZRAEL-III, |
I know, but the issue is still here, i tried, i mean i TRIED very hard (for the last 3 months) to make the game works, and it doesn't. So how can i solve this mesa issue, because this is the same issue for EVERY user on protondb who uses an Arc GPU on Elite Dangerous |
With Proton 10 (and its experimental branch), my joysticks are no longer recognized. The games binding error log file states:
Switching back to Proton 9 fixes this. I'm not sure if this is an artifact from earlier version of Proton which cached the joysticks as gamepad in [System\\CurrentControlSet\\Enum\\WINEXINPUT\\VID_231D&PID_0201&IG_00\\273&03004FDD1D2300000102000011010000.0&0&0&1] 1746387592
#time=1dbbd2c4e2093d2
"Class"="HIDClass"
"ClassGUID"="{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}"
"CompatibleIds"=str(7):"WINEBUS\\WINE_COMP_HID\0"
"ConfigFlags"=dword:00000000
"DeviceDesc"="Wine HID compatible device"
"Driver"="{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}\\0011"
"HardwareID"=str(7):"WINEXINPUT\\VID_231D&PID_0201&IG_00\0"
"Service"="winehid"
[System\\CurrentControlSet\\Enum\\WINEXINPUT\\VID_231D&PID_0201&IG_00\\273&03004FDD1D2300000102000011010000.0&0&0&1\\Device Parameters] 1746387592
#time=1dbbd2c4e1fd4e2
[System\\CurrentControlSet\\Enum\\WINEXINPUT\\VID_231D&PID_0201&XI_00\\273&03004FDD1D2300000102000011010000.0&0&0&1] 1746387592
#time=1dbbd2c4e1da7ee
"Class"="HIDClass"
"ClassGUID"="{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}"
"CompatibleIds"=str(7):"WINEBUS\\WINE_COMP_HID\0"
"ConfigFlags"=dword:00000000
"DeviceDesc"="Wine HID compatible device"
"Driver"="{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}\\0009"
"HardwareID"=str(7):"WINEXINPUT\\VID_231D&PID_0201&XI_00\0"
"Service"="winehid"
[System\\CurrentControlSet\\Enum\\WINEXINPUT\\VID_231D&PID_0201&XI_00\\273&03004FDD1D2300000102000011010000.0&0&0&1\\Device Parameters] 1746387592
#time=1dbbd2c4e1cc82e I've created a backup copy of So there's clearly a problem with old stray xinput references in I'm running with The patch for properly handling those and similar joysticks has been added here: @rbernon Do you want to take a look if you are still working on that subsystem? I can send the backup copy of the "broken" According to ValveSoftware/wine@c5a726e, the proper checks are still in place. Update: Cleaning |
@AZRAEL-III From a friend, I know that the game also crashed on Arc with Windows. Lately, it seems to be fixed there (although, the performance is exceptionally bad sometimes, especially when entering the mail slot or during various effects while fighting). Also, I've seen this game (and others) crash, if DXVK also sees the iGPU, so I'm using |
With Proton 10, mangohud is showing on the launcher while it initializes. |
@kakra Could you attach a log with PROTON_LOG=+hid,+setupapi,+plugplay log with Proton 10 with the old prefix where it doesn't work, and another one with Proton 9 with the same prefix where it works? |
@rbernon Okay, now things become strange: it was hard to reproduce today. I've created a log at each testing step. In case order matters, I've prefixed each log file with a number. Here's what I did:
The system hasn't been rebooted since yesterday. So I wondered what has been different yesterday. Actually, there's a difference: I'm playing Elite Dangerous with opentrack to track my head movement via webcam and reflect that into the game. That's immersive and a great enhancement, btw... Opentrack works by detecting Now I can reproduce the problem!
I repeated step 6 a few times and can confirm it is now working. Confused? Yes, me too. :-D So this feels like a race condition. I'm not even sure if opentrack is causing this (as I'm not sure if it was started during all the tests yesterday). Maybe opentrack starts a bit too early and causes race conditions in wine booting? It watches PIDs and checks for the cmdline name Maybe something is initializing/loading slower right after launching with another Proton version? Maybe that's causing a race? Or has there been an update to Proton 10 Experimental since yesterday? But this is pure speculation. Whatever it is, it worked reliably with Proton 9 throughout multiple minor versions... I just tried again, my HOTAS still works, and I actually launched into a game session: head tracking is also working. There was another issue yesterday: Sometimes, head tracking with Proton 10 would not work in the game (ignoring the HOTAS problem). But it reliably worked with Proton 9 (including my HOTAS). I did multiple rounds of testing yesterday, about 2 hours probably, switching back and forth different combinations of Thanks for investigating. I'll let you know if it happens again and stick to Proton 10 Experimental for now. BTW: mangohud still shows its overlay with Proton 10 within the ED launcher while it initializes... |
Proton Hotfix/Experimental suddenly doesn't work with VKB Gladiator NXT EVO R Issue transferred from #8662. Compatibility Report
System Information
SymptomsI use a VKB NXT EVO Omnithrottle L with an NXT EVO R (Premium version), and after updating Proton my right stick stopped working completely (anything inside the wine prefix was unable to receive any axis or button input from it, even if it was connected without the left stick). Reverting to Proton 9.0-4 fixed the issue. I also checked the registry with I also tried completely ReproductionAttempt to use a VKB NXT EVO R Premium on the latest Proton Hotfix/Experimental version. |
Hello @romner-set, can you see if you can gather a Proton log with the launch config requested at #150 (comment)? |
@kisak-valve Thanks for the quick response! Clean prefix ( After switching to 9.0-4: steam-359320.9.0-4.log.gz Both logs are of starting up the launcher and clicking a few buttons first on the left joystick (detected) and then on the right one (not detected on Experimental). |
@romner-set If you clean the prefix, all bindings in ED will be lost and you have to reassign the bindings to your NXT EVO. That's why I keep a backup (via snapper snapshots) of my wine prefixes, additionally I've copied the So if you start from a clean prefix, your joysticks would no longer work in ED until you reconfigure them in the game. Did you take that into account? |
@kakra I'm aware, I backed up the whole Bindings dir before deleting the prefix and tested the joysticks by trying to assign them to some controls in ED (+ opentrack in the same prefix, which resulted in the same behavior and pretty much confirms it's not a game issue). |
@romner-set Ah okay, so you are using opentrack, too. But you couldn't confirm any correlation between using opentrack and the joysticks missing? I'm using the exact same joystick models you're using. For me, it somehow started working during the tests I did. This looks like a race condition. Let me try again now to see if it still works for me. |
@kakra Nope, whether opentrack was running or not didn't change anything for me. It's weird how my omnithrottle worked fine even on Experimental though. I also use the Windows version of opentrack inside Proton with opentrack-launch while (if I understand correctly) you're using the native version, so both of us using opentrack might just be a coincidence (especially since my problem occurs even with a clean, opentrack-less prefix). I also checked the registry on my side and couldn't find any references to WINEXINPUT, so I'm not even sure we're facing the same problem. |
@romner-set Yes, I'm using the native version which maps the TrackIR driver into the prefix. So I think we can rule out opentrack. You could try unplugging both joysticks, then plug either of them back in first. This changes the order in which the game and/or wine see the joysticks, and see if this changes behavior... If it does, there's probably really some weird race condition going on. I don't think it's a problem with the game itself but rather something inside wine. There's also an issue (already present in Proton 9) where all the new Ubisoft games won't detect my gamepad unless I disconnect and connect it again while the game is running. Some people fixed this by adding a second "fake" controller via software emulation. So that sounds strangely similar but it's probably unrelated because it was already present in Proton 9.
This is an artifact of an earlier bug in Proton 9 where VKB has been detected as a gamepad and wasn't preferred as a hidraw device inside wine. I actually created the patches which fix this, they have been squashed (along with patches for other joysticks) as a similar patch in Proton 10. After this recent incident, I cleaned the |
@kakra I tried that before reporting the issue, I also tried completely unplugging either the left or right stick, swapping the ports around, using motherboard ports instead of the front panel ones, pretty much everything I could think of, restarting the game every time... and nothing ever changed. Omnithrottle works fine on any version, right stick only works on 9.0-4 or lower. Almost makes me think it's a hardware issue, but the sticks are practically identical and should be running pretty much the same firmware, so that feels unlikely. Both are also pretty much brand new (~1 month old) so I doubt it could be a malfunction. |
After saying that I decided to try and flash the firmware version made for the omnithrottle ( @kakra Try flashing both sticks with the latest omnithrottle firmware, might fix your problem as well. |
Uh oh!
There was an error while loading. Please reload this page.
I've just tried starting Elite Dangerous and it seems to not even display the game at all. It just starts and 1 second later it shuts down
I don't know how would I debug it so I would be glad if someone could instruct me on how to enable verbose for Proton Games
OS: Ubuntu 18.04
CPU: AMD Ryzen 5 1600X
GPU: Nvidia GeForce 1050 Ti 3GB
Driver Version: Nvidia Driver 396
The text was updated successfully, but these errors were encountered: