MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000770Zandronum[All Projects] Suggestionpublic2012-04-14 20:592018-09-30 19:52
ReporterWatermelon 
Assigned ToTorr Samaho 
PrioritynormalSeveritytweakReproducibilityN/A
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version98d 
Target VersionFixed in Version1.0 
Summary0000770: Raising player cap (to 64 or 255)
DescriptionOdamex has the ability to get to 255 players.

Skulltag is quite limited, 32 is not enough players for mods anymore. We NEED 64 players at least. There's times in AOW, GVH...etc, where we have people on IRC going "please let me in", and for admins to get in to deal with players, we have to actually kick people out just to get in (ignoring remote connect, but I don't like that method unless I've got no choice).

As the biggest and most advanced multiplayer port in skulltag, we should probably have more support for more players. So far IIRC we have the least (Oda 255, ZD 50).

I don't know if it's too difficult to add 64 player support. With games like GVH, AOW...etc, they can handle 32 people no problem.

Plus we're the only port who can actually attain >32 players, yet were the one with the lowest cap.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0000945closed Torr Samaho Random Number Generator compatflag freezes the server 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-04-14 20:59WatermelonNew Issue
2012-04-14 21:01WatermelonNote Added: 0003253
2012-04-14 21:06Torr SamahoNote Added: 0003255
2012-04-14 21:49QentNote Added: 0003257
2012-04-14 21:55WatermelonNote Added: 0003258
2012-04-15 02:19Torr SamahoNote Added: 0003267
2012-04-15 05:23MP2ENote Added: 0003274
2012-04-15 11:26HisymakNote Added: 0003281
2012-04-15 17:17DuskNote Added: 0003289
2012-04-15 17:18DuskNote Edited: 0003289bug_revision_view_page.php?bugnote_id=3289#r1749
2012-04-15 21:23MinigunnerNote Added: 0003304
2012-04-15 21:27MinigunnerNote Edited: 0003304bug_revision_view_page.php?bugnote_id=3304#r1753
2012-04-21 23:06MediumTankNote Added: 0003371
2012-04-21 23:17Torr SamahoNote Added: 0003372
2012-04-21 23:29Torr SamahoNote Added: 0003374
2012-04-22 00:11MediumTankNote Added: 0003376
2012-04-22 00:11MediumTankNote Edited: 0003376bug_revision_view_page.php?bugnote_id=3376#r1794
2012-04-22 00:12MediumTankNote Edited: 0003376bug_revision_view_page.php?bugnote_id=3376#r1795
2012-04-22 00:13MediumTankNote Edited: 0003376bug_revision_view_page.php?bugnote_id=3376#r1796
2012-04-22 01:20MediumTankNote Edited: 0003376bug_revision_view_page.php?bugnote_id=3376#r1797
2012-04-22 01:37Torr SamahoNote Added: 0003378
2012-04-23 16:36MediumTankNote Added: 0003405
2012-04-23 16:36MediumTankNote Edited: 0003405bug_revision_view_page.php?bugnote_id=3405#r1814
2012-04-23 16:37MediumTankNote Edited: 0003405bug_revision_view_page.php?bugnote_id=3405#r1815
2012-04-23 16:38MediumTankNote Edited: 0003405bug_revision_view_page.php?bugnote_id=3405#r1816
2012-04-23 16:39MediumTankNote Edited: 0003405bug_revision_view_page.php?bugnote_id=3405#r1817
2012-04-23 16:39MediumTankNote Edited: 0003405bug_revision_view_page.php?bugnote_id=3405#r1818
2012-04-23 16:41MediumTankNote Edited: 0003405bug_revision_view_page.php?bugnote_id=3405#r1819
2012-04-23 16:42MediumTankNote Edited: 0003405bug_revision_view_page.php?bugnote_id=3405#r1820
2012-04-23 17:20TIHanNote Added: 0003406
2012-04-23 17:20TIHanNote Edited: 0003406bug_revision_view_page.php?bugnote_id=3406#r1822
2012-04-24 00:10TIHanNote Added: 0003408
2012-04-24 00:45Torr SamahoNote Added: 0003411
2012-04-24 00:45Torr SamahoNote Edited: 0003411bug_revision_view_page.php?bugnote_id=3411#r1826
2012-04-24 00:46Torr SamahoNote Revision Dropped: 3411: 0001825
2012-04-24 05:08DevilHunterNote Added: 0003414
2012-06-05 23:19MinigunnerNote Added: 0003680
2012-06-09 13:08Torr SamahoNote Added: 0003702
2012-07-17 21:38TosenNote Added: 0004010
2012-07-18 23:11Edward-sanNote Added: 0004014
2012-07-19 01:22IvanNote Added: 0004015
2012-07-21 16:43bluewizardNote Added: 0004017
2012-07-21 18:13Torr SamahoNote Added: 0004018
2012-07-22 09:46Torr SamahoNote Added: 0004029
2012-07-22 09:46Torr SamahoAssigned To => Torr Samaho
2012-07-22 09:46Torr SamahoStatusnew => needs testing
2012-08-02 14:01WatermelonNote Added: 0004200
2012-08-02 19:28Torr SamahoRelationship addedparent of 0000945
2012-08-02 19:30Torr SamahoNote Added: 0004208
2012-08-02 19:31Torr SamahoRelationship deletedparent of 0000945
2012-08-02 19:31Torr SamahoRelationship addedrelated to 0000945
2012-08-02 19:31Torr SamahoStatusneeds testing => resolved
2012-08-02 19:31Torr SamahoFixed in Version => 1.0
2012-08-02 19:31Torr SamahoResolutionopen => fixed
2018-09-30 19:52Blzut3Statusresolved => closed

Notes
(0003253)
Watermelon   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
2012-04-21 23:17   
Ok, I'll supply you with a Windows binary with MAXPLAYERS set to 64.
(0003374)
Torr Samaho   
2012-04-21 23:29   
Here you go.
(0003376)
MediumTank   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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.