Ashes of Creation on Linux/Proton Compatibility Layer support

Hello Glorious Ashes Dev Team and Ashes Community,

I recognize that Linux support as been spoken on a few times in the past, but if I and other's like me don't push for it, I fear it may be lost to time and the black hole of statistics I don't believe accurately reflect the number of individuals that would utilize it.

With the adoption of Unreal Engine 5 I wonder if now is the time to ask for a definitive answer from Steven on the topic of Linux support. Either directly via Native Support (Please for the Love of God Steven I can't keep playing Ancient MMO's like WURM.) or via the use of Proton Compatibility Layer. Now I know there are some out there who will say "But Roman, don't you need to install Steam in order to use Proton?"

Well, as for Proton, you do not need Steam to utilize it, it is open source and stand-alone.

With all of that said, I wonder if those more knowledgeable than I could elaborate if due to the transition to UE5 it may actually be the time to look heavily into supporting Linux Natively.

If any Devs read this, could the challenges of developing for Linux as well be elaborated on?

And for those in the community reading, if you are a Linux user that needs a new MMO to play and doesn't want to go back to Windows to play one, or a Windows user trying desperately to escape Windows and MAC hegemony, respond to this post to show support!

Find more posts tagged with

Staff

Comments

ariatras

Noaani wrote: »

ariatras wrote: »

Additionally, the argument that Linux tools make cheating easier overlooks the fact that the complexity and variety of Linux environments add significant challenges for cheat developers.

I thought we already went over this.

You are once again saying that when I am saying that it is easier to hide cheating on Linux (again, Linux is designed to put the user first, not the application), your argument is that you need a higher level of technical knowledge to do this.

This is literally that same "cheating is ok if youre smart enough" thing.

If that isn't your position, you need to stop saying it.

I actually fully agree with you that Linux is harder to use (that is why it is still so unpopular). However, it is also easier for someone with the knowledge to hide neferious activity with Linux than with Windows.

Let's cut through the confusion here and set the record straight.You're still misunderstanding my point. I never said, nor implied, that "cheating is okay if you're smart enough." That’s a complete misrepresentation of what I’m arguing.

Here’s the reality: Linux doesn’t inherently make it easier to hide cheating. The fact that Linux gives users more control over their system doesn’t mean it’s a cheater’s playground. It means that Linux is designed with flexibility and transparency in mind—principles that apply to all users, not just those with malicious intent.
But here’s the kicker: that same transparency and control also make it easier to detect and counteract malicious behavior.Let’s get technical for a moment. On Linux, sure, you can manipulate processes, modify permissions, or use advanced tools to configure your environment. But that doesn’t mean anti-cheat systems are helpless. In fact, modern anti-cheat solutions, especially those that work cross-platform, are designed to detect exactly these kinds of manipulations. They monitor system integrity, process behavior, and the interaction between the game and the operating system. These systems aren’t fooled just because a user has more control over their OS. They’re built to adapt and detect cheating regardless of how much knowledge the cheater has.You keep coming back to this idea that Linux somehow offers superior hiding spots for cheaters because of its user-first design. But here’s the truth: Windows also provides plenty of ways to hide malicious activity. From modifying the registry to running unauthorized processes in the background, it’s not like Windows is some impenetrable fortress where cheats are impossible to hide. The key difference is how anti-cheat systems are designed to operate in these environments. They don’t rely on the OS being locked down; they rely on understanding what normal and abnormal behavior looks like.So let’s stop with the strawman arguments. The tools that make Linux powerful and flexible don’t inherently make it a better platform for hiding cheats. They just make it different. Cheating isn’t easier on Linux—just different in its approach. And in many cases, the open nature of Linux can work against cheaters, making it easier for anti-cheat systems to catch them. If your position is that Linux gives cheaters a unique advantage, you’re ignoring the fact that the same flexibility that might help a cheater is also the very thing that helps to expose them.So no, I’m not saying “cheating is okay if you’re smart enough.” What I’m saying is that it’s not any easier to cheat on Linux than it is on Windows, and trying to paint it that way is a gross oversimplification that doesn’t hold up under scrutiny.

Zehlan

EAC games that work in Wine/Proton use the LINUX NATIVE EAC client, which communicates with a Linux EAC binary that each game that enables support ships, alongside their Windows EAC binary. The Steam Proton EasyAntiCheat Runtime is also required. This runtime allows the NATIVE Linux EAC client (which again, is 100% userspace only and has no kernel level access) to communicate with the Windows userspace EAC binary, to allow for a less-secure but still better than nothing EAC functionality for Windows games running in Wine/Proton.
Just wanting to fan the flames lol but in all honesty I tired of cheaters ruining games! If letting Linux users play increases the chance to cheat by even 1% I say ban the entire OS from ever accessing the game! Run a dual boot. QQ

ariatras

Zehlan wrote: »

