garrysmod-requests
garrysmod-requests copied to clipboard
Facepunch
Increase player limit 256
The engines limit is 256 so there's no reason the game should be limited to 128 when servers are pushing 128 with headroom to spare.
The engine's limit definitely isn't 256. I think Valve's server list has a cap of 256 player slots though.
I've always been told it was. I know people have made modules to unlimit maxplayers but clients would crash instantly presumably due to something internal.
I'm guessing it's from the MAX_PLAYERS preprocess definition, which is heavily used for setting max network array sizes, so if you had more, it would overrun the memory. MAX_PLAYERS is set to 32 in the 2007 branch, but changed to 64 for CS:S, so I'm assuming that is the only thing that needs to be bumped up.
If the code was kept consistent with that definition, it seems like the original intention was for anyone to change that to add more players:
// The Source engine is really designed for 32 or less players. If you raise this number above 32, you better know what you are doing // and have a good answer for a bunch of perf question related to player simulation, thinking logic, tracelines, networking overhead, etc. // But if you are brave or are doing something interesting, go for it... ywb 9/22/03
Obviously with efficiency concerns, but it's intended to have a max of 255:
#define ABSOLUTE_PLAYER_LIMIT 255 // not 256, so we can send the limit as a byte
This is possible, but if we did this have you thought about if the source engine could even handle this, plus how do we know the game wont become unstable
Im not saying this is a bad idea im just saying that you should look into it befor asking on the request board.
Just think-to yourself. is this possible
Will this ever be added in nativly? I'm apparently unable to force it to 255 myself. Would be nice to be able to especially with the x64 branch coming up. aswell valve confirms its possible already :p https://developer.valvesoftware.com/wiki/Maxplayers
Any news on this one? It is possible to do this with dll injection, so I guess it is just the stability concerns and lack of interest that cause this not to be included. 255 players as a limit would certainly be used sparsely, but the few servers that utilized it right would be surely offer a great experience.
you'd need more than just dll injection. iirc the serverbrowser is also an enemy of this aswell. I believe it basically drops anything that tries to list itself above 128 even if it actually could hold that many. least thats how things went when I was tinkering around with some things
The engine's limit definitely isn't 256. I think Valve's server list has a cap of 256 player slots though.
unfortunately, it is. not technically but it is. alot of source's code is bound to max 128 players and player ids get written as bytes always
As far as I know, only the MAX_PLAYERS var would need to be raised to 255.
It could cause some Issues and some bugs, but it would be useful for some servers.
Currently, if you use tv_enable 1 and have maxplayers set to 128 you will end up having 129 slots which cause a crash for the client.
I guess now we wait till it gets updated to 255 or rubat denies us again
Maybe this could for now be implemented like tf2 did it with -unrestricted_maxplayers but for Gmod it could allow one to go up to 255.
This would allow Servers who want more than 128 slots to have more, but Gmod wouldn't actively support it like tf2:
How it could be implemented:
// game/shared/shareddefs.h
#define MAX_PLAYERS 255 // Raised to 255
#define SUPPORTED_MAX_PLAYERS 128
// game/server/hl2mp_gameinferface.cpp
void CServerGameClients::GetPlayerLimits( int& minplayers, int& maxplayers, int &defaultMaxPlayers ) const
{
minplayers = defaultMaxPlayers = 1;
int unrestricted_maxplayers = CommandLine()->ParmValue( "-unrestricted_maxplayers", -1 );
if (unrestricted_maxplayers == -1) {
maxplayers = SUPPORTED_MAX_PLAYERS
} else {
maxplayers = clamp( unrestricted_maxplayers, minplayers, MAX_PLAYER );
}
}
NOTE: If this is implemented all Gmod branches should get updated because if for example the server is running on the dev branch and a client joins, the client will crash because of MAX_PLAYERS being different/the client will crash because the server has a higher MAX_PLAYERS
This would be by far the most insane game changing feature to add to Gmod a real dream for all player & server owner
This might be a bad idea because source is a bad engine. This might introduce countless bugs, many of which will be potentially critical vulnerabilities (i.e. OOB r/w, etc), because of hardcoded stuff in the engine. It might be a little bit of a stretch here, but... Seriously, its not worth the trouble. Not a lot of servers will even be able to run that much at all.
The engine (the engine.dll) wouldn't even need to be modified, as it already supports up to 255 players.
Only the client and server dlls would need to be updated, everything in those dll's should use
MAX_PLAYERS which also makes raising it easy without those potential issues.
TF2 did raise it for them from 33 to 101 seemingly without any huge problems, but they did implement MAX_PLAYERS_ARRAY_SAFE for further safety -> https://github.com/RaphaelIT7/obsolete-source-engine/commit/d27156314e61220dc0a5eec06c6278c2dc6f7429 (it might be missing some things so it should be double checked)
And yes, it might also introduce bugs, that's why I also proposed the -unrestricted_maxplayers option, so people can test/use it if they want, and if not, they'll be back stuck at the 128 players, and anything that's hardcoded (if there even is anything that isn't using MAX_PLAYERS) to 128 players shouldn't break.
And even if there still are any concerns for bugs/security, then make a new branch with the change and let people test it for 6 months, that would at least be better than having this request sit here idle to then one day be implemented with the next net-compact changes, which usually give only 1-2 weeks to test before they are released.
Side note
source is a bad engine
Source isn't that bad :)
Trust me, you never actually know when something will or will not cause a bug(or a vulnerability) in this engine. You just never know of all the assumptions made in this engine in all >20 years of its existence and development. Maybe there is a pesky bitshift somewhere, maybe there is a hardcoded array based on player count, and all of that stuff. I have seen it, i have dealt with it, i know what i am talking about. Even if you would try to release it into testing to find out if there are any bugs, even for a long period of time, some stuff can just go unnoticed. Just an example: setting a certain bitflag caused type confusion (with a virtual call), exploitable via heap feng shui before. This went unnoticed for years.
Source engine is a giant, bulky piece of code, written in god knows what conditions by tons of people (some not very proficient). This is why, in fact, i call it a bad engine.
RaphaelIT7 solution with -unstable input for starting and let server / dev manage their shit but allow this possibility will be big motivation for community work & hype
Any chance we can get this now? Since net compat update is coming @robotboy655
