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>
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.
3492: Support F-Client and replace non-extended extension messages r=Learath2 a=heinrich5991
This continues what #3439 started, and also replaces non-extended messages that are DDRace extensions with extended messages. The DDNet server still sends the old message to old clients and the DDNet client still understands the old messages.
Supersedes #3439.
## 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
- [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)
3559: Don't highlight us if we have no name (alternative fix for #3554) r=heinrich5991 a=def-
<!-- 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
- [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)
3561: Fix input message position in teehistorian files r=heinrich5991 a=Zwelf
Previously the message was recorded when incoming. But the time when the input should apply wasn't recorded. Now inputs are recorded right before they get applied in the game world.
And record exact tick where load/save result is returned.
## 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
- [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)
3565: Add Arabic language translation by .Yukki r=heinrich5991 a=def-
## Checklist
- [x] Tested the change ingame
- [x] Provided screenshots if it is a visual change
- [x] 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: fokkonaut <35420825+fokkonaut@users.noreply.github.com>
Co-authored-by: heinrich5991 <heinrich5991@gmail.com>
Co-authored-by: def <dennis@felsin9.de>
Co-authored-by: Zwelf <zwelf@strct.cc>
3343: rescue on freeze/dfreeze (supersedes #3335) r=heinrich5991 a=def-
Fixed all the merges and clang-format (hopefully)
## 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: Vlad <gerdoexx@gmail.com>
3523: Handle switch number 0 r=heinrich5991 a=def-
Thanks to ReD for report
<!-- 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
- [x] 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)
Co-authored-by: def <dennis@felsin9.de>
GameServer()->SendEmoticon() sends CNetMsg_Sv_Emoticon packet to everyone.
Calling SendEmoticon() from Character::Snap(ClientID) triggers as many
messages to everyone as there are active players.
Move the SendEmoticon() because it is not the Character (a world entity object)
responsibility to celebrate a day. Actually it is not CPlayer responsibility
either but CPlayer is the class where we deciding to celebrate (checking the
date) so at least let's keep the coupled stuff together.
The PLAYERFLAG_AIM can now be set directly on DDNet servers via the 0.7
bridge and will be sent to clients identifying themselves as DDNet
clients.
Add a new extended message that mirror the old `Sv_TeamsState`.
3340: Fix vec_base constructors & remove useless operator r=heinrich5991 a=Jupeyy
Interestingly besides it found unused variables, this also found some "logic" errors, where vectors were used in `if`.
## 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: Jupeyy <jupjopjap@gmail.com>
3316: Disable ninja jetpack when player has telegun r=heinrich5991 a=def-
Required for map Taceht because of weapon tele interaction with jetpack
As requested by Cøke
## 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>
Co-authored-by: Dennis Felsing <dennis@felsin9.de>
How did this not blow up all day long for years?!
Found by UBSAN:
/home/teeworlds/src/master/src/game/server/entities/dragger.cpp:32:29: runtime error: member call on address 0x0000013319b8 which does not point to an object of type 'CCharacter'
0x0000013319b8: note: object has invalid vptr
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
#0 0x5501de in CDragger::Move() /home/teeworlds/src/master/src/game/server/entities/dragger.cpp:32:29
#1 0x5522c2 in CDragger::Tick() /home/teeworlds/src/master/src/game/server/entities/dragger.cpp:153:3
#2 0x5eb11e in CGameWorld::Tick() /home/teeworlds/src/master/src/game/server/gameworld.cpp:261:11
#3 0x58d660 in CGameContext::OnTick() /home/teeworlds/src/master/src/game/server/gamecontext.cpp:751:10
#4 0x4afefe in CServer::Run() /home/teeworlds/src/master/src/engine/server/server.cpp:2558:19
#5 0x4c26fd in main /home/teeworlds/src/master/src/engine/server/server.cpp:3551:21
#6 0x7f2c8cc9309a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
#7 0x451509 in _start (/home/teeworlds/servers/DDNet-Server-ubsan+0x451509)
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
2478: Use (u)int64 from system.h instead of (u)int64_t from cstdint r=heinrich5991 a=def-
src/game/client/prediction/gameworld.h:62:90: error: ‘int64_t’ has not been declared
62 | void CreateExplosion(vec2 Pos, int Owner, int Weapon, bool NoDamage, int ActivatedTeam, int64_t Mask);
| ^~~~~~~
2480: Send zoom status for dummy too r=heinrich5991 a=def-
Co-authored-by: def <dennis@felsin9.de>
src/game/client/prediction/gameworld.h:62:90: error: ‘int64_t’ has not been declared
62 | void CreateExplosion(vec2 Pos, int Owner, int Weapon, bool NoDamage, int ActivatedTeam, int64_t Mask);
| ^~~~~~~
2401: Client tells server its zoom level (fixes#2087) r=heinrich5991 a=def-
and server adapts the visible distance to it
Co-authored-by: def <dennis@felsin9.de>
2202: Send DDNet version early in the connection process r=Learath2 a=heinrich5991
This gets rid of the problem that we don't know whether we should send
full snapshots to clients because they haven't told us about them being
DDNet yet.
Co-authored-by: heinrich5991 <heinrich5991@gmail.com>
2212: Use a consistent PRNG on all platforms r=Learath2 a=heinrich5991
I just used glibc's because that is what we use on all the servers. Based on https://www.mscs.dal.ca/~selinger/random/.
Behavior change: The PRNG is actually seeded now.
Co-authored-by: heinrich5991 <heinrich5991@gmail.com>
As discussed on Discord today, can be enabled inside of teams on the fly
during each run on any server. Finishes don't count. I haven't tested
save/load yet, would do that live on the server if this can be merged.
This gets rid of the problem that we don't know whether we should send
full snapshots to clients because they haven't told us about them being
DDNet yet.
as Mac build complains:
src/game/server/entities/character.cpp:1681:18: error: ordered comparison between pointer and zero ('const float *' and 'int')
if(m_Core.m_Vel > 0 && (m_MoveRestrictions&CANTMOVE_DOWN))
~~~~~~~~~~~~ ^ ~
1922: Allow to hammer directly on unfreeze r=def- a=heinrich5991
Previously, this was only doable with frame-perfect input if you were
going to get frozen again the next tick. Now, you only have to hold your
hammer to immediately hammer once you get unfrozen.
This fixes that "deepfly" (flying with deep-frozen dummy, binding both
main and dummy tee hammers onto the same key) does not only work for
good connection.
Co-authored-by: heinrich5991 <heinrich5991@gmail.com>
1938: Explode grenades twice at the end if they have lifespans. Fix#1559 r=heinrich5991 a=Learath2
Just by looking at the code I think this is what was intended but only testing can make sure.
Co-authored-by: Learath <learath2@gmail.com>
Previously, this was only doable with frame-perfect input if you were
going to get frozen again the next tick. Now, you only have to hold your
hammer to immediately hammer once you get unfrozen.
This fixes that "deepfly" (flying with deep-frozen dummy, binding both
main and dummy tee hammers onto the same key) does not only work for
good connection.
Remove the whole copy-and-paste mess.
A seemingly ineffective and apparently code block has been removed.
The broken front layer from the first try has been fixed.
1878: Add paused and spec to explayerflags r=Learath2 a=Ryozuki
I think client should know about this, maybe we can do something with it in the future.
It also may help with https://github.com/ddnet/ddnet/issues/259 but i didn't figure out yet a way to fix it.
1903: Consistent spacing for getters and setters r=Learath2 a=ChillerDragon
Co-authored-by: Ryozuki <ryo@ryozuki.xyz>
Co-authored-by: ChillerDragon <chillerdragon@gmail.com>
1678: Handle colors in console r=def- a=Learath2
DEPENDS: #1654
A better way to fix#1581 possibly deprecates #1597
Co-authored-by: Learath <learath2@gmail.com>
1663: Use freeze end tick instead of a flag. Fix#1659 r=def- a=Learath2
I used -1 for deep frozen, and 0 for not frozen. Not really sure if this is the best way.
Co-authored-by: Learath <learath2@gmail.com>
1620: Rewrite of prediction code, with additional prediction (updated) r=def- a=trml
This is a reworked attempt at a rewrite of the prediction code (#464), to allow for more client side prediction. It doesn't fix the duplication of server code, but the client code should otherwise be cleaner. This includes separating prediction code out of gamecore/gameclient, and a refactor of the rendering of predicted characters.
There is also prediction for some new things, and some other changes:
- prediction of laser, shotgun, ninja, fng hammer, pickups and ddrace tiles (freeze/unfreeze tiles with cl_predict_freeze)
- laser and bullets are rendered when you fire them and bullets don't go through walls (when both cl_antiping_grenade and cl_antiping_weapons are enabled)
- antiping for flags
- prediction of dummy input
- an additional smoothing option that attempts to make antiping less jumpy (cl_antiping_smooth)
Co-authored-by: trml <trml@users.noreply.github.com>
Co-authored-by: trml <trml@noreply.github.com>
1655: Add delete projectiles on death settings r=def- a=12pm
Need this for a map fix and doesn't hurt to have for grenades too I guess. Defaults are still the same
Co-authored-by: 12pm <30786226+12pm@users.noreply.github.com>
1628: Make client know about other solo players, fixes#258 r=heinrich5991 a=Ryozuki
When another player is in solo and you are not, you could notice a weird collision and also the hook moving a little towards the solo player. This as been fixed.
It also applies m_ClShowOthersAlpha to other players whenever you are on solo or others are.
It uses the protocol extension thingy.
fixes#258
Co-authored-by: Ryozuki <ryo@ryozuki.xyz>
Co-authored-by: Learath <learath2@gmail.com>
1598: Fix home/end keys in console r=heinrich5991 a=def-
1601: 2 more tries to force DB to respond in UTF8 (fixes#1599) r=heinrich5991 a=def-
1605: Fix memory leak in draggers r=heinrich5991 a=def-
1606: Always initialize m_InfosLoaded r=heinrich5991 a=def-
otherwise it's uninitialized and then read, found by valgrind --tool=memcheck
1607: Enable a few more GCC warnings r=heinrich5991 a=def-
1609: Fix C90 compatibility on Windows r=heinrich5991 a=def-
Co-authored-by: def <dennis@felsin9.de>
Stopper behavior is only changed when the player would otherwise go
entirely through the stopper. Players can still enter a stopper as far
as the stopper can still affect them. One-way blockers have a bigger
range, and thus allow tees to enter furtherly.
A possible (manual) test map for this is test_stoppers.map, sha256sum
ed8be386e54a03d7bd7ed69fdd962c86f51f654427972d58d492c8905c8fbdb7, crc
48812a51.
https://cdn.discordapp.com/attachments/293493549758939136/461236206131478538/PainWeaponBug.gif
because I'm new to coding it took me 2 hours to find this bug. I spent a while looking at the POWERUP_ARMOR and RemoveNinja() code wondering why it didn't work.
this bug is funny to some players so maybe you don't want to fix it. i wont mind because it was a challange for me to find it
Edgar
ChillerDragon
