Potential Issue with CSGO trusted mode resulting in severe degradation of trust factor.

[KeironO]

Your system information

• System information from steam: System information, but no longer running in Flatpak.
• Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

Linux users are experiencing sudden drops in their trust factor in spite of positive experiences prior.

We are currently investigating the following causes:

• mesa configuration changes related to mesa_glthread=true being added either through newer versions of the library or after being appended to the launch options.
• resizeable BAR being enabled on newer AMD hardware.

I have validated that trusted mode is running. Furthermore, I have sent emails to Valve about this, but am still yet to hear any real response.

Steps for reproducing this issue:

1. Download/install CSGO.
2. Play for a while.
3. See your TF drop.

[henrym11106]

I also got an inexplicable drop in trust factor around Christmas. suddenly I was getting 1-4 blatant cheaters per game in dangerzone.

I think one surge in cheaters happened mid December. I noted at least 5 cheaters in 3 games or so on the 16th, things got better a few days later then around the 24th cheaters ramped up to an absurd level and the red trust factor warning appeared on the 26th or 27th. my daily teammate never saw a yellow warning.

I've been playing deathmatch, missions etc daily since but matchmaking is still basically unplayable for me as of now. if I get a game at all there will be cheaters in it.

I'm using steam-native on Arch with an AMD GPU, no flatpack or anything, and that regular teammate is using the same without a problem.

pretty great that after finding and reporting workarounds for this game on Linux my experience is so badly affected. I do wonder if it's related. the timing is similar; that first big Decmber cheater spike happened around the time I figured out the 'radeonsi_clamp_div_by_zero=true %command%' launch option and related testing.

[sat3ll]

The queue times have been impossible since this change (30min +)

[ChrisLuck]

Wow, I was about to create a ticket about exactly that. Glad that I am not the only one experiencing this. It was clearly around Christmas when I also first noticed a steep incline in cheat games. It was almost impossible to find an enjoyable match.

Background Info My account is 15 years old, I got thousands of hours and thousands of match wins in csgo, but all of a sudden I am getting queued with all sorts of new, fishy accounts: 500million+ steamIDs, few ingame hours on record, bunnyhopping, spinbotting, aimhacking.

Normally maybe one out of 50 games was a spinbot game (rough estimate). Now ~80% of my games are fishy at least and around 50% are blatantly spinning and bunnyhopping.

Example Games Here are some examples. Just played five games in a row and four of them were spinbot/bhop games: steam://rungame/730/76561202255233023/+csgo_download_match%20CSGO-MJAuQ-T5KSA-yPZ4b-ipCrW-ca43L steam://rungame/730/76561202255233023/+csgo_download_match%20CSGO-KTkor-Arnzf-XDOHQ-99MJ9-hd5yD steam://rungame/730/76561202255233023/+csgo_download_match%20CSGO-tQ6VE-mTbBF-v99kR-nc6Ub-YE4BO Game number four was also very fishy but those three are really obvious.

Edit: Back from game number 5. You guess it, again cheaters. This time in my team, though. (Watch last rounds only): steam://rungame/730/76561202255233023/+csgo_download_match%20CSGO-XV7vS-yxm6p-LqxqE-uGi4n-QtjPK

Theories Not sure about your flatpack/trustfactor theory though. You should remove that from the title. My trust factor seems to be fine and I think Ubuntu, which I am running, is also not making use of flatpack. I had the theory that it has something to do with an inconsistent file error that I had. That was also around Christmas but I can no longer remember the exact error. It was saying something about some *.vpk file being wrong or missing. I never tampered with any of the game files so I don't know how I got this problem but the steam inbuilt file consistency check easily fixed that issue for me back then. Since this was timewise somehow correlated with the cheat game incline I thought that this might have triggered some detection mechanism that somehow shadow banned me or put me in the cheater queue for some reason.

@henrym11106 I also used radeonsi_clamp_div_by_zero=true to fix the dangerzone bug. And I also experimented with mesa_glthread=true and gallium hud for fps graph once.

[KeironO]

