sapphonie / StAC-tf2

steph's anticheat (StAC). a built-from-scratch sourcemod based solution to cheating in Team Fortress 2.
https://sappho.io
GNU General Public License v3.0
120 stars 23 forks source link

STAC incompatible with latest TF2 100 maxplayers addition #160

Closed AgitationSkeleton closed 1 year ago

AgitationSkeleton commented 1 year ago
[StAC]

----> StAC version [5.4.3] loaded

L 07/25/2023 - 22:54:10: [SM] Exception reported: [StAC] This plugin (and TF2 in general) does not support more than 33 players (32 + 1 for STV). Aborting!
L 07/25/2023 - 22:54:10: [SM] Blaming: stac.smx
L 07/25/2023 - 22:54:10: [SM] Call stack trace:
L 07/25/2023 - 22:54:10: [SM]   [0] SetFailState
L 07/25/2023 - 22:54:10: [SM]   [1] Line 81, stac.sp::OnPluginStart
L 07/25/2023 - 22:54:10: [SM] Unable to load plugin "stac.smx": Error detected in plugin startup (see error logs)

The error is obvious, but I figure I'd note it here as something that should be changed as a lot of admins (myself included) will want to increase their maxplayers per this update to try and attract more players.

sapphonie commented 1 year ago

You're running an outdated version, this is explained better here:

https://github.com/sapphonie/StAC-tf2/blob/master/scripting/stac.sp#L293-L307

StAC doesn't make any sense to run at above 32 players and arguably at above 24, depending on hardware, the engine wasn't designed to iterate through so many clients within a sane amount of time and StAC can't count on receiving at least vaguely consistent data from each player - this is why there is a check for server stuttering every game frame:

https://github.com/sapphonie/StAC-tf2/blob/master/scripting/stac.sp#L223-L240

... and that check will probably just get hit constantly, rendering the plugin mostly useless, unless StAC is running on godly hardware that can manage to keep the tickrate stable.

But it gets worse - more than 32 players is almost 100% going to result in wacky unexplainable bugs not only in the engine itself but also in StAC and maybe even SourceMod itself.

I can probably stick it behind a cvar similarly to sv_cheats, where I very clearly state "I do not support this and you will be on your own", but that would raise memory usage by almost 300%, so I'm skeptical. However, if people want it, I can do it, but again, you'll be on your own.

awillinger commented 1 year ago

I can probably stick it behind a cvar similarly to sv_cheats, where I very clearly state "I do not support this and you will be on your own", but that would raise memory usage by almost 300%, so I'm skeptical. However, if people want it, I can do it, but again, you'll be on your own.

That would be nice, as I am one person running their server on godly hardware (5950x with a custom kernel). Currently, 33 players with all slots used doesn't really go above 60% (with a lot happening), while the tickrate is pretty much 100% at 66.6-66.7.

As for the bugs - we are used to those, it's the Source engine after all ;)

AgitationSkeleton commented 1 year ago

You're running an outdated version, this is explained better here:

https://github.com/sapphonie/StAC-tf2/blob/master/scripting/stac.sp#L293-L307

StAC doesn't make any sense to run at above 32 players and arguably at above 24, depending on hardware, the engine wasn't designed to iterate through so many clients within a sane amount of time and StAC can't count on receiving at least vaguely consistent data from each player - this is why there is a check for server stuttering every game frame:

https://github.com/sapphonie/StAC-tf2/blob/master/scripting/stac.sp#L223-L240

... and that check will probably just get hit constantly, rendering the plugin mostly useless, unless StAC is running on godly hardware that can manage to keep the tickrate stable.

But it gets worse - more than 32 players is almost 100% going to result in wacky unexplainable bugs not only in the engine itself but also in StAC and maybe even SourceMod itself.

I can probably stick it behind a cvar similarly to sv_cheats, where I very clearly state "I do not support this and you will be on your own", but that would raise memory usage by almost 300%, so I'm skeptical. However, if people want it, I can do it, but again, you'll be on your own.

I think that'd be a fair compromise. I'd like to experiment with higher-count servers, while still trying to avoid aimbotting players as much as possible.

sapphonie commented 1 year ago

Great news, this is now done as of 6.1.0, and it doesn't need a cvar. it also works with sourcemod 1.11. Probably. Try it today!

zxcvqwerasdf commented 6 months ago

I know it's closed, but why not caching cmds, then find artifacts in them? Like obtain 300 ticks, proceed to analyze (not in OnGameFrame), obtain another 300 ticks, analyze, repeat... TF2 server runs on 1 core, so on another core you can analyze obtained ticks without impact server main core. It's theory, but can it be done? Thank you.

sapphonie commented 6 months ago

I know it's closed, but why not caching cmds, then find artifacts in them? Like obtain 300 ticks, proceed to analyze (not in OnGameFrame), obtain another 300 ticks, analyze, repeat... TF2 server runs on 1 core, so on another core you can analyze obtained ticks without impact server main core. It's theory, but can it be done? Thank you.

SourcePawn is single threaded, and multi threading isn't trivial even if I were to port this to a C++ extension.