Talk:Server queries

SteamAppID

@Megaoerti: The change with the bot count and the unknown value can't be correct :/

Yes you're right, but i worry about the SteamAppID set as a 2 byte value 'F000'. This isn't zero?!

F0 is in decimal 240, which stands for CS: Source (see Steam Application IDs) --King2500 14:53, 15 Aug 2005 (PDT)

ok ... i forgot the sweet little endian of these two bytes *g* --MEGAOerti 13:17, 16 Aug 2005 (PDT)

Protocol

Source seems to handle multiple packet replies differently. It also sends the 0xFFFFFFFE header followed by the request id. But then the next byte contains the total number of packets, the one after the current packet number. Also Source does not seem to start all "actual" replies with 0xFFFFFFFF (only contained the first packet).

Is this completely right or did I miss something? If it is it will have to be updated in the main page.

--Philip 08:41, 4 Sep 2006 (PDT)

SteamAppID Again

Either I'm being blind and stupid, or do Goldsource a2s_info replies not include an AppID... I think I should point out that I may be both blind and stupid, but I'm just not seeing it

LINE	Hex
0000	FF	FF	FF	FF	6D	31	39	34	....m194
0008	2E	31	34	30	2E	32	34	32	.140.242
0010	2E	32	3A	32	37	30	32	35	.2:27025
0018	00	32	5E	48	41	42	20	43	.2^HAB C
0020	6C	61	6E	20	53	65	72	76	lan Serv
0028	65	72	3A	3A	77	77	77	2E	er::www.
0030	32	68	61	62	2D	70	72	6F	2hab-pro
0038	67	61	6D	65	72	73	2E	63	gamers.c
0040	6F	2E	6E	72	3A	3A	00	63	o.nr::.c
0048	73	5F	6F	66	66	69	63	65	s_office
0050	00	63	73	74	72	69	6B	65	.cstrike
0058	00	43	6F	75	6E	74	65	72	.Counter
0060	2D	53	74	72	69	6B	65	00	-Strike.
0068	01	0B	2F	64	6C	00	01	77	../dl..w
0070	77	77	2E	63	6F	75	6E	74	ww.count
0078	65	72	2D	73	74	72	69	6B	er-strik
0080	65	2E	6E	65	74	00	00	00	e.net...
0088	01	00	00	00	00	9E	F7	0A	........
0090	00	01	01	00					....

--Luthias 09:05, 13 Nov 2006 (PST)

You're right. GoldSrc server replies doesn't include an AppID. --King2500 17:32, 11 Jan 2007 (PST)

Counter-strike server reply format

I couldn't find anything about CS1.6 servers, AFAIK this is their reply format for A2S_INFO. There is more after this but I dont know what it is.

Data	Type	Comment
Type	byte	Should be equal to 'm'
IP	string	The server's IP address and port
Server Name	string	The server's name, eg: "Recoil NZ CS Server #1"
Map	string	The current map being played, eg: "de_dust"
Game Directory	string	The name of the folder containing the game files, ie: "cstrike"
Game Description	string	A friendly string name for the game type, ie: "Counter-Strike"
Number of players	byte	The number of players currently on the server
Maximum players	byte	Maximum allowed players for the server
???	byte	A '/'
Dedicated	byte	'l' for listen, 'd' for dedicated
OS	byte	Host operating system. 'l' for Linux, 'w' for Windows
Password	byte	If set to 0x01, a password is required to join this server
Secure	byte	If set to 0x01, this server is VAC secured
???	string	"www.counter-strike.net"

More information to add to this article

The French version of this article now has more information than this one (the english version). I have asked the person that is currently updating the French article if it were possible to add the same information to the English version. If anyone else has the time to do it as well, please step forth! Perhaps we need a new template to "tag" situations such as these... a template like {{TranslationUpdate}}, but for any language (specified when the template is used), rather than just for the English version. --Etset 14:23, 31 Jan 2008 (PST)

Bug on Rag Doll Kung Fu server reply

Sometime (actually once in two) a RDKF server will reply like this :

FF FF FF FF 49 FC 55 00 53 00 45 00 52 00 20 00 ....I.U.S.E.R. . 32 00 27 00 73 00 20 00 64 00 6F 00 6A 00 6F 00 2.'.s. .d.o.j.o. 00 00 53 6F 63 63 65 72 00 52 44 4B 46 53 6F 63 ..Soccer.RDKFSoc 63 65 72 00 52 61 67 44 6F 6C 6C 4B 75 6E 67 46 cer.RagDollKungF 75 3A 20 53 6F 63 63 65 72 00 EA 03 01 04 00 00 u: Soccer....... 77 00 00 32 2E 33 2E 30 2E 30 00 w..2.3.0.0.

