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

I've been messing around with Lutris installer scripts (submitted one), still some manual work needed due to the fact I can't seem to run or set wine64 in the script without it breaking but downloading ED and installing most of the core components including .Net is all sorted.

If you want to try out the script locally in the mean time:

1/ Download the script here: https://drive.google.com/open?id=1asCeOXSRWhYjDyXrsSvdoufDZW1i0ccH

2/ In terminal simply:

Code:
lutris -i /path/to/edinstaller.yml

3/ After installing you need to set the custom wine to wine64 in the games configure>runner options.

Recommended path to set:
Code:
~/.local/share/lutris/runners/wine/tkg-3.20-x86_64/bin/wine64
 
Managed to compile 3.20-staging in Debian Testing the other day, and it all works splendidly (hurrah!) - apart from ED not recognising my t16000m throttle (boooooo!) - that's the only thing which prevents me from properly using ED. WINE sees both joystick and throttle in the prefix's control panel joystick test application, but ED is only seeing the joystick and not the throttle. Maddening. Still working fantastic on Arch though. Even better since dxvk updated recently.
 
I've been messing around with Lutris installer scripts (submitted one), still some manual work needed due to the fact I can't seem to run or set wine64 in the script without it breaking but downloading ED and installing most of the core components including .Net is all sorted.

If you want to try out the script locally in the mean time:

1/ Download the script here: https://drive.google.com/open?id=1asCeOXSRWhYjDyXrsSvdoufDZW1i0ccH

2/ In terminal simply:

Code:
lutris -i /path/to/edinstaller.yml

3/ After installing you need to set the custom wine to wine64 in the games configure>runner options.

Recommended path to set:
Code:
~/.local/share/lutris/runners/wine/tkg-3.20-x86_64/bin/wine64

Yeah I noticed this when I was poking with lutris. It seems to be a slight deficiency in lutris to be honest - it should be possible to specify the wine64 executable directly, not via this hack.
 
Yeah I noticed this when I was poking with lutris. It seems to be a slight deficiency in lutris to be honest - it should be possible to specify the wine64 executable directly, not via this hack.

Lutris has got two problems with scripts, first it won't run wine64 or custom runners off the bat i.e. if you attempt to use a custom runner by setting version: custom in the script it will cough up an error saying x86_64 isn't supported even if you point it to just the "wine" binary it would use normally.

Secondly if you set the custom_wine_path straight to wine64 with intending the user to flip the mode to custom themselves after install it won't recognise that path until the user themselves actually manually browse and select it.

Unless they fix that anytime soon and allow selection of wine64 in the scripts a one click install script doesn't seem possible for lutris.
 
Managed to compile 3.20-staging in Debian Testing the other day, and it all works splendidly (hurrah!) - apart from ED not recognising my t16000m throttle (boooooo!) - that's the only thing which prevents me from properly using ED. WINE sees both joystick and throttle in the prefix's control panel joystick test application, but ED is only seeing the joystick and not the throttle. Maddening. Still working fantastic on Arch though. Even better since dxvk updated recently.

I've been looking in to dinput (and xinput) as I had issues with my controller under Wine (but it worked fine with Proton). So two things you could try are:
1. Change the axis mapping for your throttle via the registry (see the second entry under DirectInput: https://wiki.winehq.org/Useful_Registry_Keys); or
2. Try the SDL driver (patch for this is attached)

The SDL driver is lifted straight from Proton. After applying the patch, if you run 'wine64 control joy.cpl'; you should see an additional entry for the sdl driver (you may need to disable any other driver for the same device for it to work in ED). The SDL code has support for the Warthog throttle - but I didn't see anything for the t16000m (so it may end up with the same mapping as the 'event' driver).

The other change that Proton had (which was more relevant to my controller problem) was that it added HID entries with genuine VID and PID where as Wine masquerades your device as an XBOX controller (presumable because the XBOX controller has greater game support). But it seems Elite Dangerous iterates the devices in dinput and will only defer to xinput if you have an entry with the same VID and PID. Which is why it worked in Proton but not under Wine. I've attached a patch for this too (it'll be useful for anyone using a controller).
 

Attachments

  • 0001-dinput-Add-SDL-driver.txt
    73.6 KB · Views: 217
  • 0002-winebus-Use-the-real-PID-VID-on-controllers.txt
    2.2 KB · Views: 276
Last edited:
Maybe I'm missing it in the first post, but Is it possible to add directions on how to get this game to run in steam? (even perhaps if it requires adding separately, or perhaps manipulating the WINEPREFIX proton uses to install it in?)

Thanks in advance
 
Maybe I'm missing it in the first post, but Is it possible to add directions on how to get this game to run in steam? (even perhaps if it requires adding separately, or perhaps manipulating the WINEPREFIX proton uses to install it in?)

Thanks in advance

You can use the binaries (and instructions) here:
https://github.com/redmcg/wine/releases/tag/ED_Proton_3.16-4_Beta

