Ok, here goes...
According to the documentation, the returned packet should be in the form:
"details"
(int32) -1
(byte) ASCII 'm' ( S2A_INFO_DETAILED )
(string) net address of server
(string) name of the host / server
(string) name of the map
(string) game directory (i.e. valve/)
(string) Game description (e.g. "half-life multiplay")
(byte) active client count
(byte) maximum clients allowed
(byte) protocol version (currently 37)
(byte) type of server == 'l' for listen or 'd' for dedicated
(byte) os of server == 'w' for win32 or 'l' for linux
(byte) password on server == 1 or yes, 0, for no
(byte) is server running a mod? == 1 for yes, 0 for no
IFF the server is running mod byte was 1:
(string) URL for mod's "info" website
(string) URL for mod's download ftp server
(int32) mod version #
(int32) mod download size ( in bytes, approx. )
(byte) is the mod a server side only mod? 1 == yes, 0 == no
(byte) does this server require you to have a custom client side .dll
(
client.dll )? 1 == yes, 0 == no.
The packet I receive is in the form:
����m195.149.21.40:27015�jolt.co.uk - CS
(01)�cs_office�cstrike�CounterStrike���-dl�www.counter-strike.net���������
�
Mapping this to the packet structure of the documentation would suggest:
(int32) ����
(byte) m
(string) 195.149.21.40:27015�
(string) jolt.co.uk - CS (01)�
(string) cs_office�
(string) cstrike�
(string) CounterStrike�
(byte) �
(byte) �
(byte) -
(byte) d
(byte) l
(now up to ����m195.149.21.40:27015�jolt.co.uk - CS
(01)�cs_office�cstrike�CounterStrike���-dl)
(byte) in this bytes place we have a null character! �
(byte)
IFF the server is running mod byte was 1:
(string) www.counter-strike.net�
(string) �
(int32)
(int32)
(byte)
(byte)
And so on. I have stopped trying to do the mapping because I appear to be
getting null (0) bytes in places I wouldn't expect.
Or is this because some bytes can be null?
I hope this gives better insight into what is going on. To let you know how
I read back the response from the Half-Life Server, the socket DGRAM process
follows:
1. send the detail instruction to the specified server
2. receive the response into a 1024 character TCHAR buffer
3. change all 0 null bytes to a 255 byte (this is so I can output the buffer
without it stopping at the first null terminator).
4. begin parsing against the documented structure.
Thanks,
Simon
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of botman
Sent: 22 February 2002 22:28
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Server Protocol for Half-Life
> But how come the detail response packet structure doesn't resemble the
> documentation?
>
> To be specific, one of the bytes to indicate if the server has a password
or
> is running a mod is missing from the response!
>
> Is this possible?
> Has the mod byte been dropped as we know it is running a mod if the
> extension packet information exists?
>
> If the response doesn't match the documentation, it makes it very
difficult
> to code to the spec.
You might want to post EXACTLY what it is you are seeing in the returned
packet
(i.e POST the bytes in the packet) AND post what you think that you should
be
seeing. Someone can probably explain what you are misinterpreting.
Jeffrey "botman" Broome
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
