0000770: Raising player cap (to 64 or 255)

(0003253)
Watermelon (developer)
2012-04-14 21:01

As a side note, it would only need a player cap raise, as most major games are actually Red Team Start vs Blue Team Start, meaning we don't need more Player X starts, but just support for more players to join a team.

(0003255)
Torr Samaho (administrator)
2012-04-14 21:06

Technically raising the player limit to up to 255 is not really difficult (it's just changing the MAXPLAYERS define from 32 to whatever value smaller or equal to 255 you would like to have), bandwidth usage will be enormous though and it's very difficult to test since you needs so many players...

(0003257)
Qent (updater)
2012-04-14 21:49

I don't see bandwidth as a serious problem, provided:
* It doesn't hurt clients
* It doesn't hurt servers who keep sv_maxplayers at 32

(0003258)
Watermelon (developer)
2012-04-14 21:55

Is it possible to make a new cvar like sv_maxplayerslots true/false which enables 64 player usage?

Where is the define for MAXPLAYERS in the skulltag source? I might try a build and see if I can get >32 people in to find out how it's handled.

So far though all the massive multiplayer wads run perfectly at 32 players, when I play on them I don't notice much lag at all -- I think it depends on if the wad is putting out too much information or not.

(0003267)
Torr Samaho (administrator)
2012-04-15 02:19

> Where is the define for MAXPLAYERS in the skulltag source? I might try a build and see if I can get >32 people in to find out how it's handled.

In doomdef.h. Both, clients and server need binaries with the increased limit. If you are willing to organize testing with at least 33 players I could possibly make a official beta build with an increased MAXPLAYERS value.

(0003274)
MP2E (reporter)
2012-04-15 05:23

The only way I can see us getting over 32 players is by advertising a lot and getting a server cluster to host something that a large amount of players will flock to, but I am completely in for testing this and for it being implemented.

I think it will work rather well, and if not it's another good stress-test for the netcode ;)

(0003281)
Hisymak (reporter)
2012-04-15 11:26

I agree with increasing max players. But you must be aware that having more than 32 players may be incompatible with some mods.
Many scripts use arrays with size of 32 to store some variable for each player.
Example: int player_variable [32]
And the variable is accessed with something like this: player_variable [ playerNumber() ]
If there is more than 32 players, then the array boundary is exceeded and this can cause problems.
So server hosts who host incompatible wads must not allow more than 32 players or wad authors must modify their scripts and increase size of those arrays.

(0003289)
Dusk (developer)
2012-04-15 17:17
edited on: 2012-04-15 17:18

IMO sv_maxplayers/clients should definitely default to 32, no matter what. Server hosts can increase it if they so desire.

(0003304)
Minigunner (reporter)
2012-04-15 21:23
edited on: 2012-04-15 21:27

IMO sv_maxclients' maximum should be 255, while sv_maxplayers' should be 64. Along with that, the default sv_maxclients should be 64, and sv_maxplayers 32.
However, one major issue with this playerbaseincrease is the size of many multiplayer maps. The majority of them can accommodate up to 16 players without a significant decrease in gameplay speed, but not more. As a result, larger mappacks would have to be created just for such a large amount of players (said maps would have to be larger than AOW2 maps).

(0003371)
MediumTank (reporter)
2012-04-21 23:06

Get me a build with 64+ MAXPLAYERS (compiling it on my own with the latest source isn't working for me for some reason), and I'll get 33+ people to test it. I need someone to provide me with the build though.

(0003372)
Torr Samaho (administrator)
2012-04-21 23:17

Ok, I'll supply you with a Windows binary with MAXPLAYERS set to 64.

(0003374)
Torr Samaho (administrator)
2012-04-21 23:29

Here you go.

(0003376)
MediumTank (reporter)
2012-04-22 00:11
edited on: 2012-04-22 01:20

Is it possible to raise sv_maxclientsperip to 64? ** NOTE: It wont let me go above 32, is that something that needs to be raised in the build?

I'm testing this over a LAN with people at my school... fastest way I can get 33+ people. It's treating us as one IP. I'll be playing from a non-LAN game. No one I knew in the ST community at the moment was willing to help test the new 98e build... but maybe tomorrow I can mix up some LAN partners with non-LAN players.

Good news is that Doomseeker and IDE had no problems showing that there is 64 people, the release should work with server listing clients.

I'd have the results for you but my results will be limited to 33+ players from my class, and hopefully afterwars some more.

I'm hoping to pull 38 people, and then just connect more times via my own machine to attempt to get near 64.

(0003378)
Torr Samaho (administrator)
2012-04-22 01:37

> Is it possible to raise sv_maxclientsperip to 64? ** NOTE: It wont let me go above 32, is that something that needs to be raised in the build?

You should be able to set it to any number you like.

(0003405)
MediumTank (reporter)
2012-04-23 16:36
edited on: 2012-04-23 16:42

It worked, just for some reason on the clients when you try to set sv_maxplayers, sv_maxclients and sv_maxclientsperip to 64, for some reason the third one returns as 32 even though it is 64 on the server.

While it would be nice to have 64 players, is there anyway to mitigate the insane bandwidth usage?

38 players gave us approx 300 kb/s in outbound traffic from the server, and that was for regular deathmatch with no monsters on D2M1. That was from the server though... does that mean its sending 300 kb/s to each player? or 300 kb/s divided by # of players?
Just because for major servers like Grandvoid and such, they won't have a problem with sending that much data as long as the clients aren't getting flooded by it. I figure if its per player, 300 kb/s / 38 players = approx 8 kb/s for each player, which contains 38 player data (/ another 38) = 0.2kb/s of data per player.

If thats the case, then the basic output for a 64 player server should be around 820 kb/s serverside.

I tried sv_measureoutboundtraffic true and dumptrafficmeasure but no text seemed to show up on my client(s). The server also set it to true.

(0003406)
TIHan (reporter)
2012-04-23 17:20
edited on: 2012-04-23 17:20

> or 300 kb/s divided by # of players?

It is estimated at that, yes.

> is there anyway to mitigate the insane bandwidth usage?

Maybe. We want player positions be to accurate as possible. Not sure how we can handle it at the moment. I would say we could decrease some usage based on the bandwidth patch me and Torr did for monsters, but I'm unsure if that is even remotely compatible with players. More research is needed.

(0003408)
TIHan (reporter)
2012-04-24 00:10

Using 31 bots and including myself. I can average about 10 to 12 kb/sec with cl_ticsperupdate set to 3. If they were 31 clients, it would be about 300kb/sec outbound. The only way to mitigate this is to forcefully decrease the number of ticsperupdate which is probably a bad idea considering players will be jumping all over the screen.

(0003411)
Torr Samaho (administrator)
2012-04-24 00:45
edited on: 2012-04-24 00:45

> While it would be nice to have 64 players, is there anyway to mitigate the insane bandwidth usage?

By design the necessary outbound server bandwidth scales quadratically with the number of players (which is the reason why the player limit is or was 32). The only way to reduce it, is to deliberately not send the clients information they need to properly display the game state. You can try to cleverly omit information they need, but in the worst case, there will be visual errors on the clients if you do so. The more bandwidth you forcefully save, the more severe the visual problems will be.

(0003414)
DevilHunter (reporter)
2012-04-24 05:08

> I tried sv_measureoutboundtraffic true and dumptrafficmeasure but no text seemed to show up on my client(s). The server also set it to true.

Those cmds only work in the Server Console. Type DumpTrafficMeasure in the Server console, and it should spit out some info.

As for this Suggestion, I'm not sure if more then 32 players at a time would play well on AoW. I, ofc, played on a 32 player match before, it was intense enough. But after hearing that the PS3 can handle 255 players, (I think that is what they said,) then by all means I guess Skulltag can too.

TBH though, I don't think there was ever a 255 player game before on Odamex.

(0003680)
Minigunner (reporter)
2012-06-05 23:19

Now that we forked off of Skulltag, do you think this would be a good time to increase the max player limit and put some testing into it?

(0003702)
Torr Samaho (administrator)
2012-06-09 13:08

The fork makes changing this neither easier nor more difficult. If you want this to be included, we need more feedback based on the testing build I posted in this ticket.

(0004010)
Tosen (reporter)
2012-07-17 21:38

I agree with this. Now that StrParam is supported and variables can be saved, large player numbers could mean awesome doom MMORPGS :p

(0004014)
Edward-san (developer)
2012-07-18 23:11

but still, what about scripted wads which always assume that 32 is the max number of the players?

(0004015)
Ivan (reporter)
2012-07-19 01:22

A compatflag would save the day for them. If there are modern mods which do that, they should adapt for compatibility if they so want to have more than 32 players.

(0004017)
bluewizard (reporter)
2012-07-21 16:43

A compat flag shouldn't be needed, the hoster would just need to make the join limit 32, no?

Perhaps a message should pop-up saying going above 32 players isn't recommended for mods that have not been updated as of "XX/XX/XXXX"?

(0004018)
Torr Samaho (administrator)
2012-07-21 18:13

Yes, just keep sv_maxclients and sv_maxplayers at 32 or less and there is no need for a compat flag.

(0004029)
Torr Samaho (administrator)
2012-07-22 09:46

I did some testing with about 50 bots and didn't notice any problems. Thus I raised the limit to 64 in the source repository. Please test this thoroughly in the next beta build. If serious problems are discovered that are too difficult to be fixed quickly, we can still revert the limit to 32 for the release of 1.0.

(0004200)
Watermelon (developer)
2012-08-02 14:01

Confirmed to work online with >33 players. I tested with players and bots because I realistically can't get 33+ players on the fly, but I did get player numbers > 33 and they rendered right, and showed up on the menu fine with no bugs.

(0004208)
Torr Samaho (administrator)
2012-08-02 19:30

After seeing 0000945 I fear that the raised player limit may have introduced more problems that only occur under certain circumstances. Any additional testing put in the new build is highly welcome. Even if you just try a few of your favorite mods with it, this would help.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	ZzZombo Minigunner Jonathan
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2012-04-14 20:59	Watermelon	New Issue
2012-04-14 21:01	Watermelon	Note Added: 0003253
2012-04-14 21:06	Torr Samaho	Note Added: 0003255
2012-04-14 21:49	Qent	Note Added: 0003257
2012-04-14 21:55	Watermelon	Note Added: 0003258
2012-04-15 02:19	Torr Samaho	Note Added: 0003267
2012-04-15 05:23	MP2E	Note Added: 0003274
2012-04-15 11:26	Hisymak	Note Added: 0003281
2012-04-15 17:17	Dusk	Note Added: 0003289
2012-04-15 17:18	Dusk	Note Edited: 0003289	View Revisions
2012-04-15 21:23	Minigunner	Note Added: 0003304
2012-04-15 21:27	Minigunner	Note Edited: 0003304	View Revisions
2012-04-21 23:06	MediumTank	Note Added: 0003371
2012-04-21 23:17	Torr Samaho	Note Added: 0003372
2012-04-21 23:29	Torr Samaho	Note Added: 0003374
2012-04-22 00:11	MediumTank	Note Added: 0003376
2012-04-22 00:11	MediumTank	Note Edited: 0003376	View Revisions
2012-04-22 00:12	MediumTank	Note Edited: 0003376	View Revisions
2012-04-22 00:13	MediumTank	Note Edited: 0003376	View Revisions
2012-04-22 01:20	MediumTank	Note Edited: 0003376	View Revisions
2012-04-22 01:37	Torr Samaho	Note Added: 0003378
2012-04-23 16:36	MediumTank	Note Added: 0003405
2012-04-23 16:36	MediumTank	Note Edited: 0003405	View Revisions
2012-04-23 16:37	MediumTank	Note Edited: 0003405	View Revisions
2012-04-23 16:38	MediumTank	Note Edited: 0003405	View Revisions
2012-04-23 16:39	MediumTank	Note Edited: 0003405	View Revisions
2012-04-23 16:39	MediumTank	Note Edited: 0003405	View Revisions
2012-04-23 16:41	MediumTank	Note Edited: 0003405	View Revisions
2012-04-23 16:42	MediumTank	Note Edited: 0003405	View Revisions
2012-04-23 17:20	TIHan	Note Added: 0003406
2012-04-23 17:20	TIHan	Note Edited: 0003406	View Revisions
2012-04-24 00:10	TIHan	Note Added: 0003408
2012-04-24 00:45	Torr Samaho	Note Added: 0003411
2012-04-24 00:45	Torr Samaho	Note Edited: 0003411	View Revisions
2012-04-24 00:46	Torr Samaho	Note Revision Dropped: 3411: 0001825
2012-04-24 05:08	DevilHunter	Note Added: 0003414
2012-06-05 23:19	Minigunner	Note Added: 0003680
2012-06-09 13:08	Torr Samaho	Note Added: 0003702
2012-07-17 21:38	Tosen	Note Added: 0004010
2012-07-18 23:11	Edward-san	Note Added: 0004014
2012-07-19 01:22	Ivan	Note Added: 0004015
2012-07-21 16:43	bluewizard	Note Added: 0004017
2012-07-21 18:13	Torr Samaho	Note Added: 0004018
2012-07-22 09:46	Torr Samaho	Note Added: 0004029
2012-07-22 09:46	Torr Samaho	Assigned To	=> Torr Samaho
2012-07-22 09:46	Torr Samaho	Status	new => needs testing
2012-08-02 14:01	Watermelon	Note Added: 0004200
2012-08-02 19:28	Torr Samaho	Relationship added	parent of 0000945
2012-08-02 19:30	Torr Samaho	Note Added: 0004208
2012-08-02 19:31	Torr Samaho	Relationship deleted	parent of 0000945
2012-08-02 19:31	Torr Samaho	Relationship added	related to 0000945
2012-08-02 19:31	Torr Samaho	Status	needs testing => resolved
2012-08-02 19:31	Torr Samaho	Fixed in Version	=> 1.0
2012-08-02 19:31	Torr Samaho	Resolution	open => fixed
2018-09-30 19:52	Blzut3	Status	resolved => closed

Notes
(0003253) Watermelon (developer) 2012-04-14 21:01	As a side note, it would only need a player cap raise, as most major games are actually Red Team Start vs Blue Team Start, meaning we don't need more Player X starts, but just support for more players to join a team.

(0003255) Torr Samaho (administrator) 2012-04-14 21:06	Technically raising the player limit to up to 255 is not really difficult (it's just changing the MAXPLAYERS define from 32 to whatever value smaller or equal to 255 you would like to have), bandwidth usage will be enormous though and it's very difficult to test since you needs so many players...

(0003257) Qent (updater) 2012-04-14 21:49	I don't see bandwidth as a serious problem, provided: * It doesn't hurt clients * It doesn't hurt servers who keep sv_maxplayers at 32

(0003258) Watermelon (developer) 2012-04-14 21:55	Is it possible to make a new cvar like sv_maxplayerslots true/false which enables 64 player usage? Where is the define for MAXPLAYERS in the skulltag source? I might try a build and see if I can get >32 people in to find out how it's handled. So far though all the massive multiplayer wads run perfectly at 32 players, when I play on them I don't notice much lag at all -- I think it depends on if the wad is putting out too much information or not.

(0003267) Torr Samaho (administrator) 2012-04-15 02:19	> Where is the define for MAXPLAYERS in the skulltag source? I might try a build and see if I can get >32 people in to find out how it's handled. In doomdef.h. Both, clients and server need binaries with the increased limit. If you are willing to organize testing with at least 33 players I could possibly make a official beta build with an increased MAXPLAYERS value.

(0003274) MP2E (reporter) 2012-04-15 05:23	The only way I can see us getting over 32 players is by advertising a lot and getting a server cluster to host something that a large amount of players will flock to, but I am completely in for testing this and for it being implemented. I think it will work rather well, and if not it's another good stress-test for the netcode ;)

(0003281) Hisymak (reporter) 2012-04-15 11:26	I agree with increasing max players. But you must be aware that having more than 32 players may be incompatible with some mods. Many scripts use arrays with size of 32 to store some variable for each player. Example: int player_variable [32] And the variable is accessed with something like this: player_variable [ playerNumber() ] If there is more than 32 players, then the array boundary is exceeded and this can cause problems. So server hosts who host incompatible wads must not allow more than 32 players or wad authors must modify their scripts and increase size of those arrays.

(0003289) Dusk (developer) 2012-04-15 17:17 edited on: 2012-04-15 17:18	IMO sv_maxplayers/clients should definitely default to 32, no matter what. Server hosts can increase it if they so desire.

(0003304) Minigunner (reporter) 2012-04-15 21:23 edited on: 2012-04-15 21:27	IMO sv_maxclients' maximum should be 255, while sv_maxplayers' should be 64. Along with that, the default sv_maxclients should be 64, and sv_maxplayers 32. However, one major issue with this playerbaseincrease is the size of many multiplayer maps. The majority of them can accommodate up to 16 players without a significant decrease in gameplay speed, but not more. As a result, larger mappacks would have to be created just for such a large amount of players (said maps would have to be larger than AOW2 maps).

(0003371) MediumTank (reporter) 2012-04-21 23:06	Get me a build with 64+ MAXPLAYERS (compiling it on my own with the latest source isn't working for me for some reason), and I'll get 33+ people to test it. I need someone to provide me with the build though.

(0003372) Torr Samaho (administrator) 2012-04-21 23:17	Ok, I'll supply you with a Windows binary with MAXPLAYERS set to 64.

(0003374) Torr Samaho (administrator) 2012-04-21 23:29	Here you go.

(0003376) MediumTank (reporter) 2012-04-22 00:11 edited on: 2012-04-22 01:20	Is it possible to raise sv_maxclientsperip to 64? ** NOTE: It wont let me go above 32, is that something that needs to be raised in the build? I'm testing this over a LAN with people at my school... fastest way I can get 33+ people. It's treating us as one IP. I'll be playing from a non-LAN game. No one I knew in the ST community at the moment was willing to help test the new 98e build... but maybe tomorrow I can mix up some LAN partners with non-LAN players. Good news is that Doomseeker and IDE had no problems showing that there is 64 people, the release should work with server listing clients. I'd have the results for you but my results will be limited to 33+ players from my class, and hopefully afterwars some more. I'm hoping to pull 38 people, and then just connect more times via my own machine to attempt to get near 64.

(0003378) Torr Samaho (administrator) 2012-04-22 01:37	> Is it possible to raise sv_maxclientsperip to 64? ** NOTE: It wont let me go above 32, is that something that needs to be raised in the build? You should be able to set it to any number you like.

(0003405) MediumTank (reporter) 2012-04-23 16:36 edited on: 2012-04-23 16:42	It worked, just for some reason on the clients when you try to set sv_maxplayers, sv_maxclients and sv_maxclientsperip to 64, for some reason the third one returns as 32 even though it is 64 on the server. While it would be nice to have 64 players, is there anyway to mitigate the insane bandwidth usage? 38 players gave us approx 300 kb/s in outbound traffic from the server, and that was for regular deathmatch with no monsters on D2M1. That was from the server though... does that mean its sending 300 kb/s to each player? or 300 kb/s divided by # of players? Just because for major servers like Grandvoid and such, they won't have a problem with sending that much data as long as the clients aren't getting flooded by it. I figure if its per player, 300 kb/s / 38 players = approx 8 kb/s for each player, which contains 38 player data (/ another 38) = 0.2kb/s of data per player. If thats the case, then the basic output for a 64 player server should be around 820 kb/s serverside. I tried sv_measureoutboundtraffic true and dumptrafficmeasure but no text seemed to show up on my client(s). The server also set it to true.

(0003406) TIHan (reporter) 2012-04-23 17:20 edited on: 2012-04-23 17:20	> or 300 kb/s divided by # of players? It is estimated at that, yes. > is there anyway to mitigate the insane bandwidth usage? Maybe. We want player positions be to accurate as possible. Not sure how we can handle it at the moment. I would say we could decrease some usage based on the bandwidth patch me and Torr did for monsters, but I'm unsure if that is even remotely compatible with players. More research is needed.

(0003408) TIHan (reporter) 2012-04-24 00:10	Using 31 bots and including myself. I can average about 10 to 12 kb/sec with cl_ticsperupdate set to 3. If they were 31 clients, it would be about 300kb/sec outbound. The only way to mitigate this is to forcefully decrease the number of ticsperupdate which is probably a bad idea considering players will be jumping all over the screen.

(0003411) Torr Samaho (administrator) 2012-04-24 00:45 edited on: 2012-04-24 00:45	> While it would be nice to have 64 players, is there anyway to mitigate the insane bandwidth usage? By design the necessary outbound server bandwidth scales quadratically with the number of players (which is the reason why the player limit is or was 32). The only way to reduce it, is to deliberately not send the clients information they need to properly display the game state. You can try to cleverly omit information they need, but in the worst case, there will be visual errors on the clients if you do so. The more bandwidth you forcefully save, the more severe the visual problems will be.

(0003414) DevilHunter (reporter) 2012-04-24 05:08	> I tried sv_measureoutboundtraffic true and dumptrafficmeasure but no text seemed to show up on my client(s). The server also set it to true. Those cmds only work in the Server Console. Type DumpTrafficMeasure in the Server console, and it should spit out some info. As for this Suggestion, I'm not sure if more then 32 players at a time would play well on AoW. I, ofc, played on a 32 player match before, it was intense enough. But after hearing that the PS3 can handle 255 players, (I think that is what they said,) then by all means I guess Skulltag can too. TBH though, I don't think there was ever a 255 player game before on Odamex.

(0003680) Minigunner (reporter) 2012-06-05 23:19	Now that we forked off of Skulltag, do you think this would be a good time to increase the max player limit and put some testing into it?

(0003702) Torr Samaho (administrator) 2012-06-09 13:08	The fork makes changing this neither easier nor more difficult. If you want this to be included, we need more feedback based on the testing build I posted in this ticket.

(0004010) Tosen (reporter) 2012-07-17 21:38	I agree with this. Now that StrParam is supported and variables can be saved, large player numbers could mean awesome doom MMORPGS :p

(0004014) Edward-san (developer) 2012-07-18 23:11	but still, what about scripted wads which always assume that 32 is the max number of the players?

(0004015) Ivan (reporter) 2012-07-19 01:22	A compatflag would save the day for them. If there are modern mods which do that, they should adapt for compatibility if they so want to have more than 32 players.

(0004017) bluewizard (reporter) 2012-07-21 16:43	A compat flag shouldn't be needed, the hoster would just need to make the join limit 32, no? Perhaps a message should pop-up saying going above 32 players isn't recommended for mods that have not been updated as of "XX/XX/XXXX"?

(0004018) Torr Samaho (administrator) 2012-07-21 18:13	Yes, just keep sv_maxclients and sv_maxplayers at 32 or less and there is no need for a compat flag.

(0004029) Torr Samaho (administrator) 2012-07-22 09:46	I did some testing with about 50 bots and didn't notice any problems. Thus I raised the limit to 64 in the source repository. Please test this thoroughly in the next beta build. If serious problems are discovered that are too difficult to be fixed quickly, we can still revert the limit to 32 for the release of 1.0.

(0004200) Watermelon (developer) 2012-08-02 14:01	Confirmed to work online with >33 players. I tested with players and bots because I realistically can't get 33+ players on the fly, but I did get player numbers > 33 and they rendered right, and showed up on the menu fine with no bugs.

(0004208) Torr Samaho (administrator) 2012-08-02 19:30	After seeing 0000945 I fear that the raised player limit may have introduced more problems that only occur under certain circumstances. Any additional testing put in the new build is highly welcome. Even if you just try a few of your favorite mods with it, this would help.