Closed illwieckz closed 5 years ago
This is the complete path for a cvar to go from internals to reply packet if the cvar is flagged with CVAR_SERVER_INFO
:
SetUserInfo()
src/shared.c:1168
is called by Cvar_UserInfo_enumerate()
: src/cvar.c:658
which is called by Cvar_UserInfo()
: src/cvar.c:665
which is called by Sv_StatusString()
: src/server/sv_main.c:87
Q2 servers usually reply game
, gamename
and gamedate
too, and XQF can display the game
and gamename
keys in server list. It looks like Quetoo has game
, game_name
and game_date
. It would be fine to flag them too, the current names are fine, I can adjust XQF to recognize quetoo specificities. The user will be able to read the game_date
cvar in XQF within the rule frame.
Someone knows why there is one cvar named version
and one named game_version
? if on of these is the engine version and the other one is the game code version and quetoo is expected to be modded so these versions can differ, it can be good to flag both.
version is engine version, game_version is game DLL version (only available when server is running). only game_version is relevant to the outside. There's also cgame_version which is client-side only.
Yes, version
is the engine build version, game_version
is for the game module (mod).
These all sound like very minor fixes and I'm certainly happy to take care of them, or if someone else beats me to it, that's fine. I'm slightly surprised that some of the vars you're looking for are not already returned. Hopefully there's not a [nasty] bug in our CVAR_SERVER_INFO
filtering.
Thanks for the explanations!
I continue to dig in cvar lists. I guess it can be useful to flag g_ctf
, g_teams
and g_hook
so server browser can tell the player which game is played. What g_tech
is for? and what is g_gameplay
for? Telling player the server is a votable one (flagging g_voting
) is useful too. It would hurt no one to flag g_match
and g_rounds
. I don't know if it's a good idea to flag g_motd
but it would hurt no one.
Is protocol expected to change? If yes flagging sv_protocol
can help players to troubleshoot.
Edit: most of them if not all are already flagged.
@jdolan I can probably flag the existing cvars, but not create a mapname one.
Anything that would be useful to server browsers should be flagged, yeah. g_gameplay is the gameplay type, like small game type modifications. g_tech is whether techs are enabled or not. Protocol change is expected, yes.
Hmm, it looks like almost everything is already flagged.
What seems to not exist at all is a cvar telling the map name.
For what I see, that is the current list of flagged cvars:
cg_quick_join_max_ping
cg_quick_join_min_clients
g_gameplay
g_teams
g_ctf
g_match
g_ai_max_clients
g_ai_max_clients
game_version
game_name
game_date
g_ammo_respawn_time
g_auto_join
g_capture_limit
g_cheats
g_ctf
g_hook
g_hook_distance
g_hook_style
g_hook_speed
g_hook_pull_speed
g_frag_limit
g_friendly_fire
g_force_demo
g_force_screenshot
g_gameplay
g_gravity
g_handicap
g_inhibit
g_num_teams
g_match
g_motd
g_player_projectile
g_round_limit
g_rounds
g_show_attacker_stats
g_spawn_farthest
g_spectator_chat
g_teams
g_techs
g_time_limit
g_timeout_time
g_voting
g_warmup_time
g_weapon_respawn_time
g_weapon_stay
sv_max_clients
sv_hostname
version
game
ai
sv_demo_list
sv_download_url
sv_hostname
sv_max_clients
sv_protocol
Well, I was testing the Calinou's server which is probably outdated, using another one gives me more cvars in reply packet. Perhaps only a mapname cvar is missing, but that is a thing I don't know how to do.
Edit: even on PacketFlinger's servers I don't see all the expected cvars, like the sv_hostname
one.
Cool. I think the map name is returned in the status string, but if we want it as a cvar too, I'm totally fine with that. Let's create a new cvar, sv_name
, and declare / initialize it in sv_main.c
with the rest. Then, in [src/server/sv_init.c:252] add:
Cvar_ForceSetString(sv_name->name, name);
In Sv_LoadMedia
.
Perhaps sv_napname
is a good idea. Qstat source code tells me other q2 derivated game use map
or mapname
. sv_name
would be a bit ambiguous.
Btw I'm running through a nasty issue, if I query my local server which is up to date, I get some informations like the player list (with myself in), but still not get some other information like the hostname. Can it be possible the packet is too small for the data to fit?
There is an "end of packet" identifier somewhere in there + size of packets is sent with them I believe, should be pretty easy to figure out from that if it's prematurely ending.
enjoy:
./qstat -R -json -cfg qstat.cfg -quetoos localhost
[
{
"protocol": "quetoos",
"address": "localhost",
"status": "online",
"hostname": "localhost",
"name": "Quetoo",
"gametype": "default",
"map": "aerowalk",
"numplayers": 1,
"maxplayers": 8,
"numspectators": 0,
"maxspectators": 0,
"ping": 24,
"retries": 0,
"rules": {
"g_balance_railgun_refire": "1.4",
"g_balance_shotgun_knockback": "2",
"g_balance_supershotgun_refire": "0.8",
"g_vote_allow_g_hook_speed": "1",
"g_auto_join": "0",
"g_vote_allow_map": "1",
"g_balance_grenadelauncher_timer": "2.5",
"g_balance_supershotgun_pellets": "24",
"g_balance_blaster_refire": "0.45",
"g_match": "0",
"g_friendly_fire": "1",
"sv_public": "1",
"g_balance_shotgun_pellets": "12",
"g_vote_allow_g_spawn_farthest": "1",
"g_balance_bfg_knockback": "140",
"g_balance_hyperblaster_speed": "1800",
"g_gameplay": "default",
"g_balance_lightning_length": "600",
"g_force_demo": "0",
"g_teams": "0",
"g_balance_rocketlauncher_damage": "100",
"g_balance_machinegun_refire": "0.05",
"g_techs": "default",
"g_hook_style": "default",
"g_vote_allow_kick": "1",
"g_vote_allow_g_match": "1",
"g_balance_shotgun_refire": "0.6",
"g_balance_bfg_radius": "512",
"g_frag_limit": "30",
"g_balance_machinegun_knockback": "2",
"g_balance_railgun_damage": "100",
"g_balance_bfg_refire": "2",
"g_hook_pull_speed": "800",
"g_balance_grenadelauncher_radius": "185",
"g_show_attacker_stats": "0",
"g_balance_supershotgun_damage": "4",
"g_gravity": "800",
"g_vote_allow_g_teams": "1",
"g_balance_blaster_speed": "1000",
"g_hook_auto_refire": "0",
"g_balance_shotgun_spread_x": "700",
"g_balance_shotgun_spread_y": "300",
"ai": "default",
"g_balance_hyperblaster_knockback": "4",
"g_balance_blaster_damage": "15",
"g_vote_allow_g_techs": "1",
"g_balance_grenadelauncher_refire": "1",
"g_vote_allow_g_rounds": "1",
"g_vote_allow_g_hook_style": "1",
"g_spawn_farthest": "0",
"g_num_teams": "default",
"g_spectator_chat": "1",
"g_force_screenshot": "0",
"game": "default",
"g_weapon_stay": "0",
"g_balance_hyperblaster_climb_knockback": "68",
"g_vote_allow_g_num_teams": "1",
"g_balance_railgun_knockback": "80",
"g_balance_grenadelauncher_knockback": "120",
"g_vote_allow_g_hook": "1",
"g_timeout_time": "120",
"g_quad_damage_respawn_time": "60",
"g_warmup_time": "15",
"g_vote_allow_g_capture_limit": "1",
"g_weapon_respawn_time": "5.0",
"g_ammo_respawn_time": "20.0",
"g_balance_hyperblaster_damage": "16",
"g_balance_machinegun_damage": "4",
"game_name": "default",
"g_vote_allow_next_map": "1",
"g_self_damage": "1",
"g_vote_allow_g_frag_limit": "1",
"g_balance_bfg_prefire": "1",
"g_balance_lightning_refire": "0.1",
"g_vote_allow_g_weapon_stay": "1",
"g_vote_allow_g_ctf": "1",
"g_balance_shotgun_damage": "4",
"g_handicap": "1",
"g_balance_bfg_speed": "720",
"g_balance_blaster_knockback": "2",
"g_balance_bfg_damage": "180",
"sv_protocol": "1023",
"g_vote_allow_restart": "1",
"g_hook_refire": "0.25",
"g_time_limit": "20.0",
"g_hook": "default",
"g_ctf": "0",
"g_balance_supershotgun_spread_x": "1600",
"version": "0.1.0 x86_64-linux-gnu 6bbb9ade",
"g_balance_supershotgun_spread_y": "500",
"game_date": "Mar 20 2018",
"g_vote_allow_g_hook_pull_speed": "1",
"g_balance_grenadelauncher_damage": "120",
"g_capture_limit": "8",
"game_version": "0.1.0 x86_64-linux-gnu 6bbb9ade",
"g_balance_grenadelauncher_speed": "800",
"g_balance_hyperblaster_refire": "0.1",
"g_round_limit": "30",
"g_quad_damage_time": "20",
"g_balance_hyperblaster_climb_damage": "3",
"g_player_projectile": "1",
"g_cheats": "0",
"g_balance_machinegun_spread_x": "20",
"g_balance_machinegun_spread_y": "200",
"g_hook_distance": "2048.0",
"g_hook_speed": "1200",
"g_vote_allow_g_round_limit": "1",
"g_balance_rocketlauncher_radius": "150",
"g_vote_allow_mute": "1",
"g_vote_allow_g_time_limit": "1",
"g_vote_allow_g_friendly_fire": "1",
"g_balance_rocketlauncher_refire": "1",
"g_vote_allow_g_gameplay": "1",
"g_ai_max_clients": "0",
"g_rounds": "0",
"g_voting": "1",
"g_balance_lightning_damage": "12",
"g_balance_supershotgun_knockback": "2",
"g_vote_allow_unmute": "1",
"g_balance_rocketlauncher_speed": "1000",
"g_balance_handgrenade_refire": "2",
"g_balance_rocketlauncher_knockback": "100",
"g_balance_lightning_knockback": "6"
}
}
]
My qstat PR to add Quetoo specificities to qstat (see https://github.com/multiplay/qstat/pull/75 ) was just merged. I now need #548 and #549 on Quetoo side to be merged so I can implement Quetoo support it in XQF. :smiley:
That's awesome, thank you! I will try to get your PR's merged this weekend. While the static char array workaround was good enough for your testing, we'll want to do something a little more robust long term.
I guess that if those two PR are merged we can close this issue. :+1: :champagne: :fireworks:
XQF just uses qstat as a backend so if qstat knows how to list servers XQF will know to.
Qstat already knows how to query quake2 servers and successfully queries quetoo server, the only issue is just quetoo does not reply the cvar qstat & XQF needs.
Nothing to do:
sv_max_clients
and qstat expectssv_maxclients
, there is nothing to change on Quetoo side, I'll patch qstat instead.Things to do:
sv_hostname
cvar but does not reply it to qstat. Qstat already know how to parse this key in reply packet so you'll just have to flag this cvar to be sent in reply packet.mapname
(the short name liketrial
not the long one like “Trial by Error - by TraK”). XQF needs it. I haven't found any cvar containing that map name, so a new one has to be created. Qstat currently expectsmapname
but if you prefersv_mapname
it's very OK, I'll make Qstat recognizing the key name you'll chose. This new cvar has to be flagged in order to be sent in reply packet.version
cvar. XQF can display it and other games usually send this in reply packet, so this can be good to flag this cvar to be sent in reply packet too. It's not required to properly list servers in XQF, but it's better for the end user.