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

[Peppermint Barnstorm]

@Peppermint Barnstorm
Thx for your answer.
I can only set Buttons in Game, which I have define in Steam. For example I can set the X Axis, because the Gamepad in Steam has a X Axis. But I can't set the Z Axis for example for throttle, because the Steam Gamepad has no Z Axis.

Can you look in Steam is Joystick correct identifed?

My own stick is correctly identified in steam as a FFB Sidewinder 2. However you should know although I use the steam install I do not use steam to launch the game.

I run 2 older accounts that don't require a steam login so I use Wine 6.0 Stable instead of Proton. I don't know how old your account is but if you can run the launcher with wine instead of steam then perhaps that might help?

 

[Athan]

As for ED:MC, follow the "Running from source" instructions as that's really the easiest way to get it running -- sudo apt-get install python-iniparse python-requests python-tk git followed by git clone https://github.com/Marginal/EDMarketConnector.git ~/.edmc or whereever you want to install it).

Then, manually set up the journal directory:

mkdir -p ~/.steam/steam/steamapps/compatdata/359320/pfx/drive_c/users/steamuser/Saved\ Games/Frontier\ Developments/Elite\ Dangerous

Add a link to your desktop that runs ~/.edmc/EDMarketConnector.py and you're good. (Check in the ED:MC configuration that it's pointing at the journal directory.)

I raised an issue with the author of ED:MC that the "Running from source" / directory setup part should really be a part of ED:MC's Installation & Setup documentation for Linux, but that hasn't happened yet.

It has now . Note that I didn't include the instructions for installing extra python modules using apt because you do want to be letting the

pip install -r requirements.txt

command take care of that. It ensures you're using the versions of modules that we've tested with.

The "Home" wiki page now points at "Installation & Setup", which in turn points at "Running from source" for non-Windows, and then includes direction on getting the Journals location set.

I am wondering if the 'mkdir' step is really necessary. I'd have thought that the Game would be creating that when you first run it. EDMC itself should now (or soon when I put out 4.2.1) cope with the location not yet existing.

 

[xolophreny]

On the Odyssey alpha:
Had an issue where the stock launcher completely downloaded the alpha and got stuck at finishing the download. By fiddling around with min-ed-launcher I saw that there's some issues at play - firstly, the launcher expects the alpha to be at Products/PUBLIC_TEST_SERVER_64 but for some reason downloads it into Products/PUBLIC_TEST_SERVER_OD, so had to rename that. Also, in there there was no VersionInfo.txt, only VersionInfo.txt.new or something like that, and all the .txt, .xml and .dll files lacked execute permissions that exist for similar files in other products. After renaming the VersionInfo file and adding permissions, min-ed-launcher correctly identified the alpha and was even able to launch it if I mangled Horizon's VersionInto.txt so it wouldn't recognise Horizons and launch the next product being the alpha. Somewhen during that the stock launcher died and I'm yet to resurrect that, and the alpha needs updating, so there's that.

I wonder if min-ed-launcher could at some point get a way to interactively choose a product to launch...
It did, yay!

 

[Genar-Hofoen]

On the Odyssey alpha:
Had an issue where the stock launcher completely downloaded the alpha and got stuck at finishing the download. By fiddling around with min-ed-launcher I saw that there's some issues at play - firstly, the launcher expects the alpha to be at Products/PUBLIC_TEST_SERVER_64 but for some reason downloads it into Products/PUBLIC_TEST_SERVER_OD, so had to rename that. Also, in there there was no VersionInfo.txt, only VersionInfo.txt.new or something like that, and all the .txt, .xml and .dll files lacked execute permissions that exist for similar files in other products. After renaming the VersionInfo file and adding permissions, min-ed-launcher correctly identified the alpha and was even able to launch it if I mangled Horizon's VersionInto.txt so it wouldn't recognise Horizons and launch the next product being the alpha. Somewhen during that the stock launcher died and I'm yet to resurrect that, and the alpha needs updating, so there's that.

I wonder if min-ed-launcher could at some point get a way to interactively choose a product to launch...

