How to install ED on Linux using Wine [EXPERIMENTAL, NOT OFFICIALLY SUPPORTED]

[Oswald-p]

Hi there, I run a few more tests and it appeared that I can run ED with 1980x1080 resolution in window mode only.
I don't know if it is a wine (tkg wine 3.21) issue or a xfce/xorg/nvidia driver one.
Nevertheless it is possible to go to fullscreen window mode.
I finally played ED for a few hours and it runs between 40 and 60 fps with some fps drops here and there. I also have keyboard problems sometimes and I have to quit the game and relaunch it.

The conclusion is that it is possible to install ED under ubuntu 18.04 with the lutris script (see page 42). As mention by flyingspagetti manually pointing to the wine64 binnary is required.

Thank you all for your help.

See ya on the other side .

O-p

I finally managed to run ED so thank you very much for your help Mr flyingspagetti.
I am though limited to windows mode only. When I try to go to full screen 1080p it goes back to window mode. It seems to work well at 720p (full screen).
I am thinking that the game may check my config judging it cannot properly run the game at 1080p.
Does any body had the same experience?

My config (8 years old with some updates):
AMD phenomII black edition (running at 80% during the game)
Nvidia GTX 750Ti 2GB
8gb ram
ubuntu 18.04
Latest mesa + 396 nvidia driver series (idem with the 410 series)
The game is running at 60 fps on the menus and 30 fps in space (first tutorial).

I was thinking building a new config with a ryzen 7 1700 and a nvidia GTX1050 Ti next year. Would it worth it?

By all.

O-p

 

[RedMcG]

Just wanted to wish everyone happy Linux gaming during this holiday season and to congratulate everyone involved on the progress made during the final quarter of this year; with users finally having success in wine-staging, Lutris and Proton.

I don't like to make individual thanks - because I always leave someone out. But special thanks for Cmdr Eagleboy, wstephenson and Flying Spaghetti who have all made major contributions from the beginning. Also thanks to Maverick Togenada and others who after their own success have stuck around to help others.

Hopefully 2019 will bring further success with VR, the latest NVidia driver, Intel graphics and the various peripherals that are still having issues. And hopefully Frontier will provide further clarity on expectations from this enthusiastic Linux community.

 

[Maverick Togenada]

I followed your advise and changed the file descriptor limit.
Thank you also for this distinction between winxp and win7.
A question that comes to my mind is why both Cmdr Eagleboy and wstephenson, with their instructions, never ever mention these things.
Also we have RedMcG walking his own track with Proton and complaining that wstephenson is not giving all information.
Pity too that your script turns out to be only useful for a Debian distribution and not for Fedora or OpenSuSE.

I appreciate the efforts of you all, wish however that the experts posting here would be able to work as a team, providing complete information.

That of course did not stop me from following your suggestion and this distinction between winxp and win7 made a lot of difference. The installation did not lead to error messages, though it took very long (at least half an hour, so I went for shopping) and when I returned, it had halted. Not stopped. So I had to press Ctrl-C in bash.
I launched EdLauch.exe and Elite was downloaded.
Running wine64 EliteDangerous64.exe led to the same problem: 'Unable to initialise network'.
So I really think it has something to do with the port forwarding on the modem/router.
I will keep you informed.

I have now created a modified version of the script I wrote which works with DNF in openSUSE/Fedora. Here's a link. I tried running this with Fedora in VirtualBox and it worked for me. I've never used a distro without APT. So, when I was writing the script originally, I forgot that not everyone will be using the same tools. I'm still learning. [big grin]

 

[kolAflash]

The game seems to fully load (loading shaders, planetary generation system and so on...), but instead of the main menu I'm getting:

Login Failure
To ensure you are playing the most up to date version, please use the launcher to start the game.

Behind the message I can see the main menu background with the SRV, including the spinning space station.



I already deleted the Wine prefix and fully reinstalled ED (including re-downloading all game content) using the guide in this thread.
https://forums.frontier.co.uk/showt...LY-SUPPORTED?p=5763196&viewfull=1#post5763196
But that didn't help.

