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>
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.
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>
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.