This reverts commit 968172d.

Revert "Update translations."

This reverts commit 29a0bd7.

Closes #1347.

Closes #3483.

Closes #3485.

Closes #3486.

Closes #3484.

Thanks to pabs for noticing one of them. Closes #3495.

Fixes ticket:3493.

fixes ticket:3384

Problem persisted until the frozen client drops completely, or unfreezes (net connection is restored).

To reproduce, test with host and 2 other clients, and freeze one client with kill -STOP or by pausing the net
connection somehow.

Cause was lack of flushing, due to an inverted condition exposed in b9cc770 and
introduced in c1ca4d2. Would probably trigger before
b9cc770, for any remaining clients that freeze for any reason (for example, because
of <2.5 FPS or momentary hard drive swapping) for more than 400ms.

Nexus was building units with an unresearched sensor (equivalent to the default sensor). Since
6365f2d, Nexus can no longer build unresearched units.

In the tutorial, the designed MG viper wheels would also use the same unresearched sensor.

Replaced unresearched DefaultSensor1Mk1 with ZNULLSENSOR. Removed special case for tutorial in
7079ad2, which is no longer required.

… type.

Previous unconventional behaviour was to consider the set of previously-unselected droids becoming selected, and
report the size of the set plus the size of the set of types of droids in the set.

Iff there was exactly one droid of each type previously selected, and there was at least one unselected droid of
each selected type, then the reported unit count would coincidentally be correct.

Fixes ticket:3479.

Fixes ticket:3461.

…tefact.

Fixes ticket:3488.

…blocking.

For some weird reason, select() sometimes returns that a socket write would not block, but the socket write does
block, anyway.

On display in the bottom of a locked manpage for select(), stuck in a disused lavatory with a sign on the door
saying "Beware of the Leopard":
BUGS
       Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a
       subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong
       checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously
       reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block.

This would explain a socket read unexpectedly blocking, although the issue is actually a socket write unexpectedly
blocking.

Fixes ticket:3410, or else.

Abandoned structures with no cost now slowly deconstruct over a period of one minute.

Add error sound, and text when you can't add any more units to the Commander.

Fixes ticket:3513
Fixes ticket:3062

…escribed in said ticket.

Close ticket #3154

…oop.

Spurious assertions are possible in the case that the research tree is excessively interconnected, such as
researches 31-40 all depending on all of researches 21-30, and researches 21-30 all depending on all researches
11-20, and so on. Although it probably shouldn't assert on excessively interconnected research trees, the loop as
written could take a ridiculously long time, anyway.

Closes #3512.

Fix by Emdek, closes #3519.

Also remove unneeded "import os".

Exposed in 53ce0a7.

Somehow fixes a client crash when failing to join a game. Possibly caused by deleting one of bsocket or tcp_socket,
and then using the other.

…CTED.

Don't wait for a NET_ACCEPTED after the socket is broken, either.

NET_CreatePlayer() should not be able to fail here, though. See following commit.

Crash was due to treating ERROR_FULL == 2 as an uint8_t pointer, and trying to dereference it.

Although it no longer crashed when trying to join a game with some closed slots (see previous commits), it is also
desirable to actually be able to join it.

Instead of sending a copy of broadcast messages back to the sender, which ignores them anyway, save the bandwidth.

No need to check for NET_* messages in game queues.

Desynch was due to host-spoofed GAME_PLAYER_LEFT message being processed by clients at random times.

Instead of putting the GAME_PLAYER_LEFT in a NET_SHARE_GAME_QUEUE, put the GAME_PLAYER_LEFT in a NET_SHARE_GAME_QUEUE
in a NET_SEND_TO_PLAYER, such that the clients' NETrecvNet() will process the GAME_PLAYER_LEFT in the same iteration
of the for (current = 0; current < MAX_CONNECTED_PLAYERS; ++current) loop as the real GAME_* messages from that
player, and therefore not mix up the messages.

To reproduce before this commit, start 8-or-so clients, set all to debug mode, change game speed of some clients
slightly, start kicking players. Keep trying again, until desynch is reproduced. Changing game speed of some clients
might or might not be required.

See 93f0e61.

Requires optipng 0.7.1+ to work.

Actual construction only starts after the oil well finishes burning.

Steps to reproduce:
1) Player A builds a CB sensor.
2) Player B attacks the CB sensor with a mortar borg.
3) Player B runs away with the mortar borg where player A can't see.
4) Player A builds artillery.
5) Player B slowly kills off all the artillery with an MG viper wheels tank, while the artillery just sits there
   pointing at the mortar borg without firing.

To trigger, the artillery must be built after the last CB sensor in range of where the mortar borg attacks. Any
type of mobile artillery can trigger the bug, such as archangel leopard tracks, or MRA dragon wheels.

Workaround: Player A can build an uplink, so that the mortar borg becomes visible, and the artillery fires. If
            there's still anything left of the artillery by the time the uplink is built, that is.

Fixes ticket:3529.

The tools/image/image in .gitignore was mysteriously changed to be a directory only in
c346e9e, and the file therefore fails to be ignored.