Everything is fine except the server name (in blue) : a NUL byte is inserted between each character. There is the same effect with the player names on the A2S_PLAYER query. What about? --Cortexd 17:55, 17 Feb 2008 (PST)

I think these strings are in UTF-16 instead UTF-8 --Cortexd 19:49, 2 Mar 2008 (PST)

GoldSource RCON Protocol

Hi all,

This is probably an old topic - but is there any definitions for "GoldSource" aka "Classic" rcon packet requests/responses. Is this the correct place to start one ?

I am slowly working my way through the protocol so I may be able to contribute in some areas as well.

cheers will Beattie Wlbeattie 19:04, 6 Mar 2008 (PST)

Player connection time

Does anyone know what a player connection time of -1 (0x000080bf) stands for? Maybe someting like "is connecting"? --Koraktor 23:55, 7 Aug 2008 (PDT)

Bots I think. --TomEdwards 09:26, 8 Aug 2008 (PDT)

A2S_SERVERQUERY_GETCHALLENGE not working since last HLDS update

GoldSrc servers do not respond to A2S_SERVERQUERY_GETCHALLENGE requests since the last HLDS update (GoldSrc protocol version 48). Does anyone know what has changed? Or is this a bug? --Koraktor 07:42, 2 Nov 2008 (PST)

Indeed, kept me busy for quite some time too, but got the solution with the help of some others:

I'm using the function below. If you look closely you discover that the 5th byte has changed to 55 instead of 57 and it's now followed by 4 times \xFF .... dunno how, why and so on, but it works!

function getQuery($queryType) {
	switch($queryType)
	{
		case "A2S_SERVERQUERY_GETCHALLENGE":
		return "\xFF\xFF\xFF\xFF\x55\xFF\xFF\xFF\xFF";
		break;

		case "A2S_INFO":
		return "\xFF\xFF\xFF\xFFTSource Engine Query\x00";
		break;

		case "A2S_PLAYER":
		return sprintf("\xFF\xFF\xFF\xFF\x55%s", $this->getChallenge());
		break;
		}
	}

Hope this works for you too  :) —The preceding unsigned comment was added by Ouwe tosti (talk • contribs).

"Does anyone know what has changed? Or is this a bug?"

Current protocol 48 bugs:

• A2S_SERVERQUERY_GETCHALLENGE does not work at all, use A2S_PLAYER or A2S_RULES instead with ffffffffh (-1) as challenge.
• The map name from A2S_INFO is only updated when players are present.
• Hostname and bot flag from A2S_INFO are only updated when the map changes.
• Server rules from A2S_RULES, like amx_nextmap or mp_timeleft, are only updated when the map changes.
• mp_timelimit is off by a few minutes (only the value returned by A2S_RULES, rcon is ok though).
• bot count is now a bot flag, 1 means there were only bots during map change.

I'm not exactly sure which part of the query info gets updated when so take these bug descriptions with a grain of salt. Example, I join an empty server and the map name gets updated, but mp_timeleft is still wrong. I join a server with bots that also has a plugin that updates the server name with the time left, but only the map name gets updated via the query, not the hostname. (You can check the actual full-length hostname by typing status in console.)

--pizzahut 23:30, 2 Nov 2008 (PST)

I can, and I think everyone else can, confirm the above things written by pizzahut. GoldSource servers switched to the Source protocol, which is absolutely fine, but the implementation is incorrect (for former GoldSource servers only). These bugs are now within there for over 2 months, Valve got notified of it by people whos word should have at least a little weight for that matter (e.g. the HLSW staff) long ago and it's their very own server browser that displays these data as wrong as they are reported by the server (of course), still nothing was fixed. I'm one of the many coders that work in some way with this data and are annoyed by it while threads over this in the Steam forums just died. So I vote for putting information about these problems to the main page, as it has been a steady situation for over 2 months now.

These "unwanted features" have become part of the protocol in a way, everyone starting to work with it coming to this Wiki has to deal with them. Currently they will see the information how they could query the bot counter or current map and not everyone is suspecting such additional information in the comments page, so people will probably waste time over trying to find out the problem in their code that makes the bot counter or map be displayed wrong until they notice it isn't their fault.