It's a version of Proton compiled by me. Or you can compile from source.

https://www.protondb.com/app/359320 is a good resource for seeing what other people have done (along with their distro and hardware).
 
I've been looking in to dinput (and xinput) as I had issues with my controller under Wine (but it worked fine with Proton). So two things you could try are:
1. Change the axis mapping for your throttle via the registry (see the second entry under DirectInput: https://wiki.winehq.org/Useful_Registry_Keys); or
2. Try the SDL driver (patch for this is attached)

The SDL driver is lifted straight from Proton. After applying the patch, if you run 'wine64 control joy.cpl'; you should see an additional entry for the sdl driver (you may need to disable any other driver for the same device for it to work in ED). The SDL code has support for the Warthog throttle - but I didn't see anything for the t16000m (so it may end up with the same mapping as the 'event' driver).

The other change that Proton had (which was more relevant to my controller problem) was that it added HID entries with genuine VID and PID where as Wine masquerades your device as an XBOX controller (presumable because the XBOX controller has greater game support). But it seems Elite Dangerous iterates the devices in dinput and will only defer to xinput if you have an entry with the same VID and PID. Which is why it worked in Proton but not under Wine. I've attached a patch for this too (it'll be useful for anyone using a controller).

Thanks for those patches. Applied and wine built. Couple parts of the patches didn't go through but it was just minor differences between whatever source trees we're using and didn't take long to manually fix that.

Anyway - rebuilt wine 3.20-staging +sdl patches and tested with an existing prefix - alas no difference in outcome. So I tried creating a new prefix and hey presto it all works fine now. ED running in my debian testing boot and throttle is being recognised :)

The trick to building on debian is to apt-get install the :amd64 -dev packages and build the 64bit wine, then apt-get install the :i386 versions of those -dev packages and build the 32-bit wine. Then make install the 64 then 32-bit wine binaries, which I bung in to /opt/wine and set my PATH to suit. Works a treat.


A few of the -dev packages required to build wine don't co-exist as 64 and 32 bit versions on Debian, which was the cause of all the bother I had a week or three ago.

When I get the time I'll write a wee post in here with a detailed build procedure for Debian Testing.
 
I've been noticing a hefty performance deficit in the beta vs windows beta performance. Live on Linux is fine (around 10% loss or 140-150 fps once shaders load), but in the beta sitting in a station it's struggling to maintain 100 fps and dipping below that in most cases, when on the windows side beta there's barely a difference to windows live performance (usually 170 fps sitting in station).

Also I've noticed a bit of an oddity, one station Iben Hub in Iota Hydri has horrible frame drops on Linux in the beta with 40 fps on a 1070 at 1080p. On windows beta it's no different to any other station.

Some example pictures below:

1. Jameson memorial, decent utilisation & gpu power usage:

qRh8naK.png

2. Iben hub, utilisation is high but power is low. GPU is on max performance.

BYPlCUX.png


IrlJCOm.png

3. Windows Iben hub, literally double performance.

5Ds7Aos.png
 
Last edited:
Well, I've been trying to get Elite Dangerous to work on Linux Using Steam Play, and I finally succeeded using a special proton version made for ED, However when I try to run horizons, when it gets to the planet generation phase, it crashes.

I'm using Debian Stable 9.6 and I have probably older Nvidia Drivers installed, the 390.87 version
 
Well, I've been trying to get Elite Dangerous to work on Linux Using Steam Play, and I finally succeeded using a special proton version made for ED, However when I try to run horizons, when it gets to the planet generation phase, it crashes.

I'm using Debian Stable 9.6 and I have probably older Nvidia Drivers installed, the 390.87 version

Use latest nvidia drivers if you can, recommended driver version for DXVK: 396.54 or later.

https://github.com/doitsujin/dxvk/wiki/Driver-support
 
Got it set up yesterday with this the only change I made after testing it for a bit as this video states [video=youtube;jG7TUOXZhng]https://www.youtube.com/watch?v=jG7TUOXZhng[/video]
-- to fix the controls (keyboard - controller) was i changed the wine version. To tkg-3.19-x86_64 left everything else as is. Works great no big issues as of yet i had a few matchmaking bubs but i kinda blame my internet for that since i had them on windows 10 as well. by the way i'm using:
Operating System: KDE neon 5.14
KDE Plasma Version: 5.14.3
Qt Version: 5.11.2
KDE Frameworks Version: 5.52.0
Kernel Version: 4.15.0-39-generic

And i dropped back to my original GTX980 as in other stuff i was having issues before. the 1080 will sit on the shelf tell i can debug a bit.

An just in case your wondering why i'm on Linux for gaming now, Windows decided to in the last update delete it's %AppData% folder which is the location of the start menu win10 control panel proper display resolutions, search in the normal file explorer... just a ton of stuff an this was on a fresh format an install. an after a reinstall after that it happened again so as before windows is dead to me. Long live linux an macOS.
 
Back
Top Bottom