chinese (traditional): 5 changes by benny30111
estonian: 1 change by siimsoni
italian: 1 change by AlphaJack
ukrainian: 4 changes by StepanIvasyn
tamil: 37 changes by Aswn
portuguese (brazilian): 19 changes by Greavez
Reworked how the screenshot command works while keeping it backwards
compatible. It can now more freely understand arguments, and has
the ability to make SC_DEFAULTZOOM screenshots.
In other words, it should only (!) return true if A comes for B.
This promise was broken for the situation where two values are
identical. It would return true in these cases too. This is of
course not possible: if two values are identical, neither come
before the other. As such, the sorter was not imposing strict
weak ordering relations.
libstdc++ handled this scenario just fine, but libc++ crashes
badly on this, as it allowed comparing of [begin, end] instead
of [begin, end).
libc++ considered this not a bug (and by specs, they are correct;
just this way of crashing is of course a bit harsh):
https://bugs.llvm.org/show_bug.cgi?id=47903
english (us): 4 changes by 2TallTyler
italian: 4 changes by troccoli
serbian: 251 changes by nkrs
german: 6 changes by ebla71, 2 changes by Wuzzy2
romanian: 3 changes by ALEX11BR
russian: 11 changes by Ln-Wolf
ukrainian: 2 changes by StepanIvasyn
lithuanian: 15 changes by devbotas
spanish: 2 changes by perezdidac
The bootstrap has the _switch_mode to SM_MENU, and never leaves
this mode. Neither is it considered a modal window (while in some
sense it really is). So .. we need to add another "draw anyway"
exception, to make sure bootstrap is being drawn.
When you are downloading a map, all the commands are queued up
for you. Clients joining/leaving is done by the network protocol,
and as such are processed immediately. This means that by the
time you are processing the commands, a client that triggered
it, might already have left.
So, all commands that do something with ClientID, shouldn't
error on an invalid ClientID when DC_EXEC is set, but
gracefully handle the command anyway, to make sure the
game-state is kept in sync with all the clients that did
execute the DoCommand while the now-gone client was still
there.
Additionally, in the small chance a client disconnects between
the server validating a DoCommand and the command being
executed, also just process the command as if the client was
still there. Otherwise, lag or latency can cause clients that
did not receive the disconnect yet to desync.
Strictly seen, there are "N" people -waiting- in front of you
in the queue, but it is nicer to show "N + 1" for the person that
is currently downloading the map. Avoids it showing:
"0 clients in front of you". That just feels a bit off.
swedish: 60 changes by kustridaren
norwegian (bokmal): 12 changes by buzzCraft
czech: 82 changes by PatrikSamuelTauchim, 1 change by tomas-vl
italian: 86 changes by AlphaJack, 9 changes by federico1564S
german: 16 changes by ebla71
romanian: 10 changes by ALEX11BR
ukrainian: 3 changes by StepanIvasyn
spanish: 1 change by MontyMontana
translators
Jonathan G Rennison
Patric Stout
glx22
Michael Lutz
Limyx826
Charles Pigott
Owen Rudge
dP
frosch