I've just checked and I'm also running both radeonsi_clamp_div_by_zero=true and mesa_glthread=true. I took a month break from MM, but my trust factor has not reset - despite me losing my rank.

[henrym11106]

This is looking a bit too consistent to be a coincidence. I only ran those launch options a few times but that is when my problems started. I was under the impression that a warning would show when launch options could hurt trust factor i.e. "-allow_third_party_software" and as far as I know, I've only ever launched in "Trusted Mode"

furthermore one other person in my home also plays CSGO on Linux with the same OS, configs (including clamp_div_by_zero via .drirc file later on), similar hardware and the native client as well. we do all the same stuff but they never used those launch options and have no trust factor problems.

as for me, matchmaking has been virtually unplayable for 10 weeks now and seemingly still getting worse on it's own. 20+ minute queues before giving up for comp and DZ, in Wingman there is always at least one blatant cheater on the other team. Wingman queue times used to be under 3 minutes, this year they started at 3-5, then 13 minutes, 16, now 20+ minute queues. looks like a good chunk of operation missions will be impossible this time around.

[KeironO]

[robertswiecki]

My story is pretty much the same: 10 yo account, Prime since 2016, and sometime around beginning of this (2021) year my friends (I played only with them at the time) told me my 'trust factor' is yellow, and after another couple of days that it's 'red'.

I don't use flatpak but a regular debian/testing, but with the bleeding edge mesa, because I have a new RX6000-class card + AMD Zen3 CPU, which is supported only by newer mesa drivers. I switched to this platform (from intel + nvidia) around mid-December 2020.

Since then 90%+ of my MM matches are with or against blatant cheaters.