However, I am new to this Wiki (and to public Wikis in general), so I didn't want to do such a change myself straight away, maybe some people even consider that being rude or whatever. Of course I would be happy if that could also catch the attention of Valve but, to be honest, I doubt that. But at least let us save newcomers some time. Any comments on that from others?

--xOR 19:55, 5 Jan 2009 (GMT+1)

Looks like all GoldSource servers are responding with the Source protocol format. You will have to use appids to tell source/goldsource servers apart (IE CS/CSS). --The MAZZTer 09:47, 9 Nov 2008 (PST)

A2S_SERVERQUERY_GETCHALLENGE seems to be ignored, because it is changed. It is now 0x55 instead of 0x57 (and Steam seems to send an extra Int32 0 after it, not sure what that is). --The MAZZTer 13:52, 10 Nov 2008 (PST)

The A2S_SERVERQUERY_GETCHALLENGE hasn't "changed", it stopped working with the update. Steam apparently never used it. The header 0x55 belongs to a A2S_PLAYER request. The additional (long) 0 is an invalid challenge, therefore the server responds with a S2C_CHALLENGE containing a valid challenge. --Koraktor 10:06, 13 Nov 2008 (PST)

I put a warning on the main page about this, but it'd be really nice to know if this is a permanent change. Also, it'd be nice to know if this query will stop working in Source servers in the future. --BarkerJr 09:07, 26 Nov 2008 (PST)

Goldsource servers are still responding to the old challenge method. Just send the default header with "challenge rcon\n" after it. The server will send back a packet with the default header followed by: "challenge rcon (unsigned int)\n\0" where (unsigned int) is the challenge number.--Chris03 12:07, 30 Dec 2008 (GMT-5)

Made a new wiki page for this, Half-Life 1 Engine Bug Reports. --pizzahut 20:03, 20 January 2009 (UTC)

No longer works in Left4Dead, either -BarkerJr 03:35, 4 October 2009 (UTC) It seems A2S_PLAYER and A2S_RULES are broken, too.[1] -BarkerJr

Source: S2A_RULES doesn't return all rules

