Makes matches with up to 16 players possible (and a upper limit set to 16 in c++).
Unit Tests Skipped
I think the rmg library has some hardcodings too.
About the xml files with <repeat> tags, the hardcoding can't be avoided unless we add Engine.MatchGetMaxNumberOfPlayers() or similar that defines <repeat n="number"> in some way before the parsing or in the parsing.
Patches that should be committed should be correct and complete. I expect this to break on most random maps and in many GUI pages.
So it would probably be safer to first unify all constants in the engine to support arbitrary numbers and then only expose the > 8 in the UI if the UI and maps support it properly.
Ultimately the maximum number of players should not be limited, so that game designers can use the Pyrogenesis engine for any games they come up with.
I see that you chose 32, since the RangeManager is limited to that, so that may be an improvement already.
The real question is whether those are all files that need this change (I wouldn't be surprised if there are many more cpp files surrounding the RangeManager or anything else that stores values depending on playerID).
|5 ↗||(On Diff #6957)|
This should be received from the engine, through JSInterface_... probably the Game one
|106 ↗||(On Diff #6957)|
100% height if this has to be changed
|39 ↗||(On Diff #6957)|
<!-- MaxPlayers --> so people find it when editing it. (Would be ideal to have this a constant somewhere that is filled in in the C++/XML engine)
If the engine already supports 16 max, then it should be documented well and propagated. New sim components should be written without being possible to assume that its max 8.
About exposing this to the players, I'm not sure, it would have to be very polished.
Currently 2-8 players is well known to produce good results, we don't to water down the experience.
It should be tested well that 16 max doesn't produce less entertaining results (not only random maps, but the entire match experience).
I'm sure it will work for 10 players max ingame, not sure about the dialog boxes. Beyond that it would require some testing to see if there are some problems or quality loss arising.
For example the current team chat is already difficult, how are players supposed to communicate with that many players.
(Pyrogenesis should support limit removals for sure, but increasing max for 0 A.D. needs separate consideration.)
|5 ↗||(On Diff #6957)|
The important part is that devs dont think they can just replace this one variable and their task is done.
|1083 ↗||(On Diff #6961)|
Can you show a screenshot how the gamesetup looks with 1024*768 for 16 playerslots with this patch?
Don't think it should. Here 32 is used because it's u32. It's also not 2 * max number of players, but it should be capped by max_players.
As mentioned in the lobby, you have to keep in mind the territory manager limitation. Posting here just for the record.
I guess that is Gaia + 31 players.
Seems m_Territories only gives 4 bits to player ID mask (owner value) , which was defined originally as a player_id_t (uint_32) in CCmpRangeMangaer.cpp giving the false impression that there can be 30 players.
In the end the maximum number of players seems to still be 8 with no margin for more due all player ID masking done with uint8 or uin16 depending of the case.
I think that as long as all data of each player is stored/packed into a single value it will not be really possible to do anything more given the current implementation.