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 2022-06-29 00:00:00Z and 2022-06-30 00:00:00Z

Tater

is there any reason we are not using a more modern way of handling input packets? the way it works now where it just sends the packets once and never again is pretty bad. We are already very close to the "optimal" input packet solution it seems like a waste that we're not doing it. We just need to resend/bundle inputs from previous ticks (and correctly order them into a buffer on the server) and fix the automatic adjustment of prediction margin so it correctly scales to a constant network instability. https://youtu.be/zrIY0eIyqmI?t=1530

applying old inputs retroactively means trusting the client more, enabling more cheats

you don't need to trust the client at all, you just use the first input for each tick that was sent then if they send another one for that tick which is different you ignore it

the client can retroactively change input by not sending one for a specific tick

what?

00:08

then the server just assumes they held previous inputs for that tick?

00:09

once the server processes the input it can't be changed, the server never goes back in time (edited)

okay, sorry, I haven't watched the video, only assumed what it contains

00:09

what does re-sending inputs help?

if you manually or automatically adjust the size of the server side input buffer then sending previous ticks inputs can fill in gaps in that buffer caused by packet drop/delay, then the client experiences no mispred/lag

00:11

I time stamped the video where it shows the nice animation

00:13

ddnet already has full client side prediction which is like 99% of the work

It takes like ~20 lines of code to implement a very poor version of this system, if you just resend input packets from previous ticks and then fix the weapon switch/shoot loop on the server then the game can handle high packet loss if you manually increase prediction_margin. but right now the metrics that automatically increase prediction_marign don't work if you have a constant (ie 20%) packet loss (edited)

basically send the last n inputs or so?

it should be ping/20ms inputs but yes

00:28

but the correct way to do it is to bundle all those inputs into one packet to save data

00:30

I'm not sure what the cost of each client sending and extra 0-10 input packets per tick would be, maybe it's small enough that we actually dont care?

well, it multiplies the sent traffic by that number

yeah

is there any explanation for how the network.py protocol generation works? why is it in a python script to begin with?

it's a python script generating C++ code

01:35

you can view the output in the build/src/game/generated directory

1

Lmao fokko the Karen (@heinrich5991)

heinrich5991#9827

is that the 'let me talk to the manager?'

06:15

I also like to ping deen :)

@Tater can't a malicious client just not send input so it gets to observe ping/20ms inputs before having to decide what it wants to do? By artificially inflating it's ping it gets to observe even more. I'll take a look at the talk but I have a feeling overwatch only gets to do this because they trust their client

no I think you're misunderstanding, also overwatch doesn't trust client (edited)

07:19

the thing you get to "observe" is the client side prediction of the last server snap which is already how it works

07:22

if you send the server an input packet for a tick that the server has already passed then the server doesn't care it just ignores it

07:22

so it's not possible to abuse anything

Hm, if you don't get the retroactively do inputs, how does it help?

we send inputs for the future

Actually nvm, I'll watch the talk over breakfast. I'm interested anyway

they might get lost

07:32

so you send them multiple times

07:32

they might not get lost every time

heinrich5991

we send inputs for the future

And we predict those?

I think right now the client tells the server: "apply this input in tick x the earliest"

conceptually the way it works now is so close to the overwatch system but it's just poorly made, if ddnet client detects a misprediction it increases prediction margin, contracts time, and starts producing inputs faster, the only difference is that it only accounts for packet delay not packet loss so even if the client is sending the server packets for 50 ticks ahead of the server tick but one of them gets dropped it will still be lost. (edited)

c0d3d3v

I thought it would be interesting to use it, for the upcomming particles that could come with the material layer that @AssassinTee implements https://github.com/ddnet/ddnet/pull/5403 But maybe it is the best to just combine hud.png and extras.png in one, call it extras.png? and also add the material particles to it. And probably also the upcomming powerup particles (edited)

it's hard to follow a conversation that was a day ago. Currently I put the new particles in their own material-particles file. Are you talking about the ice skids or other ice particle? (edited)

08:21

Or are you saying I should add materials to the extras tab? Sounds nice IG

[ddnet/ddnet] Pull request closed: #5530 Update russian.txt

08:43

[ddnet:master] 2 new commits

a26c7a0 Update russian.txt - zigtfm f1cff70 Merge pull request #5530 from zigtfm/master - def-

M

Pci-e 7 will be out on 2025

09:07

https://www.nextplatform.com/2022/06/23/the-path-is-set-for-pci-express-7-0-in-2025/

Timothy Prickett Morgan