Verifying game files trough the launcher (I don't have Steam) doesn't help either.

$ wine reg query 'HKLM\Software\Microsoft\Cryptography' /v MachineGuid

reg: The system was unable to find the specified registry key or value
$ wine64 reg query 'HKLM\Software\Microsoft\Cryptography' /v MachineGuid

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography
MachineGuid REG_SZ XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

In regedit, only HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\MachineGuid exists. There's no HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\MachineGuid.

Copying HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\MachineGuid to HKEY_CURRENT_USER\Software\Frontier Developments\Cryptography\MachineGuiddidn't help either.

Also tried disabling iptables (set INPUT, FORWARD, OUTPUT to ACCEPT and did an iptables --flush).



I'm running "wine-4.0-rc1 (Staging)" on openSUSE-15.0. GPU is a Radeon RX 550 with the standard opensource drivers (which work very well for native CounterStrike Go, native Stellaris, native Kerbal Space Program, StarCraft 2 via Wine and some other games).

On Windows 7 on the same PC everything works fine.


Thanks for any help!

 

[EdVaessen]

We all seem to be spending lots of time dealing with wine, winetricks, dotnet40 and vcrun2017 while setting up Elite Dangerous, so I have created a script that automates the process. Just place this script in the same folder as EDLaunch.exe, set the permissions to allow executing as a program and double click the file. It will install the latest version of wine-staging and winetricks, create a new wine prefix in your home directory called "EDwinePrefix" and install dotnet40, vcrun2017 and dxvk. Then, it will start Elite Dangerous for you. The next time you run the script, it will know everything is installed and will just start Elite Dangerous using the new wine prefix.

You can download this script: here.



Potential issues:

1. Trouble during installation of dotnet40

If there is an issue during the installation of dotnet40, check your file descriptor limit and increase if necessary.
More info here.

2. You get the following error or a similar notification when the launcher is starting or when you attempt to log in:


The .exe files in your Elite Dangerous folder each have a config file such as "MachineIdentifier.exe.config" and "EDLaunch.exe.config". If one of these is missing, you will get errors like the one in the image above and the game will not start. I fixed this error by creating a file called "MachineIdentifier.exe.config" and copying the contents of "HardwareReporter.exe.config" into it. These files apparently tell the executable what version of .NET to use and the launcher therefore fails to find the correct version if they don't exist.

Contents of "MachineIdentifier.exe.config":

<?xml version="1.0"?>
<configuration>
    <startup> 
        <supportedRuntime version="v2.0.50727"/>
        <supportedRuntime version="v4.0"/>
    </startup>
</configuration>

I see you have been so kind to make a script for OpenSuSE/Fedora.

I tried it, after having changed "$HOME/EDwinePrefix" to "/data1/ed-wine-openuse" in your script on three occurences.
Reason is that my home directory is too small for Elite to download in.

After issuing 'bash EliteDangerousDNF', an error mesage appeared:

Starting Elite Dangerous...

wine: '/data1' is not owned by you, refusing to create a configuration directory there

At first, this appeared strange to me as yesterday I could set up wine (with your advise about winxp and win7) with prefix '/data1/ed-wine'

drwxr-xr-x 4 vaessen users 4096 Dec 22 21:09 ed-wine
drwxr-xr-x 2 vaessen users 4096 Dec 23 12:51 ed-wine-opensuse

I would expect subdirectory 'ed-wine-opensuse' to be accesible.

But...if I understand your script well, it is set up to install all wine programs when the directory /data1/ed-wine-opensuse does not yet exist. It then fails because wine refuses to create that directory. When the directory is already present (which was the case), the scripts immediately wants to launch the game.

 

[Maverick Togenada]

I see you have been so kind to make a script for OpenSuSE/Fedora.

I tried it, after having changed "$HOME/EDwinePrefix" to "/data1/ed-wine-openuse" in your script on three occurences.
Reason is that my home directory is too small for Elite to download in.

After issuing 'bash EliteDangerousDNF', an error mesage appeared:

Starting Elite Dangerous...

wine: '/data1' is not owned by you, refusing to create a configuration directory there

At first, this appeared strange to me as yesterday I could set up wine (with your advise about winxp and win7) with prefix '/data1/ed-wine'

drwxr-xr-x 4 vaessen users 4096 Dec 22 21:09 ed-wine
drwxr-xr-x 2 vaessen users 4096 Dec 23 12:51 ed-wine-opensuse

I would expect subdirectory 'ed-wine-opensuse' to be accesible.

But...if I understand your script well, it is set up to install all wine programs when the directory /data1/ed-wine-opensuse does not yet exist. It then fails because wine refuses to create that directory. When the directory is already present (which was the case), the scripts immediately wants to launch the game.

Yes, the script checks for the existence of the directory $HOME/EDwinePrefix. If it exists, it uses the prefix there to start Elite Dangerous. If not, it creates the prefix, prepares it, then uses it to start Elite Dangerous. With your modifications, wine is going to attempt to create the directory /data1/ed-wine-opensuse and set up the prefix there. If the directory already exists, it needs to be a functioning wine prefix, or it won't work. Wine needs to create the directory itself when it creates the prefix. If you were to just run the startgame function in the script with no prefix created, wine would attempt to create the prefix and start Elite Dangerous without installing dotnet40 or anything else.

In this case, it looks like wine can't create directories inside /data1 because whoever executed the script doesn't own /data1. I'm not sure how you were able to create a prefix there previously. Maybe someone with more Linux knowledge than me will know what happened. I would try deleting /data1/ed-wine-opensuse, then do "sudo chown -R vaessen /data1" and run the script again.

 

[RedMcG]

I'm getting:
Login Failure
To ensure you are playing the most up to date version, please use the launcher to start the game.

Since 3.3 you need vcrun2015 (instead of 2012)

 

[kolAflash]

Since 3.3 you need vcrun2015 (instead of 2012)

Perfect!

That solved the "Login Failure" bug.

 

[EdVaessen]

Yes, the script checks for the existence of the directory $HOME/EDwinePrefix. If it exists, it uses the prefix there to start Elite Dangerous. If not, it creates the prefix, prepares it, then uses it to start Elite Dangerous. With your modifications, wine is going to attempt to create the directory /data1/ed-wine-opensuse and set up the prefix there. If the directory already exists, it needs to be a functioning wine prefix, or it won't work. Wine needs to create the directory itself when it creates the prefix. If you were to just run the startgame function in the script with no prefix created, wine would attempt to create the prefix and start Elite Dangerous without installing dotnet40 or anything else.

In this case, it looks like wine can't create directories inside /data1 because whoever executed the script doesn't own /data1. I'm not sure how you were able to create a prefix there previously. Maybe someone with more Linux knowledge than me will know what happened. I would try deleting /data1/ed-wine-opensuse, then do "sudo chown -R vaessen /data1" and run the script again.

It is something to try out later.
A present, after having given my PC a static IP address and enabled port forwarding on the Ubee EVW320B modem/router, I have a working system. That is: I can now play EliteDangerous.
I gave myself a commander name and also gave one to the ship. Next, I will follow the tutorials (probably after Christmas).

Details.
Installed are:

wine-staging-4.0~rc2-lp150.577.1.x86_64
wine-staging-32bit-4.0~rc2-lp150.577.1.x86_64
wine-gecko-2.47-lp150.1.3.noarch

The next wine prefix was already put in the file .bashrc with these line:
export WINEPREFIX=/data1/ed-wine
export WINE=/usr/bin/wine64

Next the following commands were issued:
rm -rf /data1/ed-wine
mkdir /data1/ed-wine
wine64 winecfg
winetricks winxp dotnet40 vcrun2015 dxvk win7

All things went smoothly.

Then I started the game with wine64 EDLauch.exe.

Pity I can't get beyond this "Use not bound and not bound" message in the tutorial, no matter what I do with keyboard, mouse or joystick (which work perfectly in the demo mode).
There is also no way to set the controls in the menu, though things like audio and network can be edited.
In fact, the only way to get out is to use Ctrl-Alt-Delete.

Still all people here thanks so far for your advise and a Merry Christmas for you all!!

 

[Flyinspaghetti]

Hope all you Linux people are having a good Christmas however I got some bad news regarding the latest released 4.20 kernel, which is you pretty much require the (bugged) 415 branch Nvidia drivers for it as the older drivers will fail to build kernel modules.

It's sort of why I posted this the other day, as not only new kernels run the risk of breaking the older drivers but it's kind of important the bug gets highlighted and not kept under the rug.

Secondly Terrain bug is still in the latest released Nvidia driver 415.25, I've created a thread on the Nvidia Unix forum and I'd ask for anyone here even if you are happy with older branches to give your feedback on the 415 branch of drivers on either the Nvidia Unix board or the DXVK github thread if you can.

https://devtalk.nvidia.com/default/...rendering-issues-in-415-branch-up-to-415-25-/

https://github.com/doitsujin/dxvk/issues/267

 

[Junagu]

Thanks for the festive greetings from RedMcG and Flyinspaghetti and for all here who have made ED on Linux possible. I thought I'd just log on here and say that I've been playing ED for a bit over a week now on Linux (though admittedly it's Ubuntu, whereas my usual working distro is either MXLinux or Bunsenlabs) and the game runs fine in all aspects. The only thing that keeps glitching is the keyboard - it always takes two attempts at running the game before the keyboard registers and if I Alt-Tab into a different window it can sometimes drop out and I have to shut the game down and restart and then again it takes two attempts to get the keyboard working again.
Not sure this is entirely Linux related as I'm sure I've seen a few other posts since 3.3 where people have complained about the keyboard not being picked up by the game.

Anyhow - festive tiding of joy and what not to ye all.

 

[khaezaid]

Has anyone managed to get this working in VR? I have it running via Proton, but it doesn't seem to want to run in VR mode.

 

[Aquilinus]

Hello everyone!

Finally got Elite Dangerous (basegame only) running on my system after lots of fiddling and tweaking, thanks to you guys, especially @Cmdr Eagleboy. I also had to install dotnet452 twice to make it work…

My system specs:
OS: Xubuntu 18.04 with Linux 4.19.9-041909-generic
Wine: "wine-4.0-rc3 (Staging)" from official PPA
Graphics stack: Mesa 19.0.0-devel (oibaf PPA, so also latest RADV etc.), latest DXVK (currently 0.94).
GPU: AMD Radeon RX 580

~snip~

Your instructions were very helpful, but please update them to include "winetricks vcrun2015 …" instead of vcrun2012 (needed since 3.3, was already mentioned above).

The only problem now is that ED: Horizons refuses to start. The shader generation issue has already been solved as far as I can see, but when in the "preparing planet generation system" loading screen (the second screen after the shader generation thing), it slowly progresses to 12%, then the Frontier crash reporter pops up, but the loading continues to ~18%, and then the whole ED client crashes. I also saw my system memory (8GB) being nearly filled by the ED client at that point.
What could be the issue here? Graphics? Wine? I already saw this thread with exactly my problem, but that should be resolved since DXVK ~0.90?!

Thanks in advance. It's still great to play the normal Elite on Linux, of course! [smile]

 

[BurntJello]

Has anyone managed to get this working in VR? I have it running via Proton, but it doesn't seem to want to run in VR mode.

I actually just got around to trying this yesterday. TL;DR: didn't work.


Used RedMcG's custom proton for the extra fixes (the fixED.sh script didn't seem to work for me, used winetricks to manually install dotnet452 vcrun2017 dxvk).


After I got the game running through steam, I ran into another problem:

Proton does not use the same controller "buttons" as wine does. What should have been "Joy11" was showing up as "Gamepad_LSButton" (or something). This isn't a huge deal, it will just take a while to rebind my controller... but...

It seems proton is hijacking my real controller and pretending it is something else. It's causing Joy10 to act as "ESC", which is NOT bound by the game. I can't have proton hijacking any of my buttons. I need them all. I'll look into this some more another time.


As for VR, my Vive will start and show the "grid" default view. I cannot get ED to detect that it is there, even if I "Play in VR" through steam. I also tried the default proton, but that didn't work either. I have not looked through any logs yet to see if there is anything to see. It's probably something stupid like a missing reg key or something...

 

[Cmdr Eagleboy]

Hope all you Linux people are having a good Christmas however I got some bad news regarding the latest released 4.20 kernel, which is you pretty much require the (bugged) 415 branch Nvidia drivers for it as the older drivers will fail to build kernel modules.

It's sort of why I posted this the other day, as not only new kernels run the risk of breaking the older drivers but it's kind of important the bug gets highlighted and not kept under the rug.

Also to be noted, this bug is also registered by FD itself on Windows.

Also happy holidays/Christmas/end of the year everyone! I promise to rearrange and update OP sometime tomorrow, so it shows correct info (and possibly point to Wikis/sources that are updated more regularly). Thanks everybody for hard work!

 

[RedMcG]

Also to be noted, this bug is also registered by FD itself on Windows.

That's good to know. Were you advised privately in response to a bug report or is there a link? (I'm curious about the details)

 

