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

I'm not sure if this is an ED thing or a linux/wine thing. I have had other problems with rings in the wrong place or not scanable in the past in different positions. But this one if very visible. Is this an error or am I not doing something to scan it correctly. When I get close enough to the ring for it to succesfully hit the ring i'm out of range of the planet and can't fire. Do I need max scan percentage or something or is this an error or some relic from when you could increase scan range somehow? Notice the distance of the supposed rings. It should be much closer to the planet. I think the rings and scanner use physical data and not a separate invisible location detection for the proper position of the rings. So if the graphics are off the ring can't be scanned.Or is this the correct position of the rings?!

The ring should be within the position of the middle picture within the orange circle if I'm not mistaken.

jRJDt7p.jpg

uoHq8Xy.jpg

VnxgJET.png
 
Last edited:
Right I just thought I'd put this small warning here.

Distant Worlds 2 launches in a few hours, while this game runs very well on Linux I'd advise in order to prevent any slim possibility of technical issues having an effect on instances (as mentioned previously) it's probably best everyone in this thread taking part in DW2 does so on Windows for the meantime.

Not that I've seen any myself, just to be safe it's probably best practice. Just keep in mind everything on the Linux side i.e. Wine/DXVK/Vulkan drivers etc are still sort of a WIP and when there's 1000's of CMDR's it's probably not best to chance it.
 
I've created a squadron for those without one that run ED on Linux. If interested look for squadron id LNUX. Sorry for the spam, but I thought it might be interesting to raise awareness in-game.
 
Last edited:
Slightly off topic but what is distant worlds 2? I'm not sure I understand fully the point.

Project by players to map distant starsystems from the bubble.

Regarsing Linux: I am planning to build a Linux computer for gaming as it has progressed enough to justify buying optimized hardware for it. My friend already did it and it works amazingly. ED can be played according to some site that rates from bronze to platinum. But I am more concerned about other things.

So for you experienced pinguin guys, are there drivers for HOTAS, pedals etc. for the X52 Pro? If so, how do they work? Good/bad and do they require sepecial confoguration? Enlighten me! :)
 
For what it's worth, the ability to comfortably run on Linux might actually be the thing that gets me to log back in to Elite. It's the only thing on my Windows disk, and given that I have to have my main Linux installation running as much of the time as possible (for work reasons too in-depth to go into here), casually firing up Elite whenever I fancy it isn't really practical.

Same situation here. Most of my steam library actually runs native Linux, nowadays all indie and many AAA games support it out of the box (game engines like Unity or UE4 help a lot, i admit). I only reboot to poor old windows so i can play Elite. I suppose that also messes up statistics on how many people actually run Linux as their main platform...
 
I did the DW2 European launch on Linux and had no more or less problems than my mates.

I would strongly discourage doing that, Ed Lewis commented this thread before saying there could 'possibly' be technical issues between Linux & Windows clients: https://forums.frontier.co.uk/showt...OT-OFFICIALLY-SUPPORTED?p=7154409#post7154409

While I haven't seen these in smaller groups keep in mind Distant Worlds is with thousands of players and as last night showed isn't stable at the best of times. Best not exacerbate that by introducing something that's unsupported to the mix.

At the end of day I assume the goal of the efforts here by Eagleboy, RedMcG and others is to have a playable experience while at the same without being a hindrance to other players or an annoyance to FDev's networking teams.

That's why best to still treat the game through Wine as what the title says - [h=1]
[EXPERIMENTAL, NOT OFFICIALLY SUPPORTED]
[/h]
Play it as such by not playing in ultra large meetups.
 
I would strongly discourage doing that, Ed Lewis commented this thread before saying there could 'possibly' be technical issues between Linux & Windows clients: https://forums.frontier.co.uk/showt...OT-OFFICIALLY-SUPPORTED?p=7154409#post7154409 While I haven't seen these in smaller groups keep in mind Distant Worlds is with thousands of players and as last night showed isn't stable at the best of times. Best not exacerbate that by introducing something that's unsupported to the mix.At the end of day I assume the goal of the efforts here by Eagleboy, RedMcG and others is to have a playable experience while at the same without being a hindrance to other players or an annoyance to FDev's networking teams.That's why best to still treat the game through Wine as what the title says - [EXPERIMENTAL, NOT OFFICIALLY SUPPORTED]

