limiting humans
 

I am using this code to count the number of players + bots on the server
// -----------------------------------------------------------------------
for (client_index = 1; client_index <= gpGlobals->maxClients; client_index++)
{
pPlayer = INDEXENT(client_index);

// skip invalid players
if( FNullEnt(pPlayer) || pPlayer->free || !(pPlayer->v.flags & (FL_CLIENT | FL_FAKECLIENT)))
continue;

if(pPlayer->v.flags & FL_FAKECLIENT)
nbots++;
else
nhumans++;
}


I am using this code to limit the number of humans on the server
// -----------------------------------------------------------------------
BOOL ClientConnect(edict_t *pEntity, const char *pszName, const char *pszAddress, char szRejectReason[128])
{
// is max humans are on
if(nhumans >= (int)CVAR_GET_FLOAT("maxhumans"))
{
// don't allow this human to connect
sprintf (szRejectReason, MESSAGE_REFUSE_CLIENTCONNECT);
RETURN_META_VALUE (MRES_SUPERCEDE, false);
}

RETURN_META_VALUE(MRES_IGNORED, true);
}

Everything works fine except when more then 1 human tries to connect to the server a the same time. This method allows more then maxhumans on since it doesn't take into account players who are in the process of connecting, and not yet flagged as a valid player.

So for example, if maxhumans is set to 5 and there are 4 humans on the server and nhumans is 4 and 2 humans try to connect within a few seconds of each other BOTH will be allowed on.

Does anyone have a clean solution for this?

P.S.
How do I post code examples without it removing my tabs/spaces in front of every line?
Tx

Re: limiting humans
 

i use the code tags?

about your problem, perhaps you can try to intercept a message where the client tries to connect first (so it is NOT yet connected).

Even when this is not possible, you can always check every frame for the latest connected clients and kick the latest one.

So, you keep an own list of pEdicts , you can have a flag for HUMAN/BOT and also a TIME (fTimeConnected). This way you can simply check each frame if you have more then MAXHUMANS set. When to many humans connected anyway, you can kick them with a reason: Too many humans present..

Re: limiting humans
 

hmm you could check in your playercount function if there are to much players and if so kick them there
[edit]
stefan was faster then me :(
[/edit]

Re: limiting humans
 

I was hoping for a non-kludgy way but alas it IS HL programming...
And I was hoping to KEEP them from connecting, instead of kicking them after they connect.

Do you know where the time connected is stored?
Tx.

Re: limiting humans
 

hmm for the time... I think you have to manage that by yourself;
or something like that....

Edit: Yay now im earlier the stefan :)

Re: limiting humans
 

well, i don't know of any in-side-hl variables which hold track of that. Therefor i suggest you keep your own list:

hope it helps, pretty tired. :)

Re: limiting humans
 

There is no non-kludgy way of limiting human connections. The method using ClientConnect is messy because you cannot give the connecting player a reason why their connection failed. The MESSAGE_REFUSE_CLIENTCONNECT does not get displayed in the refusal popup window, and the player is left thinking that there's something wrong with your server.

Quote:

So for example, if maxhumans is set to 5 and there are 4 humans on the server and nhumans is 4 and 2 humans try to connect within a few seconds of each other BOTH will be allowed on.

Change your code so it checks how many humans are in the game during the connection attempt and refuse the connection if the count will be exceeded. I see you may not be doing this, and instead periodically updating a global count (nhumans) which is not in sync with the connection attempts. If you replace nhumans to a function call that counts humans on the fly, your code should work fine.

Re: limiting humans
 

Yes, but it does at least get displayed and you can see it for a few seconds on the screen right after you are disconnected. So this is better then nothing.

I actually do this. The code I posted was simplified. I call a function that counts the number of bots and humans on the server right before I do the check.

The problem is still as described.

In ClientConnect() If more then 1 human tries to connect within a few seconds of each other, they can exceed the allowed maxhumans, because the code that counts the players doesn't take into consideration players who are in the process of connecting but not actually in the game yet.

I guess I could start to kludge it by keeping track of who is connecting over the last several seconds and then watch who actually gets put into the server and track and check all this every few seconds, exactly what I didn't want to do.

As far as the time on the server, HL must keep it somewhere for each player since it is shown for each player in the server tool HLSW (time on for each player is returned by the server "Infostring" command)

Re: limiting humans
 

You could define a time window after which you decide a client who tried to connect through ClientConnect() and who has not yet reached the ClientPutInServer() step is a client who has cancelled connecting, and thus you could move your player count to ClientConnect() instead. It's not a perfect method, but it's better than nothing...

Re: limiting humans
 

I guess you're still using CS 1.5. It's a lot worse in CS 1.6 because you don't see any of the connection messages like you do in CS 1.5.

Yes, you are indeed correct, here's why

Assume MaxHumans = 5 AND there are 4 humans in the game.

If a human tries to connect, ClientConnect() will get called, and the count will return 4 humans in game allowing the player to connect as the 5th human. If another human tries to connect before the first one becomes "valid" and counted, then this human will be allowed in as the 6th human.

The real problem here is that there is no corresponding ClientDisconnect() function to hook onto when a connection attempt is refused. Only Valve can solve this one, so you're left with doing silly coding to solve the problem.

I think the best "solution" is to leave your existing code in place but to also kick out extra humans as soon as they can be detected. Most of the time people will be refused at ClientConnect(), and only the few who slip through the first check will get kicked. These guys can still get a console message informing them why they were kicked just as they do with the refusal.