Since an update in the past weeks the S2A_RULES reply doesn't contain all rules. For a vanilla TF2 server example see below. As you can see the last rule (should be tf_gamemode_ctf) is cut off and there's no way to get the rest of the rules. The reply doesn't use split packets and when querying with an additional A2S_RULES (similar to GoldSrc RCON) I get the same response. Is this a (known) bug or did I miss something?

   000000FC  ff ff ff ff 45 50 00 6d  70 5f 74 65 61 6d 70 6c ....EP.m p_teampl
   0000010C  61 79 00 30 00 6d 70 5f  66 72 61 67 6c 69 6d 69 ay.0.mp_ fraglimi
   0000011C  74 00 30 00 6d 70 5f 66  61 6c 6c 64 61 6d 61 67 t.0.mp_f alldamag
   0000012C  65 00 30 00 6d 70 5f 77  65 61 70 6f 6e 73 74 61 e.0.mp_w eaponsta
   0000013C  79 00 30 00 6d 70 5f 66  6f 72 63 65 72 65 73 70 y.0.mp_f orceresp
   0000014C  61 77 6e 00 31 00 6d 70  5f 66 6f 6f 74 73 74 65 awn.1.mp _footste
   0000015C  70 73 00 31 00 6d 70 5f  66 6c 61 73 68 6c 69 67 ps.1.mp_ flashlig
   0000016C  68 74 00 30 00 6d 70 5f  61 75 74 6f 63 72 6f 73 ht.0.mp_ autocros
   0000017C  73 68 61 69 72 00 31 00  64 65 63 61 6c 66 72 65 shair.1. decalfre
   0000018C  71 75 65 6e 63 79 00 31  30 00 6d 70 5f 74 65 61 quency.1 0.mp_tea
   0000019C  6d 6c 69 73 74 00 68 67  72 75 6e 74 3b 73 63 69 mlist.hg runt;sci
   000001AC  65 6e 74 69 73 74 00 6d  70 5f 61 6c 6c 6f 77 4e entist.m p_allowN
   000001BC  50 43 73 00 31 00 6d 70  5f 66 72 69 65 6e 64 6c PCs.1.mp _friendl
   000001CC  79 66 69 72 65 00 30 00  6d 70 5f 66 61 64 65 74 yfire.0. mp_fadet
   000001DC  6f 62 6c 61 63 6b 00 30  00 73 76 5f 67 72 61 76 oblack.0 .sv_grav
   000001EC  69 74 79 00 38 30 30 00  73 76 5f 73 74 6f 70 73 ity.800. sv_stops
   000001FC  70 65 65 64 00 31 30 30  00 73 76 5f 6e 6f 63 6c peed.100 .sv_nocl
   0000020C  69 70 61 63 63 65 6c 65  72 61 74 65 00 35 00 73 ipaccele rate.5.s
   0000021C  76 5f 6e 6f 63 6c 69 70  73 70 65 65 64 00 35 00 v_noclip speed.5.
   [...]
   00000998  6d 70 5f 64 69 73 61 62  6c 65 5f 72 65 73 70 61 mp_disab le_respa
   000009A8  77 6e 5f 74 69 6d 65 73  00 30 00 6d 70 5f 61 75 wn_times .0.mp_au
   000009B8  74 6f 74 65 61 6d 62 61  6c 61 6e 63 65 00 31 00 toteamba lance.1.
   000009C8  6d 70 5f 73 74 61 6c 65  6d 61 74 65 5f 65 6e 61 mp_stale mate_ena
   000009D8  62 6c 65 00 30 00 6d 70  5f 6d 61 74 63 68 5f 65 ble.0.mp _match_e
   000009E8  6e 64 5f 61 74 5f 74 69  6d 65 6c 69 6d 69 74 00 nd_at_ti melimit.
   000009F8  30 00 73 76 5f 61 6c 6c  74 61 6c 6b 00 30 00 74 0.sv_all talk.0.t
   00000A08  66 5f 6d 61 78 73 70 65  65 64 00 34 30 30 00 74 f_maxspe ed.400.t
   00000A18  66 5f 62 69 72 74 68 64  61 79 00 30 00 6d 70 5f f_birthd ay.0.mp_
   00000A28  74 6f 75 72 6e 61 6d 65  6e 74 5f 73 74 6f 70 77 tourname nt_stopw
   00000A38  61 74 63 68 00 31 00 74  66 5f 61 72 65 6e 61 5f atch.1.t f_arena_
   00000A48  66 6f 72 63 65 5f 63 6c  61 73 73 00 30 00 74 66 force_cl ass.0.tf
   00000A58  5f 61 72 65 6e 61 5f 63  68 61 6e 67 65 5f 6c 69 _arena_c hange_li
   00000A68  6d 69 74 00 31 00 74 66  5f 61 72 65 6e 61 5f 6f mit.1.tf _arena_o
   00000A78  76 65 72 72 69 64 65 5f  63 61 70 5f 65 6e 61 62 verride_ cap_enab
   00000A88  6c 65 5f 74 69 6d 65 00  2d 31 00 74 66 5f 61 72 le_time. -1.tf_ar
   00000A98  65 6e 61 5f 66 69 72 73  74 5f 62 6c 6f 6f 64 00 ena_firs t_blood.
   00000AA8  31 00 74 66 5f 67 61 6d  65 6d 6f 64 65 5f 61 72 1.tf_gam emode_ar
   00000AB8  65 6e 61 00 30 00 74 66  5f 67 61 6d 65 6d 6f 64 ena.0.tf _gamemod
   00000AC8  65 5f 63 70 00 31 00 74  66 5f 67 61             e_cp.1.t f_ga

--Koraktor 10:36, 30 August 2009 (UTC)

I have the same issue; at least for TF2, the reply is cut off after 1260 bytes and incomplete. So instead of the 86 rules (according to the rules number) I only get 50 or so, and the rest is lost (cut off in the middle of a string). I tried listening for additional packets but there are none, so it's not split or anything either. Haven't tested with other mods than TF2. I'll add a warning to the main page...

Comparing the English article with the French article, there seem to be a lot of differences... the French send 'V' and 'U' instead of 'D' and 'E', I tested that and I actually get the same replies back, but the packet is still just cut off for TF2 even though the French article even shows an example for a split packet reply...

Frostschutz 18:33, 23 January 2010 (UTC)