Since you mentioned that it might be setting of mesa for radeon, I checked the git log for mesa, and this is what I found (from https://gitlab.freedesktop.org/mesa/mesa/-/blame/master/src/util/00-mesa-defaults.conf)

Log	Contents
radeonsi: add config entry for Counter-Strike Global Offensive Timothy Arceri committed 1 year ago	<application name="Counter-Strike Global Offensive" executable="csgo_linux64">
dri: Restrict glthread for CS:GO to radeonsi Nanley Chery committed 1 month ago	<option name="mesa_glthread" value="true" />
radeonsi: add config entry for Counter-Strike Global Offensive Timothy Arceri committed 1 year ago	<option name="radeonsi_zerovram" value="true" />
dri: enable glthread + radeonsi workaround for CS:GO Pierre-Eric Pelloux-Prayer committed 1 month ago	<option name="radeonsi_clamp_div_by_zero" value="true" />
radeonsi: add config entry for Counter-Strike Global Offensive Timothy Arceri committed 1 year ago	</application>

The changes (radeonsi_clamp_div_by_zero and mesa_glthread) were committed on Jan 11st and then on Jan 13th. This corresponds rather well with my troubles with the 'trust factor', still it might be a red herring.

Here's another commit, but from Jan 8th/11th https://cgit.freedesktop.org/mesa/mesa/commit/?id=6f2017205e62402b7b2e340620e39cb71730c565

dri: enable glthread + radeonsi workaround for CS:GO
author | Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> | 2021-01-08 13:17:42 +0100
Marge Bot <eric+marge@anholt.net> 2021-01-11 10:28:06 +0000

CC - @kisak-valve - I think you're our only hope :)

PS: I never used mesa_glthread or radeonsi_clamp_div_by_zero directly/manually, I presume it was flagged by the csgo trust factor SW after it had been added to the mesa's default config.

[henrym11106]

Interesting. I know those changes were merged then because I recommended them. I had been using mesa_glthread via .drirc for a long time without a problem and it does provide a significant performance boost, and I found the radeonsi_clamp_div_by_zero workaround partly by accident because I enabled it in adriconf, so it was also in my .drirc for a while before trouble began.

I was also using mesa-git, I had clamp_div_by_zero enabled before November 22, saw a huge spike in Dangerzone cheaters around December 16, switched to mesa stable on December 24 (two days before my trust factor warning appeared?) then back to git (lordheavy repo, Arch) February 9. this is the first time I've had low trust score as far as I can tell, playing since 2017.

with the other machine in my home radeonsi_clamp_div_by_zero was enabled later on but before it was default in stable, so probably some time in January. they too had glthread in .drirc long before. no trust factor problems for that person's account recently, but they had an issue in the early days of Dangerzone. unlike my account, they never enabled workarounds via launch options and only ever used mesa stable, also on Arch with AMDGPU.

[KeironO]

Thank you for the responses. I'm glad that it's probably not Flatpak related as I'm not a huge fan of having a non-sandboxed instance of Steam (or any application) running on my machine. I ran radeonsi_clamp_div_by_zero and mesa_glthread as I was having issues with graphical artefacts with my (then) new 5700XT and it seemed to resolve those.

@robertswiecki - I did 3 overwatch cases a day for a month and there was zero change to my trust factor.

It's unfortunate as friends who previously played with me now no longer want to play with me because they're getting super frustrated with the cheating problem. It sucks.

[robertswiecki]

And my stats from csgostats.gg - 100% matches vs or with cheaters between January 13th and today - though I didn't play between mid-December and January 13th. So the TF drop could also have happened around the Christmas time. Today's matches were also with or against cheaters, and the stats will most likely reflect that in a couple of days.

@kisak-valve I understand that pinging you directly here might backfire. I'm very grateful for your efforts dealing with not always pleasant csgo community. Also, I get that Valve is v. secretive about thew TF sauce, and even working at Valve might not give you enough leverage to investigate it or to make any changes to the algo involved. But, I don't think there's anything we can do on our own here, and the timing plus the specific type of HW configuration of affected users would indicate that it's a systemic problem with csgo signal gathering/processing infrastructure. So, anything you can do, even if replying with Sorry folks, but I've looked at our DBs and you legitimately deserve to have this low TF would be greatly appreciated. Thank you in advance!

[p4block]

Literally all my matches since the 7th of December have had many cheaters in them, my trust factor is deep in the red according to my friends in queue. A friend also played on my computer (with his steam acc) a single game and his account also got instantly flagged with red trust factor.

Tried emailing a few times with my account and these same details but I think it's a lost cause.

Running arch with mesa-git (so latest patches in there), I also used to run mangohud to show fps and gpu stats but stopped because I suspected it wasn't doing the TF any favors. Also asked about that in the emails.

I just stopped playing the game honestly. I basically got "soft banned" as the game is completely unplayable with every game having multiple cheaters on both teams if I dare solo queue.

If anyone at Valve wants logs etc for debugging I'm open to helping in any way I can. I'd love to be able to play the game again.

[TerminalHash]

Objectively, the problem with the trust factor has been around since 2019 and in general since the moment the trusted mode was introduced. I speak as one who previously played CSGO with friends, being not only on Arch Linux - we were clearly thrown into the very abyss of frankly bad players, I was thrown to cheaters alone, despite the fact that I played well and, in fact, did not stand out for anything like that. It was precisely because the game deliberately underestimated the trust factor for me that I left from GO to 1.6 and Source.

[henrym11106]

I wonder if the issue was the presence mesa-git itself. it seems my trust score was dropping as long as it was installed after December since my queues kept getting longer through February.

also my regular teammate/other player in my home is regularly spammed with steamwebsockets errors and I'm not, even on the same server. we can't figure out why.

it looks like there were changes in who maintained which Arch packages Dec. 2020 - Feb. 2021, with Lone_Wolf looking to move on from mesa-git AUR, no longer providing pre-built mesa packages (chaotic-aur) and now focusing on mesa-minimal-git. maybe CSGO was tracking mesa-git but got thrown off by those changes? I saw Valve devs in Lone_Wolf's AUR comments before.

So how was everyone else using mesa-git? I used to build from AUR before trying the chaotic-AUR repo and then the LCarlier (lordheavy) repo most recently. I would like to try building mesa-minimal-git but I'm not confident that it won't further ruin my account, even though Valve recently pushed a beta client update targeting mesa-git.

I update daily, and my mesa package change history for the relevant period is:

• 2020-11-11 installed mesa-git (1:21.0.0_devel.130965.3a512c34d2f-1, lordheavy/lcarlier repo)
• clamp-div-by-zero enabled mid November, massive drop in match quality mid-to-late December
• 2020-12-24 installed mesa stable
• 2021-02-09 installed mesa-git (lordheavy repo, Arch)
• 2021-03-11 installed mesa stable (20.3.4)

https://steamcommunity.com/profiles/76561198298266626

[p4block]

I personally have always used lcarlier's mesa-git and upgraded rigorously every day. Honestly, touching the game at all seems like a bad idea right now until we get an official comment.

[KeironO]

I've been using both mesa-git and mesa-git-x86 copr's since Tue 20 Oct 2020 (according to my bash logs anyway).

https://copr.fedorainfracloud.org/coprs/xxmitsu/mesa-git/

[KeironO]

This is painful:

[KeironO]

Had a non-automated response.

[r3muxd]

i wonder if this is because you can use the LD_PRELOAD env var to inject cheats so valve just decided to decrease the trust factor of anyone with environment variable launch args set

[robertswiecki]

i wonder if this is because you can use the LD_PRELOAD env var to inject cheats so valve just decided to decrease the trust factor of anyone with environment variable launch args set

That would be my bet. I used LD_PRELOAD to make csgo run under pure wayland, and to fix DirT Rally (or maybe Dirt 4, don't remember now) to make it run under Zen3 CPU + new Linux kernels. I described both attempts in https://news.ycombinator.com/item?id=25818126 - it seems that Dirt rally is also integrated with libsteam and by extension with vac modules, so that info probably propagates from game to game within the valve's infrastructure.

It wouldn't be a stretch of imagination to say that given that no method for loading 3rd party libs under Linux is employed in csgo/steam (as opposed to Windows, which has some protections), then every use of LD_PRELOAD (or maybe every use with a non-indexed by Valve library) is viewed as suspicious, and the low trust factor applied just in case.

PS: Also, here's somebody who genuinely tried to fix a sigsegv in csgo, downgraded tcmalloc.so for some time, and was issued a red TF within a couple of days (green->yellow->red, same as me) - https://github.com/ValveSoftware/csgo-osx-linux/issues/2651#issuecomment-777804702

[KeironO]

Does anyone know if the recent announced mesa upgrades for PopOS has the defaults @henrym11106 posted earlier?

If so, we should probably make System76 aware. @jacobgkau

[r3muxd]

i wonder if this is because you can use the LD_PRELOAD env var to inject cheats so valve just decided to decrease the trust factor of anyone with environment variable launch args set

That would be my bet. I used LD_PRELOAD to make csgo run under pure wayland, and to fix DirT Rally (or maybe Dirt 4, don't remember now) to make it run under Zen3 CPU + new Linux kernels. I described both attempts in https://news.ycombinator.com/item?id=25818126 - it seems that Dirt rally is also integrated with libsteam and by extension with vac modules, so that info probably propagates from game to game within the valve's infrastructure.

It wouldn't be a stretch of imagination to say that given that no method for loading 3rd party libs under Linux is employed in csgo/steam (as opposed to Windows, which has some protections), then every use of LD_PRELOAD (or maybe every use with a non-indexed by Valve library) is viewed as suspicious, and the low trust factor applied just in case.

PS: Also, here's somebody who genuinely tried to fix a sigsegv in csgo, downgraded tcmalloc.so for some time, and was issued a red TF within a couple of days (green->yellow->red, same as me) - #2651 (comment)

it's funny because that wouldn't stop absolutely any cheats, but maybe try setting them as global environment variables instead of launch args

[Devorlon]

I'm wondering if this is an issue with the steam runtime. I've been having this issue (while using steam-native) and one day got a message in CS:GO saying that VAC couldn't activate (or something similar). So I switched to Steam-Runtime and did'nt get the message and also got my first over-watch case review.

So my thinking is that you can get into a game without the runtime but it lowers your trust.(?) So to get some numbers can you '''react''' with the associated icon.

I've been playing CS:GO with:

Steam Runtime - Rocket (🚀) Steam Native - Hooray / Celebration (🎉) Don't Know - Confused (😕) Just Watching - (👀)

Thanks

[jacobgkau]

Does anyone know if the recent announced mesa upgrades for PopOS has the defaults @henrym11106 posted earlier?

If so, we should probably make System76 aware.

@KeironO You can view the mesa being shipped in Pop!_OS here: https://github.com/pop-os/mesa

The released version is on the master_ branches, and the pending updates are on the rx6000_ branches. It does look like the two new options, radeonsi_clamp_div_by_zero and mesa_glthread, are being pulled in with the update to support the RX 6000 series.

Am I correct in understanding that you believe these options are causing Valve anti-cheat to flag users in CS:GO? Has anyone from Valve confirmed this (it sounds like they haven't yet, but might be looking into it)? Are you wanting/suggesting those new lines to be patched out in Pop?

I see that the changes were merged upstream after a user opened an issue requesting it: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4021 (and that issue links back to https://github.com/ValveSoftware/csgo-osx-linux/issues/2101 in this repository.) It sounds like visual glitches occur without these options. If that's the case, then it seems like the best solution would be for Valve to address this, but I'll mention this issue in our rx6000 PR so the rest of the team's aware.

(Our package is pulled from Ubuntu 21.04, so even if we patch this out, vanilla Ubuntu 21.04 users would still be affected-- you could bring this up in Ubuntu's bug tracker as well, but short of Valve allowing these options to be used, the next-best option long-term would be to have them removed in upstream Mesa.)

[henrym11106]

not clear if the options themselves cause any problems, I used them for quite a while via .drirc before the trouble began; I had clamp_div_by_zero enabled for about 6 weeks, glthread for a few years. and another computer running all the same except for mesa-git and some launch options has had no problems.

evidence is pointing to mesa git, no data for stable releases. according to my pacman history the update from the time I first saw obvious, consistent match quality problems was either 1:21.0.0_devel.132289.2ffae5a439b-1 on 2020-12-14 or 1:21.0.0_devel.132340.296316b5dec-1 on 2020-12-16. not sure how fast trust factor is affected.

basically just waiting for further response from Valve at this point.

[jackpot51]

I guess this means I can play CS:GO on work hours? I need some help with how to see if my VAC status is affected. I'll be using Mesa 21.0 plus some mods for RX 6700 XT.

[KeironO]

@jacobgkau

Am I correct in understanding that you believe these options are causing Valve anti-cheat to flag users in CS:GO? Has anyone from Valve confirmed this (it sounds like they haven't yet, but might be looking into it)? Are you wanting/suggesting those new lines to be patched out in Pop?

We're still waiting for some form of confirmation from Valve, but this feels like it's too common to just be a coincidence.

(Our package is pulled from Ubuntu 21.04, so even if we patch this out, vanilla Ubuntu 21.04 users would still be affected-- you could bring this up in Ubuntu's bug tracker as well, but short of Valve allowing these options to be used, the next-best option long-term would be to have them removed in upstream Mesa.)

I think we'd have to get into contact with the peeps working on Mesa as this is going to effect a lot of people downstream. @henrym11106 you said before that you've been in contact with Mesa regarding defaults before, would you be so kind as to draw attention to this issue for us?

[jackpot51]

Welp I never got VAC banned but I'm pretty sure there were some folks I was playing against who should have been

[KeironO]

In an attempt to regain trust factor, I've uninstalled the Linux version of the game and have resorted to buying a secondary drive for Windows. Still, the problem persists. I've done some research online and it looks like the vast majority of people that are put into low trust factor are unable to get out - so maybe I'm no longer going to be able to play this game.

[Scrumplex]

@KeironO TF needs some time to recover. Stop playing the game for a week or two and try again

[Scrumplex]

I am unsure about that Mesa stuff. But looking at the commit tells me that it was first shipped in Mesa 21.0.0 (click the ... near the top "parent c4427c2b"). Looking at pacman.log shows me that it was installed on 2021-03-12 on my system. I am sure that the bad matches started happening on/after 2021-02-19 (or maybe even before). I don't remember low trust factor in my matches before on 2021-02-13.

I don't really know the exact timestamp of when it started happening as I didn't play the game for a 2-3 weeks before 2021-02-13.

Here is my pacman log, seperated by different operations. I also added a few comments here and there https://paste.rs/76E

[Devorlon]

@Scrumplex Did you use the Steam-Native or Steam-Runtime packages with CS? And did you put anything in the launch options?

[Scrumplex]

@Scrumplex Did you use the Steam-Native or Steam-Runtime packages with CS? And did you put anything in the launch options?

@Devorlon I am using the steam package from the official Arch repos. I am always using Steam Runtime. These are my command line options gamemoderun %command% -novid -high -threads 8 -nojoy +fps_max 120 +exec autoexec

[Scrumplex]

About that LD_PRELOAD thingy mentioned earlier, maybe it's gamemode for me that's causing this? I way already using it way before this happened

[Devorlon]

I think that setting variables before '%command%' (like gamemoderun) might be what's affecting trust. As it's running additional software along with CS.

[KeironO]

@Scrumplex - I took a month off and the trust factor didn't change.

I've not seen anyone actually recover their trust factor from this situation, so I'm starting to come to terms that this is not going to be resolvable and that Valve are just a tiny indie games company that can't be expected to support a game that's probably just breaking even.

[robertswiecki]

It's probably reasonable to say to marking accounts (and actually whole computers, b/c Valve does HWID) as 'low trust' is a way for Valve to award an equivalent of VAC bans without being 100% sure that someone is actually cheating. Most people with low TF will stop playing MM (which makes it de-facto VAC ban), and unless they decide to play Faceit or on FFA servers, playing CS:GO will not make sense to them any more.

I'd understand if low TF were applied for say 2 weeks to "suspected" accounts, until the community overwatch or improved VAC heuristics will either confirm VAC ban or clear the account from the suspicion.

But deciding that's it's fine to force their customers to play with or against cheaters for months and having it as a operating policy, that's a hostile move towards the company's customers.

[Scrumplex]

Are most / all people here using tools like gamemode or MangoHud? I am starting to suspect that those are triggering low trust factor with Trusted Mode.

gamemoderun uses LD_PRELOAD to hook into the game to enable/disable gamemode. As CS:GO is OpenGL on Linux, MangoHUD also needs to use LD_PRELOAD to work here.

As I tried to explain earlier, the release date of Mesa 21 does not line up for me, as I started having these issues Mid February.

[Scrumplex]

As I tried to explain earlier, the release date of Mesa 21 does not line up for me, as I started having these issues Mid February.

Nevermind! I just downloaded the last few mesa packages from Arch Linux archive.

Mesa 20.3.3 shipped with radeonsi_clamp_div_by_zero, while 20.3.2 did not.

But for some reason no glthread? I though that both were enabled in a single commit.

Anyways. You can get the affected versions from the Arch Linux Archive. Look into the packages at usr/share/drirc.d/00-mesa-defaults.conf Extract the packages into subdirectories and run this grep -A4 csgo_linux */usr/share/drirc.d/00-mesa-defaults.conf

Edit:

I now disabled radeonsi_clamp_div_by_zero and mesa_glthread via a custom ~/.drirc:

<?xml version="1.0" standalone="yes"?>

<!DOCTYPE driconf [
   <!ELEMENT driconf      (device+)>
   <!ELEMENT device       (application | engine)+>
   <!ATTLIST device       driver CDATA #IMPLIED>
   <!ELEMENT application  (option+)>
   <!ATTLIST application  name CDATA #REQUIRED
                          executable CDATA #IMPLIED
                          sha1 CDATA #IMPLIED
                          application_name_match CDATA #IMPLIED
                          application_versions CDATA #IMPLIED>
   <!ELEMENT engine       (option+)>

   <!-- engine_name_match: A regexp matching the engine name -->
   <!-- engine_versions: A version in range format
             (version 1 to 4 : "1:4") -->

   <!ATTLIST engine       engine_name_match CDATA #REQUIRED
                          engine_versions CDATA #REQUIRED>

   <!ELEMENT option       EMPTY>
   <!ATTLIST option       name CDATA #REQUIRED
                          value CDATA #REQUIRED>
]>

<driconf>
  <device driver="radeonsi">
    <application name="Counter-Strike Global Offensive" executable="csgo_linux64">
        <option name="mesa_glthread" value="false" />
        <option name="radeonsi_clamp_div_by_zero" value="false" />
    </application>
  </device>
</driconf>

[KeironO]

@Scrumplex, I've been off Linux since late March and my account is still in low TF.

Edit: Wrong date(!)

[henrym11106]

Thing is, the other computer in my home running almost all the same software, AMDGPU, steam-native etc. was also running mesa_glthread forever, and radeonsi_clamp_div_by_zero was specifically enabled via .drirc since (I think) mesa 20.3.2. my machine and that other one are also both invoking the gamemode daemon from launch options and always have. my account was ruined and the other one was not.

the only differences between the two computers and accounts was that I enabled radeonsi_clamp_div_by_zero sooner on mine, I was on mesa-git at the time and I used a few related %command% options a couple times. also that account had a trust factor issue once in h2 2019 that Valve was emailed about.

one other thing is I launched with -perfectworld once... all I got was an ID request thing so I closed and relaunched without it.

[KeironO]

Has anyone heard back from Valve in any capacity outside of automated email responses?

[ryannathans]

I too seem to be affected by this trust factor problem (steamid ryannathans). I have an AMD Radeon VII with always up to date kisak-mesa and xanmod kernel on pop_os!

I have not set any launch arguments except -nojoy

[ryannathans]

System information https://gist.github.com/ryannathans/8645ccf72e1bd978a4d5d20d87d2cc28

[KeironO]

Hey @ryannathans

I'm sorry that you've experienced these problems. I have tried my upmost to highlight it, but people are still falling through the cracks.

I've had these problems for nearly 5 months and have attempted everything to improve my trust factor, but I've gotten nowhere.

I think 95% of my games since January 1st have had people VAC'ed, and I've now stopped playing altogether. Part of the fun in this game is trying to improve, but you can't really improve when your team mates/enemies are cheating so blatantly.

My advice to you, or anyone else reading this, is to stop playing if you're affected by this bug. Until Valve resolve it, the game is unplayable.

Best wishes,

KeironO

[dancrn]

hi all, i'm a bit late to the party here, but i have a very similar story to everyone else before me (although my low TF started happening maybe about 2 weeks ago). i've got an AMD GPU, i'm using ubuntu, and I have latest builds of mesa (i switched over to mesa-git for the purposes of getting cyberpunk, uh, "working").

matchmaking is unplayable. it's doubley painful because CSGO is how i've been socialising and staying sane in the locked-down world.

[ryannathans]

One possible workaround (that doesn't work for competitive) is to have your friend queue up and find a game, then join your friend's game when there is an available player slot

[dancrn]

Trust factor is not a determining factor in non-competitive game modes.

[ryannathans]

Whoops, my mistake, I was thinking wingman was non-competitive for some reason.

Oddly I can't even find a competitive game in a prime disabled lobby with a non-prime friend. I thought trust factor was only used in prime? The warning for low trust factor does not appear in non-prime lobbies yet after 1.5 hours queuing still no game.

[dancrn]

It's unlikely to show up in non-prime lobbies because a non-prime match is almost certainly going to be low trust factor for everyone involved. The trust factor warning is only shown to people with a higher trust factor than you.

[ryannathans]

If I had the same trust factor as my non-prime friend, why are they able to find a competitive game in 1 minute but when I am in the lobby we never find a game? Are we "shadow banned" separately to trust factor? I encourage you to try this experiment for yourself and see if you get the same results