6226: Remove projectiles on save and load r=def- a=Zwelf
Restructured CSaveTeam a bit, because I also needed access to CGameWorld. I don't store pointer to IGameController in CSaveTeam anymore, because we pass CSaveTeam to the database thread. If it would be accessed there, it could cause a race conditions.
## Checklist
- [x] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test (especially base/) or added coverage to integration test
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [x] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
6230: For integrated and discrete GPUs always prefer what comes first in the list r=def- a=Jupeyy
fixes#6200
## Checklist
- [ ] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test (especially base/) or added coverage to integration test
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: Zwelf <zwelf@strct.cc>
Co-authored-by: Jupeyy <jupjopjap@gmail.com>
Restructured CSaveTeam a bit, because I also needed access to CGameWorld. I don't store pointer to IGameController in CSaveTeam anymore, because we pass CSaveTeam to the database thread. If it would be accessed there, it could cause a race conditions.
6180: Implement exact matches in search and exclude strings r=Robyt3 a=def-
Thanks to bencie for discussion
<!-- What is the motivation for the changes of this pull request? -->
<!-- Note that builds and other checks will be run for your change. Don't feel intimidated by failures in some of the checks. If you can't resolve them yourself, experienced devs can also resolve them before merging your pull request. -->
## Checklist
- [x] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test (especially base/) or added coverage to integration test
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: Dennis Felsing <dennis@felsin9.de>
6156: Swap times should be per player, not per team (fixes#6155) r=Learath2 a=def-
<!-- What is the motivation for the changes of this pull request? -->
<!-- Note that builds and other checks will be run for your change. Don't feel intimidated by failures in some of the checks. If you can't resolve them yourself, experienced devs can also resolve them before merging your pull request. -->
## Checklist
- [x] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test (especially base/) or added coverage to integration test
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: def <dennis@felsin9.de>
When the demo recording is not stopped properly (e.g. client crashes during recording), the timeline markers and the demo length are not updated.
The length is always set to zero when starting the recording, but uninitialized memory is written for the timeline markers, which causes these demos to likely show the maximum number of markers with some markers possibly being outside the ticks that the demo contains.
This is fixed by initially setting all timeline marker data to zero when starting the recording.
Swap mathematical operations to avoid multiplication by `1000`. As `time_freq()` returns the nanoseconds in a second (1e9), first dividing this number by 1000 does not lose any precision.
Also ensure that `IntendedTick` is in the valid range of ticks.
```
src/engine/server/server.cpp:1585:64: runtime error: signed integer overflow: 24185120014282423 * 1000 cannot be represented in type 'long int'
0 0x55c165f220aa in CServer::ProcessClientPacket(CNetChunk*) src/engine/server/server.cpp:1579
1 0x55c165f3a8d3 in CServer::PumpNetwork(bool) src/engine/server/server.cpp:2383
2 0x55c165f51166 in CServer::Run() src/engine/server/server.cpp:2821
3 0x55c165eb37d0 in main src/engine/server/main.cpp:191
4 0x7f99e4c3ad8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
5 0x7f99e4c3ae3f in __libc_start_main_impl ../csu/libc-start.c:392
6 0x55c165e7ab64 in _start (build-asan/DDNet-Server+0xd7ab64)
```
The include of `base/system.h` in `src/engine/shared/protocol.h` is not required and only used transitively in `teamscore.h` for `dbg_assert`.
To avoid adding back the include in `teamscore.h`, the function definitions are moved to the cpp file. Both definitions are moved for consistency.
6217: Register application separately to specify its displayed name r=def- a=Robyt3
Follow-up from #6199.
Adding version information to the executable (#6203) doesn't result in the name being shown in the Windows settings. There is a separate registry key where applications can register a readable name.
See: https://learn.microsoft.com/en-us/windows/win32/shell/app-registration
## Checklist
- [X] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test (especially base/) or added coverage to integration test
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: Robert Müller <robytemueller@gmail.com>
6216: Follow-up fix to scoreboard showing wrong best time r=Zwelf a=def-
Forgot the call in constructor in https://github.com/ddnet/ddnet/pull/6213/
Thus best time was not displayed initially. Thanks to spur for report
<!-- What is the motivation for the changes of this pull request? -->
<!-- Note that builds and other checks will be run for your change. Don't feel intimidated by failures in some of the checks. If you can't resolve them yourself, experienced devs can also resolve them before merging your pull request. -->
## Checklist
- [x] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test (especially base/) or added coverage to integration test
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: def <dennis@felsin9.de>
6199: Register protocol and file extensions on client launch on Windows r=def- a=Robyt3
When launching the client on Windows, associate the protocol `ddnet` and the file extensions `.map` and `.demo` with the client executable.
See #6072.
## Checklist
- [X] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test (especially base/) or added coverage to integration test
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: Robert Müller <robytemueller@gmail.com>
6202: Add tool to manually ping the mastersrv r=def- a=heinrich5991
Usage example: `masterping ipv6
https://master1.ddnet.org/ddnet/15/register`.
Returns 0 on success, nonzero on failure. Note that this might report failure occasionally as it doesn't retry, UDP packets are non-reliable so they might not arrive even though the mastersrv is up.
## Checklist
- [x] Tested the change ~~ingame~~
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test (especially base/) or added coverage to integration test
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: heinrich5991 <heinrich5991@gmail.com>
6213: Fix scoreboard showing wrong best time r=Zwelf a=def-
by requesting the best time again when it initially failed. This is still not perfectly accurate since a player on another server can get a better time, which will not get updated when the current server had no database problems.
As reported by thekid36 on Discord:
> The best time shown on the scoreboard on the turkish server on a
> ddmax.Next map (mapname: 42) is 30min..while the best time should be 4
> min (it's correct on ger2 server)
So the way it works is that the best time is loaded from database when loading map. Additionally it gets updated when a new finish is done. If the initial load failed, but a finish with 30 min is done on the server, we get this result
<!-- What is the motivation for the changes of this pull request? -->
<!-- Note that builds and other checks will be run for your change. Don't feel intimidated by failures in some of the checks. If you can't resolve them yourself, experienced devs can also resolve them before merging your pull request. -->
## Checklist
- [ ] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test (especially base/) or added coverage to integration test
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: def <dennis@felsin9.de>
by requesting the best time again when it initially failed. This is
still not perfectly accurate since a player on another server can get a
better time, which will not get updated when the current server had no
database problems.
As reported by thekid36 on Discord:
> The best time shown on the scoreboard on the turkish server on a
> ddmax.Next map (mapname: 42) is 30min..while the best time should be 4
> min (it's correct on ger2 server)
So the way it works is that the best time is loaded from database when
loading map. Additionally it gets updated when a new finish is done. If
the initial load failed, but a finish with 30 min is done on the server,
we get this result
```
src/engine/shared/snapshot.cpp:219:18: runtime error: signed integer overflow: -2011501152 + -1594687485 cannot be represented in type 'int'
0 0x5593cbc3534c in CSnapshotDelta::UndiffItem(int const*, int*, int*, int, int*) src/engine/shared/snapshot.cpp:219
1 0x5593cbc3852d in CSnapshotDelta::UnpackDelta(CSnapshot*, CSnapshot*, void const*, int) src/engine/shared/snapshot.cpp:442
2 0x5593cbb881a6 in CDemoPlayer::DoTick() src/engine/shared/demo.cpp:624
3 0x5593cbb9a907 in CDemoPlayer::Update(bool) src/engine/shared/demo.cpp:1016
4 0x5593ca9f44da in CClient::Update() src/engine/client/client.cpp:2628
5 0x5593caa199dd in CClient::Run() src/engine/client/client.cpp:3220
6 0x5593caa970f3 in main src/engine/client/client.cpp:4717
7 0x7fe086d04d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
8 0x7fe086d04e3f in __libc_start_main_impl ../csu/libc-start.c:392
9 0x5593ca55e6f4 in _start (build-demofuzz/DDNet+0x24936f4)
```
```
src/engine/shared/snapshot.cpp:693:28: runtime error: left shift of negative value -1
0 0x55cae1608071 in CSnapshotBuilder::NewItem(int, int, int) src/engine/shared/snapshot.cpp:686
1 0x55cae1603fe0 in CSnapshotDelta::UnpackDelta(CSnapshot*, CSnapshot*, void const*, int) src/engine/shared/snapshot.cpp:390
2 0x55cae15544c6 in CDemoPlayer::DoTick() src/engine/shared/demo.cpp:624
3 0x55cae1566c27 in CDemoPlayer::Update(bool) src/engine/shared/demo.cpp:1016
4 0x55cae03c07fa in CClient::Update() src/engine/client/client.cpp:2628
5 0x55cae03e5cfd in CClient::Run() src/engine/client/client.cpp:3220
6 0x55cae0463413 in main src/engine/client/client.cpp:4717
7 0x7fbc7d855d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
8 0x7fbc7d855e3f in __libc_start_main_impl ../csu/libc-start.c:392
9 0x55cadff2aa14 in _start (build-demofuzz/DDNet+0x2493a14)
```
6207: Run C++ unit tests with sanitizers (fixes#6205) r=Chairn a=def-
<!-- What is the motivation for the changes of this pull request? -->
<!-- Note that builds and other checks will be run for your change. Don't feel intimidated by failures in some of the checks. If you can't resolve them yourself, experienced devs can also resolve them before merging your pull request. -->
## Checklist
- [ ] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [ ] Written a unit test (especially base/) or added coverage to integration test
- [ ] Considered possible null pointers and out of bounds array indexing
- [ ] Changed no physics that affect existing maps
- [ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: def <dennis@felsin9.de>
6206: Remove possible overflow in str_comp_filenames (fixes#6204) r=def- a=Chairn
## Checklist
- [ ] Tested the change ingame
- [ ] Provided screenshots if it is a visual change
- [ ] Tested in combination with possibly related configuration options
- [x] Written a unit test (especially base/) or added coverage to integration test
- [x] Considered possible null pointers and out of bounds array indexing
- [x] Changed no physics that affect existing maps
- [x] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-addresssanitizer--undefinedbehavioursanitizer-or-valgrinds-memcheck) (optional)
Co-authored-by: Chairn <chairn.nq@hotmail.fr>
Instead of using hardcoded tick offsets, use the current/previous/next tick values from the demo info.
This fixes seeking the next tick not working for demos where the difference between the current and the next tick was greater than 3.
Reasoning this change is correct:
* `OldPos` is set to `m_Pos` in line 260
* `m_Pos` is not modified in between line 260 and 272 (only `m_Core.m_Pos` gets modified)
* Therefore line 269 `Dir = m_Pos - OldPos` is always `vec2(0.0, 0.0)`.
* And line 271 `Center = OldPos + Dir * 0.5 = OldPos`.
So we can pass `OldPos` to `FindEntities` in line 272. Using `OldPos` here instead of `m_Pos` makes it clear, that we use the position before the move, even though `m_Pos` also still holds the old value.
Each time the client disconnected or stopped a demo, it tried to delete the previous temporary replay file, which causes an error message "could not delete file" to be shown in the console.
This is prevented by clearing the current filename of the demo recorder after deleting the file.
This function removes the registry keys that are created with `shell_register_protocol` and `shell_register_extension`.
According to the Microsoft documentation, only the keys for the program IDs should be deleted.
The keys that associate the file extensions with the program IDs should be kept, as Windows will automatically ignore the value if the program ID does not exist.
See: https://learn.microsoft.com/en-us/windows/win32/shell/fa-file-types#deleting-registry-information-during-uninstallation
The `shell_update` function notifies the system when the shell needs to be updated due to a changed protocol or file association.
An output parameter is added to the `shell_register_protocol` and `shell_register_extension` functions, to determine whether the shell needs to be updated after calling the functions.
We only check whether the application path and program association were changed, instead of checking whether any key or value was changed, as this reduces the amount of necessary checks and we assume that the other values are not externally changed.
Because updating the shell is a potentially expensive operation, this should only be done when necessary and only once after registering all protocols and extensions.
This function register a file extension on Windows by creating the necessary registry keys and values.
The file extension is only registered for the current user in the registry key `HKEY_CURRENT_USER\SOFTWARE\Classes`, so admin privileges are not required.
Windows does not allow changing the default file extension handler programatically. When the user opens a file for which a new file extension handler exists, a dialog is shown that allows the user to change the default handler.
This function registers a protocol handler on Windows by creating the necessary registry keys and values.
The handler is only registered for the current user in the registry key `HKEY_CURRENT_USER\SOFTWARE\Classes`, so admin privileges are not required.
Usage example: `masterping ipv6
https://master1.ddnet.org/ddnet/15/register`.
Returns 0 on success, nonzero on failure. Note that this might report
failure occasionally as it doesn't retry, UDP packets are non-reliable
so they might not arrive even though the mastersrv is up.
