Install Easy Anti Cheat

[Irmgard Rossie]

Verifyinggame files in Steam (multiple times)

A full re-install of the game.

Re-installing and repairing Easy Anti-Cheat

Completely disabling all firewalls and antivirus protection (I only use Windows Defender), as well as manually setting up exceptions.

Playing on both a strict NAT type and DMZ type connection.

Checking both HD and Ram for errors (and making sure the Ram sticks were both running at the same rate)

Confirming that Windows and my GPU have the latest updates installed.

Disabling the API that runs the lights on my gaming keyboard.

Clearing the Steam download cache

Changing the Download Region before verifying files

Running a Windows registry cleaner

Running steam As Admin

Adding full read / write security access to the Vermintide 2 folder

none except they are never gonna try to fix it. Steam try to push that and have support for anti-cheat in kernel so wine could run anti-cheat software without any modification. The first working solution could be considered like cheating and so it will never be support. The kernel with anti-cheat support is suposed to land in 5.11 If iu want to learn more this video could explain things

I love to use Arch Linux to play my favorite video games. However, since the release of glibc 2.39-1 I am forced to use glibc-eac from the AUR. This is because the (regular) glibc package from the core repository lacks the DT_HASH patch for games using EAC (Easy Anti-Cheat).

Apparently it has been suggested to install the flatpak version of steam (see closed bug tracker). I feel that's hardly a solution as there are many people who would love to keep on using regular steam for increased performance, being able to use one's /home directory etc.

This is problem to the many Arch gamers out there. Many games use EAC and there's quite of number of games that break because of the issue with glibc.

I am wondering if there's an awareness of the magnitude of the problem. What is the likelihood of this being resolved?

1. As he pointed out, glibc is one of the core packages of the system, is it desired that a % of the Arch-users is going to use glibc via the AUR instead of via the repositories? It seems like easy breaking territory to me.

2. I agree with him that the Steam Flatpak is not a solution, but he doesn't properly motivate why, it is not really about what we prefer to do. The problem with the Steam flatpak is that the performance is worse than with regular Steam in certain cases and in some other cases the game just won't run at all with Steam Flatpak while it will run with the latest regular version of Steam. Linux YouTuber (he also finished at least the bachelor of computer science so he knows a bit what he talks about in regard to software) Brodie Robertson addressed that in his video about EAC being broken again on Arch.

3. Archerino strongly undersells the scale of the problem with "hundreds of users", we know from the Steam Hardware Survey (far from perfect but it gives some indication) that a high % of the Linux-gamers uses Arch, it already was roughly tied with Ubuntu as the most popular distro for gaming before the SteamDeck was sold, I assume that everybody here knows what the SteamDeck is. One of the games for which currently EAC on Arch is broken is Apex:Legends, this is the 3rd most popular Battleground shooter (at a large distance from Fortnite and PUBG), which probably is the most popular genre of games in the last years. I myself play Apex:Legends at times, it just can't start with glibc from the Arch-repositories and it starts with glibc-eac via the AUR. I can understand that not everybody in the Arch-team appreciates gaming and that is fine, but please appreciate that many of us do like to game and that gaming is as common on Linux as it is on Windows these days with how good wine and especially dxvk have gotten, also assisted by tools like Lutris and Steam Proton. Common users now use Linux for gaming as they do on Windows.

In reply to Scimmia, this is not a new problem. This is a repeat of moves from 2 years ago. Back then the packager for Arch started to compile glibc differently and it broke EAC-support. In my opinion he made the correct choice to revoke it after many gamers pointed out this problem. The big question: why did he revoke it 2 years ago and not do it now? What changed? We know that these game-developers still use a deprecated hash table. Do some people hope that these game-developers will finally learn it by breaking Arch on purpose for those games? I give that 0% chance. Is there any valid reason to not support the "deprecated" hash-table? What harm does result from supporting both? A bit more data-usage while 2 TB SSD's cost less than $90? If for most users that would be problematic then it is fine but if no user its system gets any harm from also using the deprecated hash-table then the correct choice is to support that, in my opinion.