Play it as such by not playing in ultra large meetups.
I see no proof of these so-called technical incompatibilities, so I'll plainly disregard this request. Ed Lewis doesn't see the game code either, his title is "community manager", so where is he pulling this b******* from, and why?

Give us actual proof instead of blowing smoke due to being afraid and under-educated for anything not Windows.
 
Last edited:
  • Like (+1)
Reactions: EUS
I would strongly discourage doing that, Ed Lewis commented this thread before saying there could 'possibly' be technical issues between Linux & Windows clients: https://forums.frontier.co.uk/showt...OT-OFFICIALLY-SUPPORTED?p=7154409#post7154409

While I haven't seen these in smaller groups keep in mind Distant Worlds is with thousands of players and as last night showed isn't stable at the best of times. Best not exacerbate that by introducing something that's unsupported to the mix.

At the end of day I assume the goal of the efforts here by Eagleboy, RedMcG and others is to have a playable experience while at the same without being a hindrance to other players or an annoyance to FDev's networking teams.

That's why best to still treat the game through Wine as what the title says - [h=1]
[EXPERIMENTAL, NOT OFFICIALLY SUPPORTED]
[/h]
Play it as such by not playing in ultra large meetups.

While I respect where you come from with that advice, I will point out why I think that's an excess of caution. First, player instances are maxed at around 12-13 players. The problems yesterday were due to server overloading, which is well known, and caused by the 99.9% windows players, not the few of us in Linux. Second, unless there's a clear difference in behavior (due to bugs in wine) between the network layers of linux/windows, I cannot imagine why that could translate into adverse effects for other players or the servers.

That said, if bad effects were clearly identified I would consider going solo for the sake of the other players; but as long as Frontier does not persecute us or advices against doing whatever we can with wine, I will keep testing. I understand I'm unsupported and I wouldn't report any problems that couldn't be duplicated in windows.