I had that exact same problem too. My solution was different - I copied the files that were downloaded over to a Windows VM and ran the launcher on that, which then completed the Odyssey download. Then copied it all back to linux and hey presto it worked.

How is the performance of Odyssey under WINE for you? It's pretty bad for me.

 

[Darth Ender]

hopefully that poor performance is something only seen in the testing versions. Because not being able to run the game in wine (proton) is a non-starter for me. I'm not dual booting for elite.

 

[Genar-Hofoen]

hopefully that poor performance is something only seen in the testing versions. Because not being able to run the game in wine (proton) is a non-starter for me. I'm not dual booting for elite.

I'm guessing the alpha not being optimized is the cause of the poor performance. It appears to be something to do with texture loading. I had to decrease the graphics quality settings a tad in order to maintain something around 20-30fps under WINE. It still varies wildly and it does seem to be due to loading graphics. Or something. I don't know!

I'm currently trying to build a new prefix via Lutris and using an Esync runner to see if that makes any difference. Usually, performance under WINE is the same (if not a bit improved IMO) as running on native Windows, however, I've ran the Odyssey alpha on both and at the moment Windows is currently winning on performance.

 

[Genar-Hofoen]

By the way, here's a pro-tip, in case it hasn't already been mentioned...

If you've been using the /steam switch to prevent the ED Launcher's UI from its usual UI widget appearance/disappearance act, you won't need to after running this:

wine reg add "HKCU\\SOFTWARE\\Microsoft\\Avalon.Graphics" /v DisableHWAcceleration /t REG_DWORD /d 1 /f

The reason the Launcher's UI elements do that is because the launcher is a WPF application, which by default is 3D accelerated. WINE (and Proton) has historically had a problem with that. The Registry key entry above disables 3D acceleration for WPF applications.

tl;dr No more need for the /steam switch.

 

[Dummytarget]

By the way, here's a pro-tip, in case it hasn't already been mentioned...

If you've been using the /steam switch to prevent the ED Launcher's UI from its usual UI widget appearance/disappearance act, you won't need to after running this:

wine reg add "HKCU\\SOFTWARE\\Microsoft\\Avalon.Graphics" /v DisableHWAcceleration /t REG_DWORD /d 1 /f

The reason the Launcher's UI elements do that is because the launcher is a WPF application, which by default is 3D accelerated. WINE (and Proton) has historically had a problem with that. The Registry key entry above disables 3D acceleration for WPF applications.

tl;dr No more need for the /steam switch.

Works for me, thanks for the tip!

 

[xolophreny]

How is the performance of Odyssey under WINE for you? It's pretty bad for me.

Yup, rather depressing performance. Luckily, this is probably not related to wine at all since several friends of mine running it on windows report exactly the same issues, and the issue tracker for the alpha does that as well. Hm, alright disregard that, since I don't have a real way to test performance of Wine vs native, I'll just hope that wine isn't the problem as opposed to saying that it probably isn't >.>

On top of that I'm playing on a laptop that simply has an underpowered GPU for its display res, so, yay for low-spec gaming ^-^
Doesn't meet the alpha's minimum reqs for 720p, only 2GB of VRAM, and yet squeezes out some 15fps on foot in 1080p, on 0.5 supersampling. Incredible. Hoping for at least freeze-less 25fps on release. Maybe even 30fps if we'll be able to disable shadows, which is suddenly not a thing anymore xd

 

[Genar-Hofoen]

Yup, rather depressing performance. Luckily, this is probably not related to wine at all since several friends of mine running it on windows report exactly the same issues, and the issue tracker for the alpha does that as well. Hm, alright disregard that, since I don't have a real way to test performance of Wine vs native, I'll just hope that wine isn't the problem as opposed to saying that it probably isn't >.>

On top of that I'm playing on a laptop that simply has an underpowered GPU for its display res, so, yay for low-spec gaming ^-^
Doesn't meet the alpha's minimum reqs for 720p, only 2GB of VRAM, and yet squeezes out some 15fps on foot in 1080p, on 0.5 supersampling. Incredible. Hoping for at least freeze-less 25fps on release. Maybe even 30fps if we'll be able to disable shadows, which is suddenly not a thing anymore xd