Proposed solution: offer also glibc-eac in the repositories. The real repositories, not the AUR-scripts. Everybody would be happy with that solution. I appreciate the efforst from all the people who keep Arch going, please don't take any offense from this post, I mereley address a current problem.

For me, it's pragmatic thing to do. I don't have any data but if steam hardware survey is anything to go by to deduct, a considerable amount of arch users are gamers as well. One day, official glibc package is going to be updated along with rebuild of every package that depends on it. It will end up breaking maybe hundreds of installations if users are not careful. It's only a matter of time before something that drastic happens. Think of the flood this forum or subreddit is going to get when that happens.

Thank you all for commenting.

I agree with MacTavishAO that it would be a net win to include this patch in the official repos. Futhermore, I agree with PeterJansen that there doesn't appear to be reason not to include the deprecated hash table.

Even if upstream changed something, including it doesn't seem to have real disadvantages while it could help out the many gamers out there.

I purchased virtual desktop about 5 days ago and played pokerstars on it. Was great until about 2 days ago when i started pokerstars vr and saw a box for this program pop up, then i got an error message saying either no audio on the headset or general device error in the oculus app on my PC, but everything works fine when playing from my headset. Help please.

Hey there! Are any other PCVR games you have affected by this, or is this solely on the PC version of PokerStars? It's good to hear that your Quest 2 is still good standalone, so let's see if we can get your PCVR experience back to 100%.

shen I connect through virtual desktop and go to games, then click pokerstars, I get the easy anti-cheating load screen then get the error in the first picture. After I close that and go to the oculus program on my pc, I get the error in the second picture. But I could go to my headset and play with no problems what so ever.

You said it was working previously until about 2 days ago. Did anything change or update right before it stopped working? And have you tried uninstalling and reinstalling PokerStars/the Oculus PC app?

Having trouble with a Facebook or Instagram account? The best place to go for help with those accounts is the Facebook Help Center or the Instagram Help Center. This community can't help with those accounts.

This has popped up in the past, but it has never been universal and I am not sure an exact root cause was found. I played a different game that uses EZ Anti-cheat multiple times this week and have not run into this, nor the last time around.

Make sure you list your MB model and any other RGB software (Mystic Lighting, Aura, Fusion, etc) and perhaps if others are seeing this we can find some common elements. Locality may be an issue as well. You don't need to list exactly where you are, but a general regional reference (NA, Europe, Asia, Australia, etc) may be relevant.

I was be able to run Hell Let Loose until today when I installed iCue. I haven't made any other changes to this computer. I can close the iCue and Hell Let Loose would run, but I would have to play without the EQ settings I have set up. Not exactly a deal breaker, but it's definitely a hassle to close iCue just to be able to play Hell Let Loose and then open it again when doing other stuff.

Certain anti-cheats kick the player from game because of "untrusted system file", for example EAC does so for the game Rust since a recent update. It seems to be at the game developers' discretion, as some EAC-powered games have suffered from amdihk DLL in the past.

There are good technical reasons for anti-cheats of a variety of games to desire blocking unsigned/untrusted driver files in the system32 and system driver folders. I can know, as an anticheat developer (from another game) myself.

AMD, or any driver publisher, should NEVER ship unsigned driver files. "AMDIHK64" (AMD DVR component) is, as far I know, the only of such file that lacks a digital signing certificate. It's not just not valid, but completely absent, throughout recent releases of Radeon software.

Its not just anti-cheats that are affected, there are obvious reasons why DLL files of known, major (driver) software that are placed in system folders need to be signed. A lot of software can do trust checks and eventually fail. For the anti-cheat of popular games using EAC, you have now impacted hundreds of thousands of users, and they may decide to manually remove amdihk DLL file in safemode, leading to them not benefitting from AMD DVR functionality.. just in a bid to play the game. This isn't ideal.

Again, software/driver publishers should have developers that know what proper project practise is. Shipping out 99% valid signed DLLs and a single or a few unsigned files, is bad practise. Under correct practise, no issues like the anticheat one would arise. The solution is obvious.

3a8082e126