Today I found that TF2 does not split the reply for A2S_PLAYER either (tested with +maxplayers 32, and bot -name foooooooooooooooooooooooooooooooooooooooooooooooobaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaar times 32). Here too I only receive one single packet that is 1260 bytes long '\xff\xff\xff\xffD \x00fooooooooooooooooooooooooooooob\x00...' and simply cut off at the end. So it seems that TF2 is lacking the ability to send split packets for the server queries described here.

Frostschutz 15:08, 24 January 2010 (UTC)

Oh, that is beautiful. It's not even zero-terminating the string value. --BarkerJr 23:56, 25 January 2010 (UTC)

S2A_INFO2 responses don't match the protocol

Some days ago a bug report for Steam Condenser made me test the library's protocol implementation. A user had problems with a CZ server's reply to A2S_INFO requests. I started tcpdump and did a test run against some servers (the server the user mentioned, some other CZ servers and completely random servers (GoldSrc and Source). The response from all Source servers and part of the GoldSrc servers was ok. But quite a few GoldSrc servers (including the one the user had problems with) replied a packet with a S2A_INFO2 header (0x49), but the packet contents didn't match the description here.

Here's an example of a bad packet:

       0x0000:  4500 009b 0000 4000 3b11 857a 5583 a3a9  E.....@.;..zU...
       0x0010:  c0a8 0003 6987 c1fd 0087 fa96 ffff ffff  ....i...........
       0x0020:  4930 5b47 4552 5d20 4649 4748 5420 434c  I0[GER].FIGHT.CL
       0x0030:  5542 2040 6467 636c 616e 2e64 6520 6279  [email protected]
       0x0040:  2067 2d70 6f72 7461 6c2e 6465 2000 6465  .g-portal.de..de
       0x0050:  5f70 726f 6469 6779 5f63 7a00 637a 6572  _prodigy_cz.czer
       0x0060:  6f00 436f 6e64 6974 696f 6e20 5a65 726f  o.Condition.Zero
       0x0070:  0050 0000 1800 646c 0001 312e 302e 302e  .P....dl..1.0.0.
       0x0080:  332f 5374 6469 6f00 9187 6901 a07d 1ef0  3/Stdio...i..}..
       0x0090:  0540 0150 0000 0000 0000 00              [email protected].......

The part after the version number is "wrong". there should be the EDF (+ HTLV info and tags if available) after the version number. But this seems like total garbage. Is this a bug or intended behavior?

--Koraktor 12:38, 2 April 2010 (UTC)

EDIT: It seems like all responses use a new format. Does anyone know how to parse "extra data" (after the EDF)?

--Koraktor 14:49, 3 April 2010 (UTC)

All I can tell you is that I have the same issues. Your findings may help me actually get the Source TV port now, after implementing it according to the old specification I got a different number + binary data in the Source TV name. If they added new stuff, I wonder why they added it in the middle instead of like at the end. I really hate this protocol... Frostschutz 11:44, 5 April 2010 (UTC)

Challenge number not needed in all cases?

Either I'm beeing stupid or A2S_PLAYER/A2S_RULES do not always require a valid challenge number. Does it depend on the server? I tested it on several servers, e.g. try 82.165.133.27:27015.

FF FF FF FF 55 FF FF FF FF returns directly the player info instead of a challenge number in the reply format of A2S_SERVERQUERY_GETCHALLENGE, and FF FF FF FF 56 FF FF FF FF returns directly the rules.

Apart from that, it even seems that the 4 last bytes can be all kind of numbers (e.g. FF FF FF FF 56 1 3 3 7), it works anyway.

Do you know what it depends on?

--Crv 09:46, 9 August 2010 (UTC)

As war as I can tell it's not working for the latest version of Team Fortress. Sending FF FF FF FF 55 FF FF FF FF to the Server it will replay with FF FF FF FF 41 ... --Spezifanta 15:37, 27 November 2010 (UTC)

A2A_PING no longer supported?

I've been trying to ping some TF2 servers using A2A_PING packets, but the servers don't respond to these. I've found a conversation from the hlds mailinglist that seems to confirm it's gone [2]. Is this true? If it is, perhaps the info should be removed from the main page, or at least a notification should be added.

I have confirmed that A2A_PING no longer works on CS:S servers and TF2 servers and an appropriate warning has been placed in the A2A_PING section with a link to this talk section and a summarisation of it. --Maggymay 23:58, 27 December 2012 (PST)

A2S_PLAYER should include steam id's