I'm running an RTX 2070 Super. If I start the game in WINE and in a space station, on Ultra I get a respectable 45fps and the card is working at 40-odd %.

As soon as I do something which invokes planet display like e.g. book a space taxi, the FPS plummets when displaying the Apex system map - some planetary body textures take an age to load in. Even exiting that Apex system map, and my GPU is now running at 100% no matter what I do.

So it's definitely planet textures (or definitely related to planets) which bring the alpha FPS down drastically.

 

[Darth Ender]

So, I can't get my stupid starter guy off the starter walking area because my starter ship spawned in a system 12ly away from where I am and the apex shuttles dont seem to go anywhere outside of the system (every system says out of range)

So, needless to say, i'm over testing it. I was averaging about 50fps with dips into the 30's with the last version of proton that worked with .net4 and an amd 5700xt in ultra graphics (1080p).

The walking around graphics made me have deja vu with playing X4. Only slower.

edit: apparently the being stuck in-system is part of phase 1. So i guess i'll be waiting until phase 2-3 to check this out any further, when they allow us access to space ships.

 

[xolophreny]

Hmpf, updating to Phase 2 now introduced crashing on 0% Preparing Planetary Generation phase, with Proton-5.0-10 and 5.9-GE

Any pointers on what might be causing that? Seems like the reports on Frontier's issue tracker are old and/or marked as fixed

 

[A_D]

Mesa regression, assuming AMD: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4533

 

[xolophreny]

Mesa regression, assuming AMD: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4533

Ohh, right, that seems to be it, thank you! Indeed using freshly-updated mesa 21.0.2 with Radeon RX 640, had minor issues with other games since the update but didn't realise that this could also be linked to it

 

[Darth Ender]

So, new launcher pushed it seems. Requires dotnet 4.5.2 and my old proton setup that was working fine (5.10) wont run dotnet 4.5.2

Has the non-dotnet mono installation thing gotten to work with multiple logins yet? Or is that still stuck with 1? I'm trying other combinations of proton with dotnet 4.5.2 but haven't been successful yet.

 

[A_D]

Allegedly .net45 works on latest wine, perhaps try that? AFAIK the launcher still gets upset when you click links on wine-mono (also, the ED fixed wine-mono isnt needed, the latest wine-mono should just work now)

 

[Darth Ender]

Allegedly .net45 works on latest wine, perhaps try that? AFAIK the launcher still gets upset when you click links on wine-mono (also, the ED fixed wine-mono isnt needed, the latest wine-mono should just work now)

the launcher is requiring .net452 which was saying that it was giving an error box during install that said it was known to be broken with current proton (4.6).

Whether using the fixed wine-mono or the standard wine-mono, if I can't login with a non-steam account, then it's effectively useless.

I dont get why there aren't just some cli or config file options to set your username and password (or just get prompted for the password on startup). But then again, i dont get why the launcher is as dumb as it is to begin with. Lots of dependencies and nonsense for something that shouldn't require any.

Are you saying the current client is working fine for you with dotnet 4.5.0?

 

[A_D]

I have not tested it, no.

 

[A_D]

That said the minimal ED launcher is working towards having standalone support (and updating support, I believe), so that may become a solution for you.

 

[Darth Ender]

Ok, So, I successfully engaged the login/logout features using the stock mono from proton experimental

I did this a little hackish way though. I had a user.cfg from the launcher when i was using an older version of proton and everything still worked. The user.cfg has your current login email address and a hashed password (which is the same as the hashed machine id it also has) As opposed to the empty values the steam user.cfg gets.

Replacing the user.cfg in the launcher folder (under local settings / application data / etc), caused the launcher to load with my email address up in the top right showing (but it was still basically logged in as my steam account and would run the game as such.

But since the email address is up in the top right now, i can click it and select "log out" and go thru the normal login process just perfectly fine. Now, the launcher is associated with my direct frontier account like i want.

So there is a semi-functional workaround ... so long as you have a user.cfg with login credentials so that you can get that email address in the top right to login/logout .

The "Options" menu logout button is still non-functional . You need the email address up in the window border.