As suggested by BannZay on Discord. We scale down when we notice that
no responses arrive. The idea is that player's internet has become
faster than when DDNet started, so increasing the default is ok.
2715: Fix server responses handling in game browser r=heinrich5991 a=BannZay
Fixes all problems for #2620
Explanations of existed problems:
Lan has non expected servers because we were creating browser entry regardless token check
DDNet tab has ping 0 for servers as we weren`t rejecting previous refresh responses
Co-authored-by: Andrii <bannzay3@gmail.com>
One from each country and so on instead of doing one country fully first
before moving to the next. This makes loading servers like Japan and AUS
much faster since they're at the back of the list. This also reduces the
peak number of packets sent to each IP at once.
- As requested by qshar and KoG players
- Similar to DDNet tab
- Info fetched from servers-kog entry from https://info.ddnet.tw/info
- Also supports countries and types
- Doesn't inform whether map has been finished
- Generalized the code a bit but it's still ugly
- Depends on #1533, also shows KoG servers as official/verified
Replace `mem_free` by `free`, and `mem_alloc` by `malloc` or `calloc`
(the latter one being used to allocate a zeroed array of elements,
sometimes, this makes a call to `mem_zero` superfluous).
This results in having to remove `mem_stats` which previously recorded
the number of allocations and their size that the Teeworlds code did
directly.
Remove OOM handling in `src/game/client/components/binds.cpp`.
Remove needless copying in the CSV code in
`src/game/client/components/statboard.cpp`.
- Single json file containing all information for the client
- Fetched from https://info.ddnet.tw/info?name=deen
- Replaces versionsrv, news, ddnet-maps.json and ddnet-ranks.json
- Servers are sorted by most popular ones for respective player
- Always stays < 100 ms response time, compared to occasional 50 s for
old ddnet-ranks.json
This means that we have a reliable and fast way to query for extended info,
while also not wasting network bandwidth.
The protocol is designed to be extensible, there's four bytes space for
encoding more request types (currently zeroed), and there's one string in each
response packet and one string for each player available (currently the empty
string).
The protocol itself has no problems with more than 64 players, although the
current client implementation will drop the player info after the 64th player,
because it uses a static array for storage.
Also fixes#130, the player list is just sorted each time new player info
arrives.
