Previously, tees could go around the start line on some maps, going
directly to the finish line while leaving one tee behind at the start.
By letting that sole tee start and kill itself, the team could be
directly at the finish at time 0:00.
Fix this by requiring every tee of a team to hit the start line before
being able to finish. Tees can still get some advantage by skipping the
start line, but it will no longer be a 0:00 finish.
3930: Still allow lock/unlock/practice while sv_chat_initial_delay is set r=Jupeyy a=def-
Not sure if we should just allow them whenever someone is muted
Fixes#3929
<!-- What is the motivation for the changes of this 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 if it works standalone, system.c especially
- [ ] 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>
3927: Forbid votes while being muted r=def- a=heinrich5991
Fixes the problem of people abusing the vote reason for spamming.
Fixes#3926.
<!-- What is the motivation for the changes of this 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 if it works standalone, system.c especially
- [ ] 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>
3837: Use "occupado" spawn spots when nothing else is left r=heinrich5991 a=def-
Better than not spawning at all
<!-- What is the motivation for the changes of this 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 if it works standalone, system.c especially
- [ ] 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>
3826: Respect TuneZone for characters r=def- a=TsFreddie
*I might be totally insane for doing this.
*The effect is only truly noticeable if you have high ping AND dropping packets.*
*clang-tidy's warning doesn't seems to relate to anything I've changed*
Now characters will try to respect TuneZones when ~~evolving and~~ predicting (like projectiles do). Since it is really important to keep TuningList as accurate as possible, I made a TuningList update logic so we try our best to update tunings only for the correct TuneZone (instead of constantly shoving current tuning into TuningList)
And each CCharacterCore now has its own Tunings to avoid any characters influencing GameWorld's tuning. Some server code has to be updated accordingly. I checked the code path, didn't notice anything that would make our server behave differently.
And I guess I should tag @trml myself this time.
## 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 if it works standalone, system.c especially
- [ ] Considered possible null pointers and out of bounds array indexing
- [x] Changed no physics that affect existing maps (as far as I could tell)
- [ ] 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: Freddie Wang <tsfreddiewang@gmail.com>
Co-authored-by: def <dennis@felsin9.de>
3792: Add hammer_hit_fire_delay tune r=heinrich5991 a=def-
as requested by J$ON for new map with Genex
the current hammer_fire_delay is only used when no other tee has been
hit. In order not to change any existing behaviour I have added a new
tune for the case of hitting, instead of making the existing one control
both.
<!-- What is the motivation for the changes of this 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 if it works standalone, system.c especially
- [ ] 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>
as requested by J$ON for new map with Genex
the current hammer_fire_delay is only used when no other tee has been
hit. In order not to change any existing behaviour I have added a new
tune for the case of hitting, instead of making the existing one control
both.
With the MySQL C API, we need to distinguish between SQL statements that
return result sets and those that do not, UPDATE is one of those that
don't produce a result set.
Fixes#3725.
