DDraceNetwork - developer

this is the old jetpack prediction, can anyone tell me how the client knows at this position whether we have jetpack on or off? i dont see any check for e.g. the faketuning or so https://github.com/ddnet/ddnet/commit/0b3f3b03b57c39dfec1506570cf35ce8b7bb1221#diff-0d0221c586efbe7eda89b6e5075098fdL561-L564

This link, no idea why the one above doesnt work https://github.com/ddnet/ddnet/blob/f37f8a8268731e38497dd88f6f95e15bb0e05222/src/game/gamecore.cpp#L561-L564

@Learath2 there are some issues with the chat commands. First: args are not shown, second: when just giving a parameter, like ?i, without a [Description], it will make something weird, for example adds a <string> to the arg list

Where, in the latest version of the pr?

yes

I'd ask you to just debug it but I doubt you'll even give it a go, so I'll take a look later tomorrow

@Learath2 btw. null antibot is deployed

16:47

shall I try noby's?

sure, give it a go

16:48

@fokkonaut would you be so kind to atleast give me a testcase or am I going to have to grasp around in the dark again?

what do you mean?

16:49

you can try it on my server, if your client is up to date with master

16:49

type /po and you should see it

@Learath2 @noby it's live

2

Hooray

17:37

@fokkonaut you should have said it had a bug in the issue... now oy merged it, now I need to fix it tonight

17:40

@fokkonaut /policeinfo has ?i and it displays [number] for me

is that correct?

yes

and all other commands dont display anything

i means you need a number, [] means it's optional

17:41

which command needs to display something but isn't displaying something?

every command

17:41

almost

the ones with descriptions are broken, not the ones without description

yes

17:42

but why

found it, fixed it

@heinrich5991 do you like the serverinfo extension I pull requested as a solution? Do you think maybe we should do something more future-proof?

I'm fine with the protocol

18:25

I think you should support receiving packets out of order

18:25

quick look at the code gives me a new Truncate which isn't really needed, you can track the size instead (in the end, don't use Packer.Size() but the size you tracked

18:26

@Learath2 answer is in the first line, is that a reasonable answer to your question?

I think so, I'm just a little unsure because it kinda feels like I could possibly wasting our one chance to rework the protocol on something pretty un-extensible

the thing is, we can extend it furtherly be putting more request header into the packet

18:28

so I'm not too worried about that