Most but not all sound creations in CCharacter::FireWeapon have this NOLINT comment.
Somehow clang does not get tripped on all of those. But sooner or later it might.
I currently got a new error in my downstream fork when tweaking
FireWeapon a bit. So I applied the NOLINT comment to ALL occurences in
FireWeapon not only the ones that clangd finds at the moment.
Following sequence of events was possible:
1. HTTP map download for map X is started (e.g. client initially connects to server).
2. Map change message for map Y arrives while downloading (e.g. vote for another map has passed on the server).
3. Client already has map Y and loads it directly without starting or resetting the map download.
4. HTTP map download task for map X finishes.
5. Map X is loaded, overriding the map Y that should be loaded. This is one cause for #2804.
This could potentially also happen with the map download from the game-server, if the final map data chunk for a downloaded map is received directly after another map change message for a map which does not need to be downloaded, though this seems more unlikely.
This is fixed by resetting the current map download immediately after receiving a valid map change message instead of only when starting a new map download.
The relevant code to reset the map download is moved to `CClient::ResetMapDownload` to avoid duplicate code and ensure that the temporary map download file is always deleted and closed.
* Fixes OpenGL on Wayland when the GLX flavor of GLEW is linked
* Only if SDL2's video driver is "wayland" we also allow the
GLEW_ERROR_NO_GLX_DISPLAY error code to be accepted as if glewInit()
actually succeeded
* Hopefully this won't be needed anymore on future versions of GLEW when
glewContextInit() is made part of the public API
5cf0e5e997/datasrc/network.py (L8)5cf0e5e997/datasrc/seven/network.py (L10)
0.6 game flags:
```python
GameFlags = ["TEAMS", "FLAGS"]
```
0.7 game flags:
```python
GameFlags = Flags("GAMEFLAG", ["TEAMS", "FLAGS", "SURVIVAL", "RACE"])
```
The 0.7 protocol extended the game flags without changing the old 0.6 flags.
So flag teams and flag flags are the same in both versions and 0.7 just
has additional flags.
The server is now sending the same m_GameFlags from the gamemode
controller to 0.6 and 0.7 connections. It clamps away the unsupported
flags for 0.6.
Before this commit the ddnet server would always send the hardcodet race
flag to 0.7 connections while ignoring what the gamemode set as a game
flag.
Gradle can determine the NDK version automatically and this property is only required if multiple NDK versions are installed. The NDK version previously determined from the filename could not be parsed by Gradle anyway.
ChillerDragon
