2758: Remove the rudimentary fuzzing since no one uses it anyway r=heinrich5991 a=def-
2769: Update front.png by Soreu r=heinrich5991 a=def-
2772: Dont predict camera position on spectator changed r=heinrich5991 a=BannZay
No reason to predict camera position in case when we just changed spectator.
But tbh I have not found a big reason to predict it at all.
Co-authored-by: def <dennis@felsin9.de>
Co-authored-by: Andrii <bannzay3@gmail.com>
2747: Fix proof circle position in editor r=heinrich5991 a=def-
As reported by Ravie on Discord. Tee is not drawn exactly in center.
Co-authored-by: def <dennis@felsin9.de>
2742: Add str_utf8_copy that trim broken utf8 sequence at the end. r=heinrich5991 a=TsFreddie
Currently this replaces `str_copy` text input and clipboard paste in chat. Many places may need the same treatments, like steam names.
Test string:
abcd今天是个好日子心想的事儿都能成今天是个好日子打开了家门咱迎春风今天是个好日子心想的事儿都能成今天是个好日子打开了家门咱迎春风今天是个好日子心想的事儿都能成今天是个好日子打
2745: Update mapres by mind r=heinrich5991 a=def-
Adapted from 0.7 for new renderer. Not sure if this makes sense :D
Co-authored-by: TsFreddie <tsfreddiewang@gmail.com>
Co-authored-by: def <dennis@felsin9.de>
2767: Don't lock SQL writes r=Zwelf a=def-
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.
Co-authored-by: def <dennis@felsin9.de>
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.
2751: More aggressive analysis & check 2.0 gl Functions that were used r=def- a=Jupeyy
If even that fails, I'm out of ideas
Checks all texture shaders, checks all functions used.
2752: Can't detect if paused on KoG, so don't show button r=def- a=def-
Since they're running an old version of DDNet server
2756: Don't deactivate menu when a popup is active r=def- a=Learath2
Deactivating menu while a popup is active causes the menu to never open again.
Reported by Anxton on discord.
Co-authored-by: Jupeyy <jupjopjap@gmail.com>
Co-authored-by: def <dennis@felsin9.de>
Co-authored-by: Learath <learath2@gmail.com>