[edit: my previous post reporting success was not in defiance of the recomendation, but just as an observation that I didn't experience ill effects particular to Linux]
 
Last edited:
I found another problem. It's with alt tabbing. I have no idea where this one lies as a problem. If you alt tab too much eventually your screen retains the image of your desktop and won't go back in game. It's in game but you can't see it. You can hear the ui sounds though as you move the mouse around.

Also:

1: Alt tabbing messes up the mouse. This is seen as a mouse move arrow in flight that can't move as far as it should. This can temporarily be resolve by either:
a. Alt tabbing without releasing the tab until it rotates back to the game screen. (Assuming you have a program showing you which window is highlighting while alt tabbing.)
b. Similarly remembering how many windows, like browsers are up, and alt tabbing without releasing alt until back on the game program.

I always have mozilla the launcher and the game up. So I hold alt and tap tab 3 times to resolve this.

2. Preparing planet generation is very slow on startup. Makes it hard to restart to deal with other issues like the first one I mentioned.

3. Alt tabbing an also make the alt button stick stopping some keybinds from working. This can be resolved by tapping alt once in most cases.

4. Opening Gal map can shut down the user interface. This can be resolved by opening and closing it. Not sure if this is a glitch or a problem with some sort of keybind cross.

5. Sometimes when scanning planet it's acts like it's been scanned and you cannot see where you have and haven't already dropped probes. I know of no way around this besides using careful patterns and remembering where you land them. I already use fairly efficient patterns. So, it helps to get around this a little.

I forgot the other things. Adding to list as I think of things.
 
Last edited:
At the end of day I assume the goal of the efforts here by Eagleboy, RedMcG and others is to have a playable experience while at the same without being a hindrance to other players or an annoyance to FDev's networking teams.

100%. But unfortunately the communication from Frontier doesn't provide any clear instruction.

My read was that the reports were not yet confirmed but still being investigated - and since we haven't heard anything back then perhaps there was nothing there? If there was I would have expected a more explicit post (although perhaps the investigation continues).

On the other hand - if nothing was found - I wouldn't expect to see an endorsement post from Frontier (as they are under no obligation to provide it).

But running under Linux is still new (and therefore experimental), thus problems are still being found. So for your own experience (and for your commanders safety) then running in Windows (if that is an option) is pretty sensible. If not - then running in Solo or a group that endorses Linux is also a good option. I personally play in Solo under Linux (although I must admit I don't get in the pilot seat all that often).

However - until Frontier confirm that there is an issue, or provide explicit instruction not to play in Open, then I'd say the choice is up to the individual commander. But if someone does run in to a confirmed issue that impacts other users in their instance, then please do report it here (not only to report the issue so it can be resolved but to help inform others).

Here's Ed's quote for easy reference:
Hey everyone!

We've had reports that the above "experiments" are causing some technical problems in-game. The issues aren't just happening for those playing Elite Dangerous on Linux, but also for players who end up in the same instance while playing on PC.

Just a reminder that Linux is not an officially supported platform, and we are currently investigating these issues. We wanted to let you know so you don't too much time on something that we can not support, and that could potentially change.

Thanks,

Ed
 
While I respect where you come from with that advice, I will point out why I think that's an excess of caution. First, player instances are maxed at around 12-13 players. The problems yesterday were due to server overloading, which is well known, and caused by the 99.9% windows players, not the few of us in Linux. Second, unless there's a clear difference in behavior (due to bugs in wine) between the network layers of linux/windows, I cannot imagine why that could translate into adverse effects for other players or the servers.

That said, if bad effects were clearly identified I would consider going solo for the sake of the other players; but as long as Frontier does not persecute us or advices against doing whatever we can with wine, I will keep testing. I understand I'm unsupported and I wouldn't report any problems that couldn't be duplicated in windows.

[edit: my previous post reporting success was not in defiance of the recomendation, but just as an observation that I didn't experience ill effects particular to Linux]

Wasn't saying Linux users caused the server crash, however due to the way this games peer to peer connections work I'd say not to 'rock the boat' particularly in the early stages of a huge expedition like this. Small expeditions in my opinion are fine however when you're talking about multiple instances of 30-50+ players in each (especially those streamer instances where everyone is trying to get in to hump ObsidianAnt's leg) it's probably not a great idea to add to an already messy experience Linux as a factor.

Back to the driver terrain bug topic, a new driver launched today but unsure whether it fixes anything. Issue is as my main account is on DW2 I can't test, I got a secondary account but it's in Colonia and the engineer bases there are not affected by the terrain issue (different design).

If anyone can test the new driver (415.27) take a screenshot of the Laksak base in the bubble with dxvk hud on and report back it would be great, alternatively a specific location in the Colonia region where the bug occurs that I can test would be great too.

This bug does affect Windows but on older generations of hardware than Maxwell. Looking at the PC bug reports section though there appears to be little movement on this bug other than recommending people use older drivers.
 
I found another problem. It's with alt tabbing. I have no idea where this one lies as a problem. If you alt tab too much eventually your screen retains the image of your desktop and won't go back in game. It's in game but you can't see it. You can hear the ui sounds though as you move the mouse around.

Also:

1: Alt tabbing messes up the mouse. This is seen as a mouse move arrow in flight that can't move as far as it should. This can temporarily be resolve by either:
a. Alt tabbing without releasing the tab until it rotates back to the game screen. (Assuming you have a program showing you which window is highlighting while alt tabbing.)
b. Similarly remembering how many windows, like browsers are up, and alt tabbing without releasing alt until back on the game program.

I always have mozilla the launcher and the game up. So I hold alt and tap tab 3 times to resolve this.

2. Preparing planet generation is very slow on startup. Makes it hard to restart to deal with other issues like the first one I mentioned.

3. Alt tabbing an also make the alt button stick stopping some keybinds from working. This can be resolved by tapping alt once in most cases.

4. Opening Gal map can shut down the user interface. This can be resolved by opening and closing it. Not sure if this is a glitch or a problem with some sort of keybind cross.

5. Sometimes when scanning planet it's acts like it's been scanned and you cannot see where you have and haven't already dropped probes. I know of no way around this besides using careful patterns and remembering where you land them. I already use fairly efficient patterns. So, it helps to get around this a little.

I forgot the other things. Adding to list as I think of things.

I've noticed all these things with my installation too. I usually get about an hour of good smooth running before it starts to go a bit weird. Switching apps definitely can do funny things.
 
Wasn't saying Linux users caused the server crash, however due to the way this games peer to peer connections work I'd say not to 'rock the boat' particularly in the early stages of a huge expedition like this. Small expeditions in my opinion are fine however when you're talking about multiple instances of 30-50+ players in each (especially those streamer instances where everyone is trying to get in to hump ObsidianAnt's leg) it's probably not a great idea to add to an already messy experience Linux as a factor.

I see now a quoted post that there indeed was suspicion of issues caused by linux. I had missed that, I thought we were speaking purely of hypotheticals.
 
5. Sometimes when scanning planet it's acts like it's been scanned and you cannot see where you have and haven't already dropped probes. I know of no way around this besides using careful patterns and remembering where you land them. I already use fairly efficient patterns. So, it helps to get around this a little.

It does happen in Windows too, I hope it is going to be fixed in the next update.
Try logging out and in again to see it unmapped.
 
Here is another one. How long does the new scanning locations take in windows. Is it supposed to be instant or should it have a spinning wheel thing and take random amounts of time in windows also. I also get a message constantly saying, "Adaptive Zoom Failed." Not sure if this is a glitch or my mouse wheel being funny.
 
Here is another one. How long does the new scanning locations take in windows. Is it supposed to be instant or should it have a spinning wheel thing and take random amounts of time in windows also. I also get a message constantly saying, "Adaptive Zoom Failed." Not sure if this is a glitch or my mouse wheel being funny.

It's supposed to be like watching paint dry, exactly the same on Windows along with your other issues.
 
Here is another one. How long does the new scanning locations take in windows. Is it supposed to be instant or should it have a spinning wheel thing and take random amounts of time in windows also. I also get a message constantly saying, "Adaptive Zoom Failed." Not sure if this is a glitch or my mouse wheel being funny.

I run ED on both Windows and Linux (because I'm making Captain's Log run natively under both platforms and need to test all alterations under both), and the game running under Linux is behaving exactly the same way that it does under Windows, including such things as GameFreezePause, taking a long time to scan and show PoI's, and every other foible existing at the moment.

Also, absolutely no offense meant nor intended to Flyingspaghetti; running ED under Linux can't be causing networking issues - the netcode is built into the game client, is the same netcode running under both platforms, is responsible for comms to ED's back-end servers as well as P2P traffic, and if running under Linux/WINE was causing issues, that would become immediately apparent in terms of communication with the back-end servers, in my opinion. :) Of course the real difference is between the Windows networking stack and the Linux networking stack, and personally I'm inclined to trust the Linux networking stack way more than I would Windows ;)
 
I've been tinkering with it today and still can't find a proper fix for Steam Controller issues, tried several methods listed on this thread (involving joy.cpl and so on) but it's not responding properly. If any of you have any pointers or tips I should try, let me know

It took me over a month, but I finally got around to plugging in my Steam Controller and trying it out with Elite Dangerous. For me it worked fine - but I'm using kernel version 4.15. I know a kernel driver for the Steam Controller (hid-steam) was introduced in kernel version 4.18. This introduced issues with Steam.

It looks like a fix was accepted for 4.20. So if you're using 4.18 or 4.19 then that could be the problem. The workaround (if you can't upgrade to 4.20) looks to be to blacklist the hid-steam module (or manually compile the steam-controller fix).

Edit: Just read that the fix was back-ported to 4.19.6.
 
Last edited:
Back
Top Bottom