Glorious Alpha Two Testers!
Alpha Two Realms are now unlocked for Phase II testing!
For our initial launch, testing will begin on Friday, December 20, 2024, at 10 AM Pacific and continue uninterrupted until Monday, January 6, 2025, at 10 AM Pacific. After January 6th, we’ll transition to a schedule of five-day-per-week access for the remainder of Phase II.
You can download the game launcher here and we encourage you to join us on our for the most up to date testing news.
Alpha Two Realms are now unlocked for Phase II testing!
For our initial launch, testing will begin on Friday, December 20, 2024, at 10 AM Pacific and continue uninterrupted until Monday, January 6, 2025, at 10 AM Pacific. After January 6th, we’ll transition to a schedule of five-day-per-week access for the remainder of Phase II.
You can download the game launcher here and we encourage you to join us on our for the most up to date testing news.
Comments
So, what you are saying here is that Linux is only able to be used for cheating if you actually try to do that.
Well, I'm glad we don't need to worry about people accidently cheating on it.
The problem with what you are saying - which can kind of be broken down to "it isn't easy to hide your cheating on Linux", is that you think it is ok for people to cheat if they know what they are doing.
Let’s get something straight: I never said, nor implied, that it’s ‘okay for people to cheat if they know what they’re doing.’ That’s a ridiculous misinterpretation of my point. Cheating is unacceptable, no matter what platform you’re on or how technically savvy you are. My argument was focused on debunking the false notion that Linux somehow makes it easier to hide cheats, which it doesn’t.
To clarify, Linux’s flexibility and openness do not equate to an invitation for cheating. If anything, the transparency of Linux makes it easier for both users and developers to detect and root out malicious behavior. Saying that Linux is only good for cheating ‘if you actually try’ is like saying the same about any operating system—including Windows. Anyone who deliberately attempts to cheat and knows what they’re doing can potentially cause problems on any platform, but that’s a universal truth, not something unique to Linux.
The reality is that on Linux, just like on Windows, cheating requires deliberate action and intent. The difference lies in how cheats are developed, deployed, and detected. The gaming industry’s focus on Windows has led to more cheat tools being available there, but that doesn’t make Linux a cheater’s paradise. In fact, the diversity and configurability of Linux distributions add layers of complexity that make it harder, not easier, to develop universal cheat tools.
So let’s drop the strawman argument. Cheating is never acceptable, and Linux is not some magical loophole that makes it easier. The focus should be on developing robust anti-cheat systems that work across all platforms, including Linux, to ensure a fair gaming environment for everyone.
Which is it?
Let’s clear this up once and for all. There’s no contradiction here if you actually understand what’s being discussed. Saying that Linux doesn’t make it easier to hide cheats is about the general landscape—how cheats operate, how they’re detected, and how they’re countered. It’s about the baseline difficulty of developing and deploying cheats across different systems.
The point about configuring a Linux system to limit what applications, including anti-cheat software, can see is a separate issue. This is true for any operating system, not just Linux. On any platform—Windows, Linux, or macOS—a user with enough knowledge and malicious intent can tweak their environment to try and hide what they’re doing. But that’s not a problem unique to Linux. If anything, Linux's openness means it’s easier to detect and scrutinize these configurations, especially by those who know what they’re doing.
So, before jumping to conclusions, let’s be clear: The ability to configure a system in specific ways doesn’t mean that Linux inherently makes cheating easier or more hidden. It means that with enough knowledge, anyone on any platform can try to manipulate their environment, but that’s no special advantage of Linux. The real issue here is intent and capability, which apply universally, not just to Linux.
This wording is borderline neferious.
"Anyone can try" on any OS. You can try and hack the game using a banana if you want, that doesn't mean you will be successful.
Fact is, is you are using Windows, you absolutely can set up a curtain to hide a portion of what is running on your system, just as you can on Linux. The thing is, on Linux, you can hide the curtain as well.
On Windows, you can't hide it.
Anti-cheat software looks for cheats, but also looks for that curtain. If it finds either, it stands in the way. It doesn't care what is behind that curtain, it just cares that it is there. This is why you can't do something as simple as running a game using EAC on a VM - even though there are many valid reasons for using one, RAC simply doesn't allow for it, because it can't see past it.
You are right that intent and capability are important, but so are tools - and Linux offers a better toolset for this than Windows.
Let’s break this down carefully. Your argument hinges on the idea that Linux somehow offers a better toolset for hiding cheats, but that’s an oversimplification and, frankly, not an accurate portrayal of how things work.
First off, let’s tackle the notion of ‘hiding the curtain.’ The idea that Linux allows users to hide the very mechanisms that might be used to conceal cheats isn’t entirely accurate. While Linux does offer greater control over system processes and permissions, this doesn’t translate into some magical ability to cloak cheats from detection. In fact, because of the open nature of Linux, anti-cheat developers can dig deeper into the system’s operations, if necessary, to identify suspicious behavior.
Yes, Linux provides more tools and flexibility—tools that are often used for legitimate purposes, like privacy, security, or system customization. But these tools aren’t exclusive to cheating, nor do they make cheating inherently easier or harder. The claim that Linux users can ‘hide the curtain’ implies a level of stealth that’s simply not there. Anti-cheat systems on Linux can be just as effective as those on Windows, especially when designed with cross-platform compatibility in mind.
Now, let’s address why Linux’s powerful tools do not make cheating easier. The fact that Linux offers more granular control over the system doesn’t inherently benefit cheaters. In many cases, this increased control and transparency actually works against those trying to cheat. For example, the open-source nature of Linux means that the entire system is subject to scrutiny—not just by users but also by developers and the broader community. This transparency can make it easier to detect abnormal behavior or configurations that could indicate cheating.
Furthermore, Linux’s flexibility means that it’s harder to create cheats that work universally across all Linux distributions. The wide variety of configurations and environments in Linux makes it challenging for cheat developers to design tools that are effective across the board. This diversity acts as a natural deterrent, increasing the complexity and reducing the success rate of cheats compared to the more standardized Windows environment.
The idea that Linux provides superior tools for hiding cheating is more myth than reality. It comes down to how those tools are used—and in what context. Let’s not confuse the availability of powerful tools with an inherent advantage in cheating. If anything, the visibility and control that Linux offers can work both ways, benefiting both users and developers in detecting and preventing cheating.
So, while it’s important to acknowledge that Linux offers different capabilities than Windows, it’s equally important to recognize that this doesn’t give cheaters an edge. The tools might differ, but the principles of detection and prevention remain consistent across platforms.
Again, this is as opposed to Windows just pointing to the curtain.
Let’s dive into the technical aspects of this. The idea that Linux requires ‘bespoke detection’ on each client system misunderstands how modern anti-cheat systems operate across different platforms.Anti-cheat mechanisms don't rely on needing to 'see behind a curtain' in a literal sense, whether on Windows or Linux. Instead, they function by monitoring specific behaviors, system calls, memory access patterns, and interactions that are indicative of cheating. These mechanisms are designed to detect anomalies in how software behaves rather than needing to probe every aspect of a system's configuration.On Linux, the open-source nature and the diversity of distributions do mean there’s more flexibility and control available to users. However, this does not translate into a fundamental advantage for cheaters. In fact, anti-cheat systems can leverage Linux's transparency to their advantage. Tools like strace, auditd, or SELinux provide a wealth of monitoring capabilities that can be integrated into anti-cheat solutions to detect unauthorized actions or irregularities at the system level.Moreover, modern anti-cheat systems, such as those integrated with Proton or those using kernel-level modules, can perform extensive checks on the integrity of game files, system libraries, and even the kernel itself. These checks are not fundamentally different from what is done on Windows, where similar techniques are used to monitor and verify the integrity of the environment.The 'curtain' metaphor you're using refers to sandboxing or virtualization detection techniques often employed on Windows. Anti-cheat systems look for processes running in isolated environments (like VMs) because these can sometimes be used to hide cheats. However, this is not a weakness in Linux but a general concern across all platforms. On Linux, similar isolation techniques (like containers or namespaces) can be detected and flagged by anti-cheat systems if they are being used to manipulate the game environment.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. While on Windows, a cheat might work broadly across millions of identical systems; on Linux, the variability in distributions, kernels, and configurations means that cheats have to be much more sophisticated and adaptable to be effective. This variability works as a natural deterrent.
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.
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.
They do, that is why I can't run the game on my VM.
We have managed to sort this out for a number of Linux users using the Alpha 2 Client.
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).
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.
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.
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.
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.
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)