[Cmdr Eagleboy]

That's good to know. Were you advised privately in response to a bug report or is there a link? (I'm curious about the details)

We raised awareness via bug report during beta, but I have been advised privately about this.

 

[Junagu]

by the by - is there another thread for various other linux related things?

e.g. a relative mouse/curves type thing? for FAO shenanigans etc?

 

[Flyinspaghetti]

Also to be noted, this bug is also registered by FD itself on Windows.

Also happy holidays/Christmas/end of the year everyone! I promise to rearrange and update OP sometime tomorrow, so it shows correct info (and possibly point to Wikis/sources that are updated more regularly). Thanks everybody for hard work!

I don't know if this is the same as the Windows bug, that one was more terrain randomly glitching out but could be reset by reentering the instance. This one is more a set thing in where the specific locations are always bugged and the terrain is generated the same way each time i.e. like the crater engulfing Traders Rest.

I'm thinking maybe there's an error that causes the generation to offset, I wouldn't be surprised if that specific crater can be found on the surface in a different location normally.

 

[khaezaid]

Proton does not use the same controller "buttons" as wine does. What should have been "Joy11" was showing up as "Gamepad_LSButton" (or something). This isn't a huge deal, it will just take a while to rebind my controller... but...

It seems proton is hijacking my real controller and pretending it is something else. It's causing Joy10 to act as "ESC", which is NOT bound by the game. I can't have proton hijacking any of my buttons. I need them all. I'll look into this some more another time.


