2202: Send DDNet version early in the connection process r=Learath2 a=heinrich5991
This gets rid of the problem that we don't know whether we should send
full snapshots to clients because they haven't told us about them being
DDNet yet.
Co-authored-by: heinrich5991 <heinrich5991@gmail.com>
This came from a long discussion comparing PCG-* against xoroshiro*. Do
not generate integers without bias because it doesn't affect us very
much and it is easier to reimplement with modulo.
This gets rid of the problem that we don't know whether we should send
full snapshots to clients because they haven't told us about them being
DDNet yet.
1678: Handle colors in console r=def- a=Learath2
DEPENDS: #1654
A better way to fix#1581 possibly deprecates #1597
Co-authored-by: Learath <learath2@gmail.com>
1654: Try working on colors a bit r=def- a=Learath2
There were color functions everywhere, I tried cleaning it up a little. I still couldn't get the roundtrip from Hsl to Rgb to be exactly the same, but I think this is the best possible.
1685: Work on compound binds r=def- a=Learath2
Closes#1417
Co-authored-by: Learath <learath2@gmail.com>
Quoting the man page of vsnprintf:
RETURN VALUE
Upon successful return, these functions return the number of characters printed
(excluding the null byte used to end output to strings).
The functions snprintf() and vsnprintf() do not write more than size bytes (including
the terminating null byte ('\0')). If the output was truncated due to this limit,
then the return value is the number of characters (excluding the terminating null
byte) which would have been written to the final string if enough space had been
available. Thus, a return value of size or more means that the output was truncated.
(See also below under NOTES.)
If an output error is encountered, a negative value is returned.
[...]
The glibc implementation of the functions snprintf() and vsnprintf() conforms to the
C99 standard, that is, behaves as described above, since glibc version 2.1. Until
glibc 2.0.6, they would return -1 when the output was truncated.
SHA256 was chosen because it is reasonably standard, the file names
don't explode in length (this rules out SHA512) and it is supported by
basically all versions of OpenSSL (this rules out SHA512/256 and SHA3).
The protocol is changed in a backward compatible way: The supporting
server sends the SHA256 corresponding to the map in the `MAP_DETAILS`
message prior to sending the `MAP_CHANGE` message. The client saves the
SHA256 obtained from the `MAP_DETAILS` message until the next
`MAP_CHANGE` message.
For servers not supporting this protocol, the client falls back to
simply opening maps like in the previous scheme.
Remove the `map_version` tool, it is not being used and would have been
a little bit effort to update.
Use the OpenSSL implementation of SHA256 if it is supported, otherwise
fall back to a public domain one.
Fix#1127.
ChillerDragon