The Path Is Set For PCI-Express 7.0 In 2025

The ink is barely dry on the PCI-Express 6.0 specification, which was released after years of development in January 2022, we hardly have PCI-Express 5.0

09:09

Image attachment

09:09

the jump is hilarious

should be logarithmic scale, bandwidth doubles with each gen

AssassinTee

it's hard to follow a conversation that was a day ago. Currently I put the new particles in their own material-particles file. Are you talking about the ice skids or other ice particle? (edited)

It was not a very long conversation xD just my answer... I still do not know, what we should do. With the new HUD, we added now hud.png and extras.png. I'm thinking about just putting them together in one extras.png, that contains everything new our mod adds. But I guess some of the materials and material particles, have to be made by ravie or someone of the teeworlds artist, so that it is in the teeworlds look anyway... so do not care about this now to much.

As far as we can tell, they did it, but we won’t know for sure until the first PCI-Express 6.0 devices hit the streets in maybe early 2023 to late 2024. It usually takes 12 months to 18 months for new devices supporting the spec to get into the field, but a lot depends on when the CPUs get each generation, since that drives the peripherals. The desire to move to CXL main memory is pretty strong, and that requires lots of bandwidth and low latency, so we think engineers will be working on the PCI-Express specifications for 7.0, 8.0, and 9.0 with the mind of energy we have not seen in the past, and there will be a lot more of them, too, which increases the odds of breakthroughs.

09:11

Image attachment

09:14

But assuming electrical signaling can keep moving ahead – it is a better than even assumption that it can – then PCI-Express 10.0 should be in products in 2035 or 2036 and should be driving 1 Tb/sec signaling lanes and 4 TB/sec across an x16 duplex slot in a server. If we even have a thing called a “server” then, that is. By then, a server might be an abstraction of interconnected components, with an interconnect hypervisor standing in for a printer circuit motherboard and slots.

09:14

damn

c0d3d3v

It was not a very long conversation xD just my answer... I still do not know, what we should do. With the new HUD, we added now hud.png and extras.png. I'm thinking about just putting them together in one extras.png, that contains everything new our mod adds. But I guess some of the materials and material particles, have to be made by ravie or someone of the teeworlds artist, so that it is in the teeworlds look anyway... so do not care about this now to much.

I actually asked @louis already for this and he doing great work! But I know he is busy and hasn't yet started with all particles. The only particles I currently have are the ice skids from zatline

Image attachment

1

09:18

Image attachment

09:20

I guess I am next to deliver! I have a branch with all planned materials working. Since this was a lot of trial and error I need to update my PRs in the future

1

@deen @heinrich5991 So I think we agreed that the freezebar is final for 16.2. Unaffected by all criticism. But should I add client side notification, if some effect player effect (endless jump, no hit....) changed, or just reenable server messages? Server messages could just reenabled in nightly so we would not need to push to 16.2 (or it could also be pushed to 16.2 since it is a small change, and then 16.2 server would also send them). And then we could work on the new animation, notification whatever for future version. (edited)

Sounds ok to me. I guess if something like solo changes the icon in HUD should light up strongly for a moment so you notice it like the server message

I like that it makes a sound though

Is the ok for re-enabling server messages? @deen (edited)

09:29

Then I make a PR for that

Yes

1

[ddnet/ddnet] Issue closed: #5509 weird patch on screen

[ddnet/ddnet] Pull request opened: #5532 Update hungarian.txt

16.2-rc4 translations (missing: Aim bind, Show freeze bars, Opacity of freeze bars inside freeze )

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

Rust is awesome

10:18

@Ryozuki I understand why ur so much in it, started & already love ti

TOOBASED

10:26

Nice

[ddnet:master] 2 new commits

fb22a1c Update hungarian.txt - bencie 7a0a0e0 Merge #5532 - bors[bot]

10:28

[ddnet/ddnet] Pull request closed: #5532 Update hungarian.txt

[ddnet:master] 10 new commits

df52df9 move DDNetCharacterDisplayInfo to DDNetCharacter - C0D3D3V 07cfda5 remove rampvalue from ddnetcharacter - C0D3D3V 4729fa9 Match PACKER_BUFFER_SIZE when using SecureUnpackMsg - C0D3D3V 00f28f2 Unpack all 64 Parts of a splitted Snapshot - C0D3D3V f819afe Print also extended NetObj and NetMsg Names - C0D3D3V 59436b5 Add default values to extended Net Objects - C0D3D3V 917e9f1 remove unused python code - C0D3D3V eea0615 refactor compile.py - C0D3D3V 2090178 Set default of cl_freezebars_alpha_inside_freeze to 0 - C0D3D3V 1743b7c Merge #5210 - bors[bot]

