Editing Virtual1's Hotline Server Protocol Guide (section)

===Chapter 1: NUMBERS AND STRINGS===

long = 4 bytes
short = 2 bytes

Anywhere there is a number that is preceeded by a length, (such as if
the number is the only part of an object, like Socket or Icon) then
the number can be a short OR a long. HL software will always pick
the smaller of the two when sending, though it does not hurt them to
receive a long that is zero.

Numbers appear to be stored as "two's complement".
 0 = 00 00 00 00 (you can send as a short 00 00)
          +1 = 00 00 00 01 (you can send as a short 00 01)
      +65535 = 00 00 FF FF (you can send as a short FF FF)
      +65536 = 00 01 00 00
 +2 = 7F FF FF FF
 -2147483648 = 80 00 00 00 (now counting backwards toward zero)
          -1 = FF FF FF FF

This is how 2's complement works. The ctrl-F12 does not seem to parse
this entirely correctly, but I am assuming this is how things are
supposed to work internally in Hotline. The only place you'd have to
worry about this is if you ran into a file > 2.1gb that was returning
a negative filesize or something. Remember that icons can be
negative numbers. (though the numbers are not likely to get near
the "crossover" point at 231)

It might be simpler to just send everything you can as a long. Some
items must be sent as shorts if they don't have a length indicated
in the protocol, such as all length indicators and some items in
filelist/userlist entries. Anywhere you see short() or long(), it
means that you MUST send it that way, because there is no length
indicator. Anywhere you see number(), you need to send the
length as a short, followed by the number, in your chosen format.
There are a few oddball exceptions. Icon numbers are numbers,
and normally the server will send them in Number format. (length
followed by the number) Userlists however, send the Socket,
Icon, and Status objects without length bytes, (all as shorts)
Filelists have the same limitation. In the event of a negative
icon number, (it can happen, and does work) the icon will be
sent as a SHORT two's complement number. They are very easy to
convert fortunately... just lop off the the first two characters
of the number. -3 changes from FF FF FF FD to FF FD. This limits
your numeric range to -32768 <-> +32767.

Strings are sent as a length (always a short) followed by the
string's characters. Strings marked as "encoded" have each
character of the string EOR'd with $FF. i.e. y=chr(255-asc(x))
It's not meant to be hard to crack, just hard to READ and easy
to DO. Note that strings added to the protocol in HL1.5 are
sent as "pascal" strings, and have a length specified by ONE
BYTE, not two. (no consistency!) These are referred to as
"pstring" instead of "string" for clarity below.