Use the `DoButtonLogic` function directly for the key reader buttons in the controls settings. Now, the key reader will only be activated when the left click is initiated and completed inside the key reader button. Previously, the key reader would be activated immediately when holding the left mouse button from outside and then hovering the key reader, and the key reader was already activated by the press-event, whereas now it will only be activated by the release event of the left mouse button. The active key reader UI ID is now tracked as a member variable of `CMenusKeyBinder` to avoid using static variables for this purpose.
The scrollregion scrollbar was not being deactivated if the handle is continued to be hovered after releasing it, causing the handle to become offset with the position of the click on the next activation of the handle.
The seekbar is immediately activated if the mouse button is held while moving the mouse over the seekbar, which is inconsistent with the general `DoButtonLogic` behavior. This is problematic on Android, where the first mouse button is always pressed while the mouse is being moved, causing the seekbar to steal focus immediately when hovered.
The tooltip was not shown if the seekbar is the active item, i.e. when the first mouse button is held down and the seekbar is currently updating the demo player.
Assume every server that does not have ddnet or race in its gametype to be a pvp server.
This allows spectators to follow multiple players during a fng/ctf/gctf/ictf round.
Related issue #7509
The `-1` in the size calculation for the ringbuffer allocation of chat history entries was incorrect, so the entries potentially didn't fit the zero terminator. Because `mem_copy` was used, the string was also not zero terminated explicitly.
This reverts commit f319ed239a.
Initializing these variables with junk data doesn't seem to be an
improvement over not initializing them. It hides potential Valgrind
warnings about data accesses to uninitialized memory though.
f319ed239a (r1590801501)
Nudge the initial position for explosions' smoke particles slightly towards the edge of the closest non-solid tile, if it would otherwise be inside a solid tile, so the smoke particles do not get stuck inside solid tiles on explosion events happening at the edges of tiles but slightly inside them. The physical position of the explosion event is unchanged, so this does not affect physics. The explosion sprite is still rendered at the physical position of the explosion, to preserve the apprearance.
ChillerDragon