EAC games that work in Wine/Proton use the LINUX NATIVE EAC client, which communicates with a Linux EAC binary that each game that enables support ships, alongside their Windows EAC binary. The Steam Proton EasyAntiCheat Runtime is also required. This runtime allows the NATIVE Linux EAC client (which again, is 100% userspace only and has no kernel level access) to communicate with the Windows userspace EAC binary, to allow for a less-secure but still better than nothing EAC functionality for Windows games running in Wine/Proton.
Just wanting to fan the flames lol but in all honesty I tired of cheaters ruining games! If letting Linux users play increases the chance to cheat by even 1% I say ban the entire OS from ever accessing the game! Run a dual boot. QQ

The argument that allowing Linux users to play might increase the chance of cheating by "even 1%" is speculative at best. If that’s the standard, then why not ban any configuration that slightly increases risk? Should we ban older versions of Windows? Should we ban users who overclock their systems because it might give them an advantage? This kind of reasoning leads to a slippery slope where you’re punishing legitimate users to avoid a hypothetical problem.

Noaani

ariatras wrote: »

If that’s the standard, then why not ban any configuration that slightly increases risk?

They do, that is why I can't run the game on my VM.

Funkychicken

Good Day everyone. If you would like to know how to install the Launcher as it stands on the Alpha 2 Client, I have posted a video on how to do this here.

We have managed to sort this out for a number of Linux users using the Alpha 2 Client.

lemba

Funkychicken wrote: »

Good Day everyone. If you would like to know how to install the Launcher as it stands on the Alpha 2 Client, I have posted a video on how to do this here.

We have managed to sort this out for a number of Linux users using the Alpha 2 Client.

Because I'm on EndeavourOS I will try and install it without Flatpak, just plain Bottles... Thx for your preparation tips.

myonen

As an exclusive user of Linux I was about to drop $120 to be included in the next round of alpha testing, but unfortunately I can't give you my money until I can at least test it.

Funkychicken

I have been looking at the Launcher on Linux and I can now see this error as soon as I launch game:

ERROR|LoginViewModel.Crypt|Auto log in failed. Exception: Unknown error (0xc1000002).

I can repeat this process and it happens consistently. Although initial authentication is working on the Webview2 form and I have reinstalled EAC multiple times it seems to be the same issue.

EAC seems to be the main source of the problem on a lot of Linux wine systems with games. But this seems to be when it gets the login from the previous form and then tries to pass it to the URL, but it cannot authenticate.

I have noticed that installing additional dependencies such as IE API or winhttp or anything sometimes will break the bottle, even though you reset it back to how it was. Sometimes the client will load, but wont display on screen. Sometimes the client loads OK, but the form has no information in there and is just blank with no fields on there. Sometimes the application will not load at all and quits about 1 second after opening.

So what I have tried doing is re-deploying the bottle from the beginning. I have installed only webview2 from the dependencies (let the installer install visualC++2022) and I have not modified the urlmon.dll override or set the webview2 version to be Windows 7 - left it on Windows 8.1. Reinstalled the game.

Installed ierutil, winhttp. The Launcher worked ok up until this point. Installing wininet to the point where the Launcher runs, but nothing appears on screen. It seems that Wininet completely blows up the bottle and I need to delete it, start again and re-download everything. Uninstalling it does not seem to work so the only solution is a fresh start.

So now I have seen the main issues doing a bit of research.

Directx12 is needed by AOCClient.exe (the bootstrapper for the game)
Dotnet 4.72 is needed by AOCClient.exe to render the page.

One of the main problems is that Directx12 is not supported in a native wine environment. This is replaced by vkd3d on vulkan. One main workarounds is to install wine from source whilst including the vkd3d libraries so the directx12 side works. Then we are left with installing dotnet4.72 and left with WebView2 from a compiled wine install. I think I am going to need a bit of time to try all these but if someone has a wine 32/64 install and has vkd3d compiled with wine then it may be worth seeing if the AOCClient.exe works with this. (actually loads u the anti cheat window before loading the game).

merumeru

Thank you for the introduction to Bottles Funkychicken, managed to run the client and even got the splash screen which I assumed is from EAC, but getting stuck with Pending Service Connection Code:32 so I guess EAC is not running after all. I wonder whether it would be possible to somehow use the same native EAC Steam uses instead of the windows one. By the way, the mentioned error log, where does it come from, the client itself or the launcher?

supersteef

@Funkychicken out of curiosity, have you tried adding the the game to your Steam library and launching it from there? I'll admit, I don't know WHY this seems to work for so many things but EAC seems to play nicer with stuff launched via Steam than just through Lutris/Bottles.

Noaani

Noaani wrote: »

ariatras wrote: »

Additionally, the argument that Linux tools make cheating easier overlooks the fact that the complexity and variety of Linux environments add significant challenges for cheat developers.

I thought we already went over this.

You are once again saying that when I am saying that it is easier to hide cheating on Linux (again, Linux is designed to put the user first, not the application), your argument is that you need a higher level of technical knowledge to do this.

This is literally that same "cheating is ok if youre smart enough" thing.

If that isn't your position, you need to stop saying it.

I actually fully agree with you that Linux is harder to use (that is why it is still so unpopular). However, it is also easier for someone with the knowledge to hide neferious activity with Linux than with Windows.