As for VR, my Vive will start and show the "grid" default view. I cannot get ED to detect that it is there, even if I "Play in VR" through steam. I also tried the default proton, but that didn't work either. I have not looked through any logs yet to see if there is anything to see. It's probably something stupid like a missing reg key or something...

I suspect your issues with the controller have more to do with Steam and less to do with Proton. Remember when Steam released the Steam controller and added a way to rebind the steam controller as either a gamepad or as keyboard/mouse controls? Well, now that feature exists for other controllers too. It's been known to cause problems for some. You can try going into the controller settings in steam and turning off "Generic Gamepad Configuration Support".

As far as VR goes, according to proton logs I'm looking at, it appears as if ED does detect my Vive very briefly. It loads openvr_api.dll and vrclient_x64.dll. My Vive detects something is going on and shows me a load screen for about 30 seconds. However, the game unloads all VR stuff before it ever outputs anything to it. I'm not sure exactly why. It's rather difficult to make sense of the log, because there are many error messages, and most of them are harmless. I'll have to compare to the log for a known working VR title (ie. The Red Stare).

Also, I'm pretty sure you don't have to install dxvk with winetricks if you are using Proton. Proton comes with it's own version of dxvk, so as long as the wine prefix was created properly (ie. created by Steam), dxvk should already be working. I believe the above instructions are specific to people using standalone Wine. In any case, I've managed to run the game in non-VR mode without having to install dxvk with winetricks.