Render a slim bar below the server browser listbox to show the loading progression, instead of showing a percentage on the Refresh button, as suggested in https://github.com/ddnet/ddnet/pull/5878#issuecomment-1257227947.
The margin around the bottom status elements is removed to make more space and improve the alignment of the elements with the rest of the server browser.
6173: Add README.md for the mastersrv, briefly explaining the setup r=def- a=heinrich5991
## 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: heinrich5991 <heinrich5991@gmail.com>
5886: Send laser objects as DDNetLaser with type (fixes#5885) r=heinrich5991 a=fokkonaut
This pull request will make the server send the correct lasertype directly. The type determining based on EntitiyEx for that got removed on the clientside as it is not needed anymore when using DDNetLaser.
Also, I fixed the NetObject to accept -1 (no owner). That is important in order to be able to render the laser at full opacity for everyone.
This does not only make the color determining more consistent as before (compared to entities using EntitiyEx and shotgun/laser using DDNetLaser), but it does also make it entirely more mod-friendly. As an example in my mod I dont use EntitiyEx to save objects in the snapshot, as we still dont have an extended snapshot system, and like this we can still have colors without doubling the amount of objects.
Also, this will color the dragger beam aswell as the plasma bullets being shot by the freeze/unfreeze/explosive laser gun correctly.
This PR should get applied for the next minor update on client & server.
## 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: fokkonaut <35420825+fokkonaut@users.noreply.github.com>
6170: Use CMake cache instead of extra file for shader compile, fix typos r=def- a=Jupeyy
<!-- 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: Jupeyy <jupjopjap@gmail.com>
6171: Remove unused variable m_Force in CProjectile r=def- a=Zwelf
Simplifies the code a bit.
## 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>
6167: Make tileflag names consistent with automappers r=def- a=Patiga
Follow-up to commit a4867d29c6
- `TILEFLAG_FLIP_HORIZONTAL` -> `TILEFLAG_XFLIP`
- `TILEFLAG_FLIP_VERTICAL` -> `TILEFLAG_YFLIP`
In the previous commit, I pretty much just switched `V` and `H` and
changed the naming a little more to break further uses.
The reason was that the two flags were called counter-intuitively.
Since then, I realized that the auto mapper syntax also already faced
this issue and is already using `XFLIP` and `YFLIP`.
For more consistency and to reduce the amount of names for these flips,
these flags should also be called like that.
It also turned out that more things are connected to `V` and `H`.
Those letters are shown in the `Info` mode in the editor, and are used
extensively by the automapper community.
Switching to `X` and `Y` allows keeping backwards compatibility while
introducing more intuitive names.
<!-- 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: Patiga <dev@patiga.eu>
Follow-up to commit a4867d29c6
- `TILEFLAG_FLIP_HORIZONTAL` -> `TILEFLAG_XFLIP`
- `TILEFLAG_FLIP_VERTICAL` -> `TILEFLAG_YFLIP`
In the previous commit, I pretty much just switched `V` and `H` and
changed the naming a little more to break further uses.
The reason was that the two flags were called counter-intuitively.
Since then, I realized that the auto mapper syntax also already faced
this issue and is already using `XFLIP` and `YFLIP`.
For more consistency and to reduce the amount of names for these flips,
these flags should also be called like that.
It also turned out that more things are connected to `V` and `H`.
Those letters are shown in the `Info` mode in the editor, and are used
extensively by the automapper community.
Switching to `X` and `Y` allows keeping backwards compatibility while
introducing more intuitive names.
6163: Add tooltips for the buttons that open directories and files r=Jupeyy a=Robyt3
Closes#5653.
## 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>
6162: Fix smooth zooming overshooting the target zoom level r=Chairn a=Robyt3
Ensure that the zoom level with smooth zooming does not exceed the target zoom level.
Closes#3747.
## 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>
6160: Add support for hot-plugging gamecontrollers r=def- a=Robyt3
Handle the appropriate SDL events to open new joysticks when they are connected and remove joysticks when they are disconnected.
If the active joystick gets disconnected, then the first joystick in the list will be activated as a fallback.
If the previously activated joystick gets reconnected, it will be activated again automatically, as it is identified by the GUID stored in the configuration.
The stored joystick GUID is only updated when the user manually selects a new joystick in the controls settings or with the console.
Closes#6152.
## 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>
Instead of passing the generic `SDL_Event` to the handler functions and getting the specific structure inside the functions, pass the specific structure directly to the functions.
Handle the appropriate SDL events to open new joysticks when they are connected and remove joysticks when they are disconnected.
If the active joystick gets disconnected, then the first joystick in the list will be activated as a fallback.
If the previously activated joystick gets reconnected, it will be activated again automatically, as it is identified by the GUID stored in the configuration.
The stored joystick GUID is only updated when the user manually selects a new joystick in the controls settings or with the console.
Closes#6152.
6153: Handle ordinal joystick hat keys as combined cardinal hat keys r=def- a=Robyt3
Instead of considering diagonal hat inputs (e.g. up-left) as separate keys, consider them as inputs for both cardinal directions (e.g. up and left) at the same time.
This improves input with gamecontrollers that map the D-Pad to a joystick hat, as it was impossible with the previous handling to move with hat-left/right and jump with hat-up at the same time.
This means that diagonal hat buttons can no longer be used in binds, because they are no longer considered distinct buttons. It's unlikely that they would ever be useful in this game, as real joystick POV hats would not be used anyway.
Closes#6120.
## 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>
Instead of considering diagonal hat inputs (e.g. up-left) as separate keys, consider them as inputs for both cardinal directions (e.g. up and left) at the same time.
This improves input with gamecontrollers that map the D-Pad to a joystick hat, as it was impossible with the previous handling to move with hat-left/right and jump with hat-up at the same time.
This means that diagonal hat buttons can no longer be used in binds, because they are no longer considered distinct buttons. It's unlikely that they would ever be useful in this game, as real joystick POV hats would not be used anyway.
Closes#6120.
6150: Recreate all entities when restarting round, fix server crash on maps with more than 64 spawn points of same type r=def- a=Robyt3
## 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
- [X] 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>
Calculate `Pos` in `OnEntity` based on `x` and `y` instead of passing `Pos` and calculating `x` and `y` from that.
This removes duplicate code and makes it easier to understand.
When restarting a round (i.e. with the `restart` command, with the `sv_warmup` option, and after a round ends) some entities where permanently destroyed and others were kept around.
This is changed so all entities are destroyed and then recreated, so rounds can be properly restarted.
Closes#6128.
Using more than 64 spawn points of the same type causes out-of-bounds accesses, as the number of spawn points is not checked before adding a spawn point and the existing check that limits the number of spawn points after adding one contains an off-by-one error.
For neutral and red spawn points this caused the last spawn point to be added for the following team instead. For blue spawn points this caused a server crash.
This is fixed by allowing an arbitrary number of spawn points of all types, by using an `std::vector` instead of an array.
6146: Instruct to use rustup/rustc-mozilla on older Debian/Ubuntu (fixes#6145) 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: Dennis Felsing <dennis@felsin9.de>
6147: Use %zu formatter for size_t, not PRIu64 (which is for uint64_t) r=heinrich5991 a=def-
Issues found in the logs from https://github.com/ddnet/ddnet/issues/6145
## 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: Dennis Felsing <dennis@felsin9.de>
/usr/include/c++/8/bits/stl_vector.h: In member function ‘void CCommandProcessorFragment_Vulkan::CleanupVulkan() [with bool IsLastCleanup = true]’:
/usr/include/c++/8/bits/stl_vector.h:1085:4: note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator<CCommandProcessorFragment_Vulkan::SMemoryBlock<2>*, std::vector<CCommandProcessorFragment_Vulkan::SMemoryBlock<2>, std::allocator<CCommandProcessorFragment_Vulkan::SMemoryBlock<2> > > >’ changed in GCC 7.1
_M_realloc_insert(end(), __x);
^~~~~~~~~~~~~~~~~
6143: Add separate `ed_limit_max_zoom_level` for editor, fix editor smooth zooming when joining/reloading game r=def- a=Robyt3
## 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>
6142: Adjust no weak prediction to updated server code r=def- a=Jupeyy
Tho i didnt see a wrong prediction with hook which probably makes sense, it probs only affects weapons, as thats the main part the server code was updated for
## 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: Jupeyy <jupjopjap@gmail.com>
Using `IClient::LocalTime` for smooth zooming in the editor causes the zoom to behave incorrectly when joining a game, as the local time is reset when joining a game.
This is fixed by adding a separate `IClient::GlobalTime` which is only set once when the client launches and never resets.
6137: Improve move_sqlite script to adapt timezone r=def- a=Zwelf
Fixes#6105
This change does some more stuff:
* change the filename to include the time with seconds to be able to run the script easier more often
* Fix that _backup tables are only moved after 1h and not immidiately in UTC+1
* Add a parameter to configure the number of minutes the backup
* Add parameter to change timestamps to be in localtime
* consider the timeout in num_transfer calculation
* remove rows in _backup tables to not print in them in the log
* rename tables to TABLES, because it is meant to be a constant
## Checklist
- [x] Tested the change ingame relative throughout
- [ ] 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>
6136: Also ignore sqlite-shm and sqlite-wal files r=Zwelf a=def-
See https://www.sqlite.org/tempfiles.html
## 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: Dennis Felsing <dennis@felsin9.de>
This change does some more stuff:
* change the filename to include the time with seconds to be able to run
the script easier more often
* Fix that _backup tables are only moved after 1h and not immidiately in
UTC+1
* Add a parameter to configure the number of minutes the backup
* Add parameter to change timestamps to be in localtime
* consider the timeout in num_transfer calculation
* remove rows in _backup tables to not print in them in the log
* rename tables to TABLES, because it is meant to be a constant
6133: Remove spammy log (thanks Skeith) 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: Dennis Felsing <dennis@felsin9.de>
6132: Make tileflag names consistent and intuitive r=def- a=Patiga
- `TILEFLAG_VFLIP` -> `TILEFLAG_FLIP_HORIZONTAL`
- `TILEFLAG_HFLIP` -> `TILEFLAG_FLIP_VERTICAL`
According to the native editor, the "Tiled" editor and image search, a horizontal flip should be associated with switching left and right, modifying the x coordinate.
I did not just switch the letters `H` and `V` to create compiler errors where the original constants are used.
Whenever I was working with tileflags, the naming caused me to have no idea what I was doing. I mostly had to resort to opening the resulting map in the editor to see what the code does. This change aims to make the naming intuitive and also consistent with the map editor.
## 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: Patiga <dev@patiga.eu>
- `TILEFLAG_VFLIP` -> `TILEFLAG_FLIP_HORIZONTAL`
- `TILEFLAG_HFLIP` -> `TILEFLAG_FLIP_VERTICAL`
According to the native editor, the "Tiled" editor and image search, a
horizontal flip should be associated with switching left and right, modifying
the x coordinate.
I did not just switch the letters `H` and `V` to create compiler errors
where the original constants are used.
Whenever I was working with tileflags, the naming caused me to have no
idea what I was doing. I mostly had to resort to opening the resulting
map in the editor to see what the code does. This change aims to make
the naming intuitive and also consistent with the map editor.
