/dev/random wrote:Usually there's no need to set fs_game manually while connecting to a server, since the engine will figure this out on its own.
If you insist, then just use "game" from the info reply, since it matches the server's fs_game setting. Be aware that this key might not be present if it equals the default BASEGAME, e.g. "baseq3", "baseoa", "smokinguns" etc. (in which case you should not need to manually set it either).
Since it does not include any useful information for the players, I'd say just ignore it.IIRC, the wrong UI module will be loaded initially if the server isn't using the default fs_game. Then the client changes the UI when it learns the server's fs_game setting. That doesn't look so good, so I'll continue setting it to avoid that situation./dev/random wrote:Be sure to use "gamename" from status replies to discriminate between mods.
The same key in info replies is set to "com_gamename" in recent ioquake3 forks. I have no idea why they chose a key name which is already taken by another cvar.
I guess this is the "safest" way to detect mods. There is no guarantee that a mod actually changes this value, but you'd have to rely on other hacks to detect mods in this case (like looking at special version cvars, such as "xp_version" for E+ in status replies).
Some mods change only game, not gamename. I'm still thinking about this -- it's a bit of a mess. Currently, MB checks both of them and includes the server if either is a match for the desired mod name.