I think it would be great if A2S_PLAYER would include steam id's of the players in the response. Right now it is impossible to really identify the users that are connected to a server without using a plugin or RCON. --Durza007 07:13, 31 July 2012 (PDT) I'm agree with you. It's possible only with sourcemod plugins, but it's a bad idea. --Desire 11:21, 3 September 2012 (PDT)

A2S_PLAYER Challenge issues

I'm updating a SRCDS library for Python and I've come across some issues. If I send A2S_SERVERQUERY_GETCHALLENGE and use the challenge given by the response my A2S_PLAYER queries still receive the 0x41 challenge response. In addition the challenge response from A2S_PLAYER remains fixed unlike A2S_SERVERQUERY_GETCHALLENGE.

My code in Python (given a connected socket) is as follows:

   sock.send('\xFF\xFF\xFF\xFF\x57')
   chal = sock.recv(4096)[5:]
   sock.send('\xFF\xFF\xFF\xFF\x55' + chal)
   # This will always return a \xFF\xFF\xFF\xFF\x41 response
   players_resp = sock.recv(4096)

Interesting. Which games did you try this against? Maybe it's another individual exception in the protocol. A lot of stuff seems to be slowly becoming deprecated. A2S_SERVERQUERY_GETCHALLENGE was previously reported on this Talk Page to be displaying odd behaviour; it could very well be an addendum to the reported dysfunction. --Maggymay 01:31, 29 December 2012 (PST)

A2S_INFO response from HLTV

Has anyone else noticed that some (perhaps all) HLTV proxies return two response packets to an A2S_INFO query? The first response is in the old GoldSrc format (with header 0x6D) and the second is in the Source format (with header byte 0x49). Anyone know why this happens? d_a_parker 13:05, 21 July 2015 (UTC)

UPDATE: I e-mailed Alfred and he confirmed that this is the expected behavior of an HLTV server. His recommendation was to simply ignore the first response (GoldSrc format) and use the second one (Source format). --d_a_parker 14:58, 14 August 2015 (UTC)

We ought to revise data type names.

This page and the whole wiki use data types which, I feel, are confusing to developers who are the target of this community. I'm interested in integer types. Let's leave floating points and strings out of it.

In my experience, data types typically have the following lengths.

• byte 8
• short 16
• int 32
• long 64

Whereas the wiki calls those lengths by these names

• 8 byte
• 16 short
• 32 long
• 64 long long

What I really have a problem with / do not understand is the naming of 32 and 64 bit types. The 32 bit name of long contradicts most languages. The 64 bit name of long long is frankly appalling. This type does not exist in any popular language to my knowledge, and this is so for good reason! First, data type names should not be two words. Compilers / interpreters spit variable type from name by splitting at space characters. Very many languages make it illegal to use spaces in programmer defined types.

The pseudo language of this wiki should be no different.

It's not like it would be an overhaul to change it either, just a large scale find and replace, surely. I would be willing to do that myself but obviously won't without the majority of mods/users approving.

On a slightly separate note, I am of the opinion that data types should be signed unless prefixed with a u like uint. Do comment on how realistic such a modification to the wiki pseudo language would be. If I've missed something and just made myself look stupid, please highlight that.

Replies

I concur that the 32-bit "long" and 64-bit "long long" do not make any sense. It would certainly make more sense if the 32-bit type was "int". Other than that, I think the data types are fine. They have been that way since I started referencing this document in the mid-2000's, so I think it's just been one of those things that people have seen, been slightly annoyed (or perplexed) by, but moved on because the actual protocol information is correct. In short, it doesn't stop you from understanding the protocols and parsing the packets, so people just left it alone. Also, please insert a signature after comments you post on this page so it is more clear who made the comment, and when. You can insert a signature using four tildes (~) as described here. Thanks. --d_a_parker 20:53, 17 November 2015 (UTC)

I also concur that the naming is very poor, however I do not agree with using `int` and such at all as the size of `int` can vary depending on system architecture also. Rather the `stdint.h` values should be used which explicitly confer the width and signedness of the types. For example, 32-bit unsigned is `uint32_t`. --gnif 09:51, 10 July 2023 (AEST)

A2S_PLAYER challenge request changed

The Steam and TF2 server browsers seem to be sending FF FF FF FF 55 00 00 00 00 now for the challenge request instead of the previously used FF FF FF FF 55 FF FF FF FF. Can anyone else confirm this?

--Yepoleb (talk) 00:33, 8 September 2016 (UTC)