11:49

[ddnet/ddnet] Issue closed: #5455 Maybe a bug in the snapshot system

11:49

[ddnet/ddnet] Pull request closed: #5210 Move ddnet character display info in ddnet character

11:49

[ddnet/ddnet] Issue closed: #5455 Maybe a bug in the snapshot system

@deen I hope the merge to 16.2-devel worked without concerning conflicts

there was one conflict and I left out the 2 python changes about refactoring

12:32

@c0d3d3v i guess i should wait for your other change before next rc

12:32

feels like the most rcs we ever had

deen

@c0d3d3v i guess i should wait for your other change before next rc

ah you mean the one with the server messages. Sorry I'm just really got going, was a bit tired this morning. I can do this quickly. Is actually just remove all the version checks again. give me 5 min. if you want to wait for that

no problem, just saying

[ddnet-web:pr-16.2] 1 new commit

c89c9a9 Version 16.2 - def-

12:43

[ddnet-web:master] 1 new commit

f12f190 Translation status update - def-

[ddnet/ddnet] Pull request opened: #5533 revert to send server messages for now

!grafik send our old server messages till we come up with a better way to tell the player some effects on him have changed. See https://github.com/ddnet/ddnet/issues/5510

Checklist

[x] Tested the change ingame
[x] Provided screenshots if it is a visual change
[ ] Tested in combination with possibly related configuration options
[ ] Written a unit test if it works s...

@deen ^

pff, somehow some blank lines survived xD I thought I removed all... (edited)

[ddnet/ddnet] Pull request closed: #5533 revert to send server messages for now

13:21

[ddnet:master] 2 new commits

435b7ab revert to send server messages for now - C0D3D3V cbab1fb Merge #5533 - bors[bot]

oh god, deen ping incoming

13:26

i see you @fokkonaut

