DDraceNetwork - developer

DDraceNetwork

Development / developer

Development discussion. Logged to https://ddnet.tw/irclogs/ Connected with DDNet's IRC channel, Matrix room and GitHub repositories — IRC: #ddnet on Quakenet | Matrix: #ddnet-developer:matrix.org GitHub: https://github.com/ddnet

Between 2018-08-16 00:00:00Z and 2018-08-17 00:00:00Z

my irc is dead :c

[ddnet-maps:master] 1 new commit

39b5f0d A Run Free - def-

@jxsl13 the #ddnet irc channel is quiet anyway

Image attachment

09:07

whats going on here? :c

PM me your IP address

What can I do now? Remove password from my server?

Which mod is it?

ddnet newest version

In any case for ddnet based servers you can remove password, or change ip and not sv_register your server

hm ok

09:59

ty

(changing port probably suffices)

after fixing that crappy old source of mine, it seems that the patch I stated in the exploit issue seems to work

Is it the same patch we have in the ddnet source? (with the vanilla compatible handshake?)

more or less yes

10:12

east patched my zcatch source a few years ago, sadly this never found its way anywhere

please fix https://github.com/ddnet/ddnet/issues/500 before importing it into vanilla

Token handshake a bit brittle · Issue #500 · ddnet/ddnet

Token handshake shouldn't rely on NET_CTRLMSG_ACCEPT, that's not guaranteed to arrive. Probably better to check the first normal message you receive. Vanilla handshake assumes that the clie...

[ddnet/ddnet-web] Pull request opened: #54 Remove frontpage video containing bot

This reverts commit 0fbb33876b98a00c9697aaf1a016cc07a3a52612.

1

12:45

[ddnet/ddnet-web] Pull request closed: #54 Remove frontpage video containing bot

12:46

[ddnet-web:master] 2 new commits

0d0a991 Remove frontpage video containing bot - heinrich5991 2ef039b Merge pull request #54 from heinrich5991/pr_revert_video - def-

[ddnet/ddnet] Pull request opened: #1258 Fix stoppers while retaining backward-compatibility

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.

there we go, a fix for stoppers

15:24

if someone wants to test this, I can produce binaries

@heinrich5991 how is a CANTMOVE_LEFT_TWOWAY different then a CANTMOVE_RIGHT_TWOWAY then a CANTMOVE_RIGHT | CANTMOVE_LEFT?

@Learath2 they are additionally set when the reason for the CANTMOVE is a two-way blocker

15:36

see also the comment in src/game/collision.h, line 20 and 30

pff, stupid backwards compatibility

yeah, that was fun to figure out

15:39

I got out a piece of paper and sat for half an hour or so

collision.cpp L640 has a typo

15:41

also what would "until your center leaves you" mean?

until your center leaves the tile

15:42

that was the typo I just fixed, is there another one in there?

"...so we have just have to stop you from exiting the stopper in the..."

15:43

"...so we just have to..."

done

@heinrich5991 what was a ModPos? modulo pos?

@Learath2 you can test it on the map I provided, btw

15:46

ModPos?

vec2 ModPos = Pos + DirVec(d) * Distance;

15:47

also GetMoveRestrictions basically returns which ways you can't move right?

ah, ModifiedPosition, basically

15:48

yes

15:48

like the constant names suggest

15:48

CANTMOVE_RIGHT

So confusing, who decided that twoway stoppers should behave any different from one way stoppers?

GreYFoX

what is a PureMapIndex?

a map index

15:51

not sure why they called it "pure"

15:51

index into the map array

collision.cpp L657, L654. I'm guessing the magic constants need to match

15:53

also L658, don't we have a define for that somewhere?

no, I grepped

15:53

TILE.*32

weird, how do we even render it?

fixed the magic constant in L657, L654

@heinrich5991 DirCoord gets the velocity in the relevant axis?

and position, etc.

15:55

yes

hmm, could modifying GetMoveResctrictions to only return the relevant restrictions maybe simplify the code?

15:57

guess it's symmetrical

what do you mean by "relevant restrictions only"?

15:58

ah, you mean, depending on the current velocity?

15:58

I don't think that will make the code simpler

e.g. pass direction you are moving in to getmoverestrictions yes

15:58

yeah, won't make any difference

16:01

@heinrich5991 do CANTMOVE_RIGHT/LEFT/UP/DOWN get used? except as intermediaries used to craft the actual flag with TWOWAY and HERE?

yes

16:02

in the rest of the stopper code, see the first PR (edited)

16:08

afk for a while

@heinrich5991 did you consider using one bit to indicate twoway and one bit to indicate here?

16:15

The code looks good to me, I don't see any other way to simplify or clear it up

16:15

maybe the twoway and here being bitflags might help a little

[ddnet:master] 1 new commit

311e89c Fix votes - def-

[ddnet-web:master] 1 new commit

5c2d633 Updated staff - gdin

@Learath2 one bit for twoway and here is too little

23:27

I also have to know in which direction it's one way/here

CANTMOVE_RIGHT already encodes that no?

no

23:28

we can have CANTMOVE_RIGHT|CANTMOVE_RIGHT_HERE|CANTMOVE_DOWN|CANTMOVE_DOWN_TWOWAY

oh true, restrictions don't encode just one tile

23:29

CANTMOVE_DOWN|CANTMOVE_DOWN_TWOWAY

23:29

what does this encode?

23:30

I mean physically

it means that you can't move down, and that there's a twoway stopper below you

23:30

so you can move as long as you're 18 units above the next tile

23:31

*move down

23:33

thanks for looking into the PR so fast, btw **

23:33

^^

Exported 91 message(s)