Enlarging the space for init string? Or new server info publishing system?

[Gig]

Just a thing I suggest you developers to think about, when the protocol will be changed for any other reason (I suppose this may imply a protocol change, but it is not enough to justify a protol change all alone... but maybe, at the same time of other changes...): I was wondering if it could be possible to enlarge the space available for the "sets" variables (those the server admin can use to give informations about his server -very useful-, see also (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Command_console#Set_variables).

I have done some tests, and at the moment, it seems to me too easy to hit that limit! I haven't calculated exactly how long a single variable can be, and how many characters the info string can contain before you get "info string length exceeded" error when starting your server or using the "serverinfo" command, but the proportion seems unfair anyway: I think that the info string should be able to contain some variables at their maximum lenght....

I don't know what that change would break about compatibility (third party server browsers, external tools, mods...), but please try to think if it is worth of spending some time.  
There are many server settings that would be nice to set using "sets" (e.g. to allow people to know if DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Special_game_options]special game options are enabled or not, or to know server settings like sv_fps to be able to set their client in the best way to play there), but server admins have quite limited "sets" space available.

Or else, maybe better, it would be useful to invent a brand-new alternative system to let users know about server settings like g_elimination, g_vampire, g_regen, g_friendlyfire, g_catchup, pmove_float, pmove_fixed, pmove_msec, etc. I would like to know if such features are enabled or disabled on the server, but at the moment it is not possibile, unless server admin uses "sets" with them (but there is little "sets" space), or I try to guess by myself while playing (quite hard for some of them, don't you think?). In short, a new way (like a new client command, similar to "serverinfo", but with more/different data, populated with server settings chosen by the admin -how?- or maybe better, chosen by you developers talking with the community) to know about game settings. This solution would not have big network compatibility problems, I suppose, relying on a new command that maybe (if needed to avoid errors) could not be sent at all to old servers; anyway the system should be designed to allow to publish more variables in the future, as OpenArena will gain new features that will be controlled by new cvars.
If you think it would not bring too many compatibilty problems, maybe all such "public" variables could be integrated to the init string, to allow external tools to read them without updates from their authors, but if they expect for a maximum string lenght, it may cause problems, I fear...

At the moment, in theory server admins could use the DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Message_of_the_day]message of the day to inform users about some server settings, but it would be quite intrusive and would still rely on admins' good will (a problem that affets "sets", too).

[GrosBedo]

I have done some tests and unluckily, there is indeed a limit not only in the engine, but in the dpmaster tool too. I don't know why there is this limitation, I didn't have a read at the code exactly, but it seems not coming from an inherent limit from the UDP protocol.

What is important to know is, if I am not mistaken, that the info string only gets send from the server to the listing (dpmaster), never to a client (except if the client does a /serverstatus).

In consequence, I have done 2 tests :
- Limits of the game server (String info length exceeded) : Trying to sets as many variables on the server.
- Limits of the master server : fake server (so no limit, it just a script with the amount of vars I want) to test dpmaster's limits.

For these tests, I have used variables with a name composed of 10 caracters, and their values was a string of 10 caracters too.

For the first test, the game server reached the String info length exceeded bug after only 15 to 20 such variables, but the server was still accessible for players without any difference from a normal game server. Then, with about 30 or 40 variables, the game server still throws the same error, but then become inaccessible for players (can't load the .bsp of the map), but it is still shown on the dpmaster listing. Then, with more than 50 variables, the game server is no more to be seen in the dpmaster listing. So it seems that there are 3 different degrees of limitation for this specific problem.

For the second test, the dpmaster could handle about 58 such variables (a little bit more than the first test probably because there were less side variables since the environment was better controlled), which contains exactly 1473 caracters, here is an excerpt of the packet sent to the dpmaster :

Code:

ÿÿÿÿinfoResponse
\game\baseoa\voip\1\g_humanplayers\0\g_needpass\0\pure\1\gametype\4\sv_maxclients\10\clients\0\AAAAAAAAA1\thisisatst\AAAAAAAAA2\thisisatst\AAAAAAAA3\thisisatst\AAAAAAAAA4\thisisatst\AAAAAAAAA5\thisisatst\AAAAAAAAA6\thisisatst\AAAAAAAAA7\thisisatst\AAAAAAAAA8\thisisatst\AAAAAAAAA9\thisisatst\AAAAAAAA10\thisisatst\AAAAAAAA11\thisisatst\AAAAAAAA12\thisisatst\AAAAAAA13\thisisatst\AAAAAAAA14\thisisatst\AAAAAAAA15\thisisatst\AAAAAAAA16\thisisatst\AAAAAAAA17\thisisatst\AAAAAAAA18\thisisatst\AAAAAAAA19\thisisatst\AAAAAAAA20\thisisatst\AAAAAAAA21\thisisatst\AAAAAAAA22\thisisatst\AAAAAAA23\thisisatst\AAAAAAAA24\thisisatst\AAAAAAAA25\thisisatst\AAAAAAAA26\thisisatst\AAAAAAAA27\thisisatst\AAAAAAAA28\thisisatst\AAAAAAAA29\thisisatst\AAAAAAAA30\thisisatst\AAAAAAAA31\thisisatst\AAAAAAAA32\thisisatst\AAAAAAA33\thisisatst\AAAAAAAA34\thisisatst\AAAAAAAA35\thisisatst\AAAAAAAA36\thisisatst\AAAAAAAA37\thisisatst\AAAAAAAA38\thisisatst\AAAAAAAA39\thisisatst\AAAAAAAA40\thisisatst\AAAAAAAA41\thisisatst\AAAAAAAA42\thisisatst\AAAAAAA43\thisisatst\AAAAAAAA44\thisisatst\AAAAAAAA45\thisisatst\AAAAAAAA46\thisisatst\AAAAAAAA47\thisisatst\AAAAAAAA48\thisisatst\AAAAAAAA49\thisisatst\AAAAAAAA50\thisisatst\AAAAAAAA51\thisisatst\AAAAAAAA52\thisisatst\AAAAAAA53\thisisatst\AAAAAAAA54\thisisatst\AAAAAAAA55\thisisatst\AAAAAAAA56\thisisatst\AAAAAAAA57\thisisatst\AAAAAAAA58\tttttttttttttttttttttt\mapname\oasago2\hostname\ ^3TESTING FAKE SERVER\protocol\71\challenge\D=+H},4+@

This packet worked and made the server show in the listing (see the attachment for the result). Beyond these 58 test variables, the dpmaster would no longer list the simulated server in the listing (but the dpmaster would still make transactions with the server, just like a normal server !).

----

At first I thought that it might be a limitation in the UDP packets (because these are only transmitted via UDP), but we are way below the limit of 65 527 bytes/caracters.

So in the end, I think that there would be no problem in removing the limitations of the info string, but one would need to update the dpmaster code too.

[Gig]

A thing to consider about updating the init string: I suggest to take a look to this thread, that sounds quite important. It talks about some situations involving the init string, like that ioquake3 supports up to two kinds of init string at once, and that it seems they are preparing some kind of protocol change... It also says that current OA 0.8.5 init string does not allow to see IPv6 servers on dpmaster, cause of searching for a different game name.

I don't know if we should ask for init string enlargement to ioquake3 guys (maybe their protocol update is just the right moment? Do we want to ask in their Bugzilla site in the next days? What do you think about it? Maybe dpmaster author could update it, if the change involves all ioquake3 games. But I don't know how to preserve backward compatibility when more sets variables will be used...)... Anyway, I repeat that maybe a better solution could be a way to publish such useful info automatically, without servers admins have to manually use "sets" for all those variables. First time I proposed that, maybe Sago told that he fears a bit things shown by default, bit I say let's decide together what to show and what not.