No, I wanted to ask for MrCosmos discord, then I remembered it is listed on the status.tw page where the master servers are listed, but his Discord doesnt seem to work anymore (MrCosmo#1337)

@MrCosmo ^

1

The fuck

Maybe he just blocked you and that's why you can't @ him

I literally pressed send friend request and searched servers where I can ping him

13:32

He didnt block me iirc, we had normal talks back then

13:32

Nope, I can message him

13:32

just discord being weird again

maybe parenthesis (@fokkonaut)

13:33

hum

13:34

discord didn't proposed a list of name. I think you need a space between ( and @

yea i have tried everything xd

13:36

Discord is just buggy sometimes and doesnt show all users

13:36

also in dms

mobile app as well, asks me for "please do these steps before you can talk" again and again here

Tater

is there any reason we are not using a more modern way of handling input packets? the way it works now where it just sends the packets once and never again is pretty bad. We are already very close to the "optimal" input packet solution it seems like a waste that we're not doing it. We just need to resend/bundle inputs from previous ticks (and correctly order them into a buffer on the server) and fix the automatic adjustment of prediction margin so it correctly scales to a constant network instability. https://youtu.be/zrIY0eIyqmI?t=1530

Very interesting. Thx for this.

haha

we use javascript not rust so go away

1

justatest

Ryozuki

justatest

u need to read irc to understand xd

no more irc bridge ?

Chairn

no more irc bridge ?

its was some scam about free rust xd

oh the game?

16:16

i hesistate to open a painful discussion on github about supported targets

yeah he meant the game

16:18

but this is dev channel, so he meant language

reworked snow particle, opinions?

Image attachment

Ravie

reworked snow particle, opinions?

Cool, but I think it's better for the snow stars to be away from the center, left and right of the body

particles arent the problem, but ninja skin doesnt fit

skin is another topic, but I tried to make the snowflake look better at small scale

@deen someone requested to show also older years for player time, similar to github, 2022, 2021 etc

16:36

dunno if that plugin supports it

you can leave the original skin, but as if in ice, or add ice to the current one from above?

yeah

16:36

could be cool xd

[ddnet/ddnet] Issue opened: #5534 No freeze bar on rc7 and latest master

With opengl 3.3 on ubuntu18. Also reported by Pastoer on discord.

Ravie

reworked snow particle, opinions?

just played and saw it, nice stars!

Image attachment

cauldron

just played and saw it, nice stars!

the ones you have are the old ones, the reworked one is on the right in my image

i don't care, both nice

17:13

but this could be reworked as well

Image attachment

Jupstar ✪

@deen someone requested to show also older years for player time, similar to github, 2022, 2021 etc

Can add this at some point. Right now we only started recording data in June of 2021

Ravie

reworked snow particle, opinions?

I prefer the new ones

17:38

@c0d3d3v In general I really appreciate the HUD changes, freeze bar and snow flakes. Starts to feel more like a proper game when we're not just abusing every old graphical element but implement our own

2

1

[ddnet/ddnet] Issue closed: #5534 No freeze bar on rc7 and latest master

hmm, jump state hud is a little weird/confusing for tutorial (at start) because you only have mainjump and no dj (edited)

17:54

so i think we should differentiate both in hud

my skin still isn't fixed

Iza

my skin still isn't fixed

what is wrong with it? I could reupload if there's a problem with the image

no my skin which is in the database isn't showing up ingame

18:06

some update broke it

there has to be something wrong with the image if all other skins work

no the update just broke it

18:07

the devs know but idk how far they are with fixing it

Iza

my skin still isn't fixed

well switch to stable for now, heinrich has to fix it

@Discord Mod ^

damnm 7 rc

18:26

we are like linux now

18:26

well i think linux has 3

what if they need more?

mh, I guess this happened because we added features to the rc, rc is supposed to be a feature freeze

Honestly I'm confused as to why the snow particle wasn't put in the effects.png. Sure there will be more effects soon, but it honestly feels a bit unoptimal right now.

[ddnet/ddnet] Issue closed: #2319 sv_vanilla_antispoof 1 prevents vanilla clients from joining

Yeah, basically I made the 16.2 cut too early, didn't realize we needed so many other HUD changes

18:58

or HUD shouldn't have landed in half-finished state at all. master should always be in a state that allows cutting an RC from

[ddnet/ddnet] Pull request opened: #5535 Updated french language

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

deen

or HUD shouldn't have landed in half-finished state at all. master should always be in a state that allows cutting an RC from

I'm sorry about this.

Tater

is there any reason we are not using a more modern way of handling input packets? the way it works now where it just sends the packets once and never again is pretty bad. We are already very close to the "optimal" input packet solution it seems like a waste that we're not doing it. We just need to resend/bundle inputs from previous ticks (and correctly order them into a buffer on the server) and fix the automatic adjustment of prediction margin so it correctly scales to a constant network instability. https://youtu.be/zrIY0eIyqmI?t=1530

this would be super nice. also if you could compress the inputs a bit (maybe delta + tick difference) so you could send inputs for a whole second or two back to handle larger bursts if playing in solo/dummy. was thinking about this a long time ago, but never got around to it

Ravie

reworked snow particle, opinions?

@deen is it ok if we add the new texture "extras.png" from ravie to the 16.2 release

He really wants it. (edited)

21:34

for the simplified snow flake

21:35

I will just make the PR... you can decide then

[ddnet/ddnet] Pull request opened: #5536 Fix more unsafe define

Fix some unsafe define that can expand in an undesired way if used with some bitwise operator (very unlikely though)

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

[ddnet/ddnet] Pull request opened: #5537 simplify the snowflake

somebody complained that the snowflake is not very teeish so Ravie thought about a redesign !grafik !grafik

Checklist

[x] Tested the change ingame
[x] Provided screenshots if it is a visual change
[ ] Tested in combination with possibly related configuration optio...

trml

this would be super nice. also if you could compress the inputs a bit (maybe delta + tick difference) so you could send inputs for a whole second or two back to handle larger bursts if playing in solo/dummy. was thinking about this a long time ago, but never got around to it

do you know if the protocol supports sending non-fixed sized packets? I only saw the ability to send strings which I guess would work but doesn't seem ideal.

22:16

sending a whole second of inputs would be quite a lot, but I guess if you're playing in solo it doesn't matter if you have a 1000ms prediction margin

I think some netmessages have variable sizes ("[]" in network.py). another possibility would perhaps be a fixed size and not use everything

22:20

and yes, for the last part I was thinking about some kind of compression. for example at the very least not send inputs every single tick if the input only changed some of them

yeah it would compress very well with run-length encoding

was also thinking about bit-packing the data (in theory a single input could be packed into 16 bits or less if you send an angle instead of a target and sacrifice accuracy a little :P), but that ended up being a bit complicated

you could still bit pack the rest of the input I guess

22:27

I think the server need mouse position for anti-bot (edited)

yes, I guess it does

Exported 169 message(s)