Just going to reiterate this point that I made a while ago, and point out the whole situation with Apex Legends right now.

While trying to get a game running on Linux is fine (and I have no intention of posting in the thread to that end), actual developer support of Linux hinges in Linux developers creating a secure environment for the game where the user can't just supercede the protections in place. (edit to add; this is a secure environment from the perspective of the game developer, not the user - the game developer needs protection FROM the user).

Since this is what many people would consider "anti-Linux", I wouldn't be expecting it to happen any time soon. However, this is where work currently needs to be done in order to get actual game developer support on Linux.

Funkychicken

supersteef wrote: »

@Funkychicken out of curiosity, have you tried adding the the game to your Steam library and launching it from there? I'll admit, I don't know WHY this seems to work for so many things but EAC seems to play nicer with stuff launched via Steam than just through Lutris/Bottles.

Hello yes I have done this. I have added AOCClient.exe to steam and ran it from there with the options --proton --proton LauncherTetherPort=XXXXX with whatever number of udp port netstat is showing.

EAC doesnt play well in steam for me. I cant even install the application, but within Bottles it works first time.

I can get into the game by logging in with bottles and then executing AOCClient.exe from within Steam.

Funkychicken

Ok there are a few things here. Firstly thanks to @icedown for looking into this on this comment here

In terms of the setup. The installer was done with bottles and AOCClient added to steam. So there are 2 different applications launching the game. So why is this?

1) Intrepid Studios launcher is a login system using webview2. AoCCLient.exe is a bootstrap to run AOCClient-Win64-Shipping that executes the game (eventually) When you Launch the game, it jumps through these processes and then connects.

2) Running AOCCLient on Bottles invokes a Directx12 check, and does not pick up any of the dxvk drivers and therefore fails. However running this in steam works on the latest experimental drivers. Running AOCClient.exe on its own will give Error:10. This error is authentication has not been met. Meaning that on this session, AOCCLient.exe cannot see IntrepidStudiosLauncher.exe having been authenticated.

3) The Launcher, when Launching the game on linux, stalls for about 20 seconds and then comes back to Launch Game. There is an issue with the invokation of AOCClient.exe from the Launcher. So logging in with the Launcher authenticates you and then running the game on the same UDP session works.

f0rce91

Hi guys,

as an alternative solution to the one with bottles I created a YAML install file to install the Intrepid Launcher in Lutris. If somebody is interessted in it, it is downloadable here. This was my first time creating a YAML file so propably things are not realized with best practice, but in the end I was able to get the launcher up and running with it. This variant also requires the steam workaround to be able to start the client itself.
Thanks btw to @Funkychicken. Your videos helped me very much in finding all the things I have to configure.

If you have any feedback or suggestions for improvement, let me know.

ashvoller

So I am reading a great number of Linux preconceptions.

Linus Torvald works on the Kernel, not the OSes, as the lead project coordinator. Linux is an open source project that has many many developers. Kernel 6.10 had 1,918 different developers adding code just in that version along. (242 first time developers for this kernel version)

Red Hat, Fedora, Debian, Ubuntu, SUSE, Arch, ChromeOS, Android, and Gentoo based OS distributions all have major philosophical and software stack differences. (These are just some of the major distributions). Example: Gentoo builds everything* from source (*mostly everything, common exceptions being browsers)

Security considerations
Ubuntu and Debian using AppArmor
Android, Red Hat, Fedora, and SUSE using SELinux
Both are major security modules, both wouldn't really change how the system works with games.

On VMs, you can can how the virtual hardware and CPU reports to the Guest OS. Do you could potential use a VM, I don't recommend for variety of reasons, but technically possible.

On Steam Decks, I know a lot of people that steam decks are their only gaming PC. Some dock it at home like the Nintendo switch or just don't brother with large screens and play on the couch/bed. I played Elden Ring and Grounded online on my steam deck, so I can play with my friends at their house.

On Controllers, all game developers should support controllers, it is a key way for people with accessibility needs to also play games with devices work for them. The accessibility devices use controllers to remap to.

Last I saw on Linux Desktop stats got up to 4%, but is still very low.

Proton does support EAC software. I am not sure how easy is it to support that when not releasing on steam in fairness. I have only played Warhammer 40,000: Space Marine 2 online on my Linux Desktop. That games uses EAC. I also played Baldur's Gate 3 multiplayer.

I would love a Linux Native Version, but proton support would be the best option if they want support Linux Community.

I would love to see an Open Source Anti-Cheat Solution, that works. Security through Obfuscation is not my favorite.

(likely has typos)

Azalroth

Hello folks, we got Ashes to work on linux. Full tutorial https://forums.ashesofcreation.com/discussion/62094/linux-tips-tweaks-and-troubleshooting-thread/p1

JeanPhilippeGunghar

I have a warning for Linux users. Easy Anti Cheat isn't 100% compatible with Linux, Support said. I almost got perma ban because apparently I run Ashes without it. Which was false. I had proof it was indeed installed on
my machine and got unbanned. Be careful.

Child Item