Closed AgitationSkeleton closed 11 months 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 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 ;)
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.
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!
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.
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.
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.