-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Elite Dangerous (359320) #150
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: |
Hello @jgacas, from your Proton log:
This looks like a video driver issue which should be mentioned to your video driver vendor if it hasn't been already. |
Thanks for the tip @kisak-valve , I'll search bug trackers to see if there is similar issue already reported. |
Had Elite working well ~6 months ago, came back to it recently and having a lot of trouble with it. Frequent crashes, especially when flying close to planetary surfaces. Could be something in one of the recent updates, or my system could have updated since then. System info:
Proton log: The issue happens with regular proton, experimental, GE, various versions. Tried a few launch flags, including switching Vulkan implementations. I have my GPU power limited so I know it is not overheating. I'm 100% open to it being a driver issue, I just can't confidently say based on the logs. If someone more knowledgeable could take a look and let me know if I'm barking up the wrong tree that would be great. Thanks! |
Hello @Gyrfalcon5, check if https://gitlab.freedesktop.org/drm/amd/-/issues/3343 is relevant to your system. A quick test would be to reboot into an older kernel and see how the game behaves. |
Btw, I have now |
@kisak-valve thank you for this! I didn't have an older kernel handy but I decided to be bold and compiled 6.9 with linux-tkg. Things seem to be working much better now. |
I can confirm that the game no longer crashes on Terrain Generation on Startup or when close to a planet when running on (CPU: |
I can also confirm, that ED is running stable again with linux-6.9.6 with AMD RX 6700 XT. Previously I had issues with planet generation on startup or near planets, too, with linux-6.6.x . |
So, I have the issue wherein I can't launch the game if I have an extra monitor plugged in, I use a laptop, with my main display being external |
Try min-ed-launcher. Sometimes frontier changes something and you'll need to launch the game once via their launcher anyway, but most of the time it works normally and launches the game. Tip: you don't need to include terminal emulator in launch options, you can see logs of launcher in journalctl. Handy when the game simply does not start due to this launcher. |
I'll give it a try, the AUR version of mined didn't work, will try the .exe one
|
I simply downloaded the linux binary in the game folder, near the frontier launcher itself. Startup command then looks like this: There's a subtle requirement that took me a while: make sure that your ~/.config supports executables (has no noexec flag) - mined places their .so there. If it is not, move bundle extraction dir using P.s. Today I learned there's an AUR version. |
Used the exe, worked 100%!
|
Elite Dangerous (359320) 2024 Issue transferred from #7861. Compatibility Report
System Information
I confirm:
SymptomsThe launcher is hogging CPU except/until a game has launched and exited or possibly just a time-lapse having occurred. I cannot enter the game with the Odyssey expansion selected. The first item on the Odyssey menu is 'Start' and it appears to be running an introduction/tutorial which terminates after three lines of green text with an Orange Sidewinder error. No 'Stuck Recovery' just permanent error. I suspect possibly some missing content in this introductory sequence but can't rule out a Proton-related or platform-related issue. If I play the Horizons expansion, I initially couldn't get past the 'Planet Generation' step until what I believe was a 'shader update.' I have a relatively high-latency internet connection. I don't have any reason/insight to rule latency in or out as a contributing factor. I have the 'Optimus' dual GPU design in this laptop, with the discrete GPU being an Nvidia A500 RTX. I have the various bumblebee packages installed. I can happily run glxgears (and various native apps) with either GPU using 'optirun' but have yet to see the Steam client recognise the discrete GPU at all. |
Hello @vernwinkle, please copy the contents of Steam Runtime Diagnostics from Steam ( If the game isn't choosing your NVIDIA GPU, I'd try to run the game using NVIDIA's PRIME Render Offload (https://download.nvidia.com/XFree86/Linux-x86_64/550.90.07/README/primerenderoffload.html). Try setting the game's launch options to The GPU that's being used to render the Steam client is unrelated to what's used by the game. |
@vernwinkle @kisak-valve At least I can confirm that this game has problems starting if it sees more than one GPU. I do not use render offload or anything like that, and NVIDIA is my main GPU. But my Xorg server sees both my NVIDIA GPU and my Intel iGPU (which has no monitors connected), and to make this game work, I need to use |
Steam Runtime Diagnostics #1: https://gist.github.com/vernwinkle/6c766763daf013dca043c12cfb1a55fc |
Thanks |
nvidia-vulkan-icd is already the newest version (525.147.05-7~ deb12u1). I found and installed the missing nvidia vdpau driver, but the vulkan issue might require me to think :) Update: vulkaninfo output may have a clue, https://gist.github.com/vernwinkle/26771fbb5813235a1f423ca1219ee2d8 I'm a little out of my depth here. |
Noticed this issue as it was mentioned in my old primus_vk issue (which I don't use anymore). If I remember correctly, you need to disable/uninstall your bumblebee setup to use PRIME render offload, as it gives the same functionality anyways. If kisak-valve's recommendation for the launch options doesn't work, my distro uses a synonym for this: |
Not ready to abandon bumblebee on my system for the sake of running steam, yet.. I don't see prime-offloading working alongside bumblebee, maybe I'm mistaken? Running the native VKCube app seems to operate flawlessly. All of the non-Proton/Wine-related testing comes up 100%. I've had ED Odyssey running once on my NVIDIA GPU under bumblebee and am trying to get back there.
I had one seemingly random success playing through the Odyssey intro/tutorial (NVIDIA=525), and beyond that I get a number of launches with nothing but a black screen with eventual mouse pointer appearing. I've now had my NVIDIA driver update from 525 to 535 and instead I'm back to the game process crashing, The 32bit training demo gives; 7406.029:058c:0630:warn:seh:handle_syscall_fault backtrace: --- Exception 0xc0000005 at 0xe6 The 64-bit Odyssey and Horizons seem to be back in shader-hell with the Windows crash dialog appearing at around shader-compilation time. I'm hoping when the caching expires I might see an improvement. There is a post on the NVIDIA developer forums indicating I might need to update from 535 to 550, but I'm hooked onto the nvidia-current under Debian bookworm at the moment, not sure how a forced upgrade happens. Update: Steam Runtime Diagnostics # 2: https://gist.github.com/vernwinkle/8d5d9bed8018a9fb434b4bad0bdeea1d |
As far, as I know bumblebee is old and outdated :/ I got laptop with 2 GPUs 2 years ago for the 1st time, and bumblebee was not recommended already. I used
mangohud is used to change the order of when FPS is limited (limiters are off in-game). This way mouse's cursor on buttons works better in Elite. Also I use nvidia-beta driver now. Last couple months they had many problems in stable branches. I have: |
Also an Arch user here but have been on Optimus laptops from way back. I had trouble getting Vulkan atuff to even work back during the bumblebee days (see: my issue on primus_vk) and quickly abandoned it when NVIDIA first added PRIME render offload to the drivers. As far as I know, the latter is the main recommended option nowadays.
So if you insist on sticking with bumblebee, I'm not sure how many people still use that (unless they're using cards that aren't supported by driver versions that do have PRIME render offload) and can help you with this issue.
…-------- Original Message --------
On 7/4/24 05:33, Alex wrote:
As far, as I know bumblebee is old and outdated :/ I got laptop with 2 GPUs 2 years ago for the 1st time, and bumblebee was not recommended already. I used nvidia-prime package on Arch. Script is:
export GAMEMODERUNEXEC=prime-run
export PROTON_HIDE_NVIDIA_GPU=0
export PROTON_ENABLE_NVAPI=1
export VKD3D_CONFIG=dxr,dxr11
export PROTON_ENABLE_NGX_UPDATER=1
export VKD3D_FEATURE_LEVEL=12_2
export MANGOHUD_CONFIG="fps_limit=60,fps_limit_method=early,no_display"
mangohud gamemoderun "$@" &>/dev/null &
mangohud is used to change the order of when FPS is limited (limiters are off in-game). This way mouse's cursor on buttons works better in Elite.
—
Reply to this email directly, [view it on GitHub](#150 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AA6TFUVQJDRPI5IVSWWRTQ3ZKRU2FAVCNFSM4FRBHFS2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRQG4ZTIOJZGIYQ).
You are receiving this because you commented.Message ID: ***@***.***>
|
My issues don't appear to be related to bumblebee atm. I will possibly move to PRIME at some point but at present I don't want regression/complication. Bumblebee is a unified method across different GPU hardware but is likely/probably less efficient than PRIME. If somebody would pinpoint the issue that is bumblebee-related, preventing me from running ED, I will be happy to change tack. |
Try different kernel/driver version combinations. |
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: