3541: rank/teamrank: Display how much better you are r=def- a=def-
## Checklist
- [x] Tested the change ingame
- [x] 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
- [x] 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: def <dennis@felsin9.de>
Co-authored-by: Zwelf <zwelf@strct.cc>
Previously, a save could possibly be loaded twice given enough latency
discrepancy between servers. The server only verified that it deleted
*some* save with the given password, not *the* save it is trying to
load. This is fixed by also checking the SaveID column that is random
and globally unique (except for the old NULLs). Since users can't create
new saves with NULL SaveID, these pose no problem.
Also change the default UUID for saves without save ID to something
nonzero, so we can't accidentally hit it due to a bug.
/media/ddnet/src/engine/server/sql_string_helpers.cpp:74:3: warning: Call to function 'strcpy' is insecure as it does not provide bounding of the memory buffer. Replace unbounded copy functions with analogous functions that support length arguments such as 'strlcpy'. CWE-119 [clang-analyzer-security.insecureAPI.strcpy]
Purely automatic change. In case of conflict with this change, apply the
other change and rerun the formatting to restore it:
$ python scripts/fix_style.py
The slow query logs are full of this:
# Time: 200906 21:03:43
# User@Host: teeworlds[teeworlds] @ ger6.ddnet.tw [89.163.212.120]
# Thread_id: 101540 Schema: teeworlds QC_hit: No
# Query_time: 11.012166 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0
# Rows_affected: 0 Bytes_sent: 67
SET timestamp=1599419023;
LOCK TABLES record_teamrace WRITE, record_teamrace AS r WRITE;
Do we really need these lock? See also
https://dev.mysql.com/doc/refman/5.7/en/table-locking.html
> InnoDB tables use row-level locking so that multiple sessions and
> applications can read from and write to the same table simultaneously,
> without making each other wait or producing inconsistent results. For
> this storage engine, avoid using the LOCK TABLES statement, because it
> does not offer any extra protection, but instead reduces concurrency.
also added protection to shotgun stucks, needs to be tested when a random crazy shotgun bullet gets stuck
loaded the score file before saving to avoid corruption
added freeze and unfreeze in rcon
added protection in some rcon commands
Signed-off-by: GreYFoXGTi <GreYFoXGTi@GMaiL.CoM>
