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 2021-11-16 00:00:00Z and 2021-11-17 00:00:00Z

how do i pull request?

[ddnet/ddnet] Pull request closed: #4320 WIP: Allow any aspect ratio

[ddnet:master] 2 new commits

b5d09dd Use W, A, S, D to navigate in editor - ChillerDragon 8c49d20 Merge #4315 - bors[bot]

08:07

[ddnet/ddnet] Pull request closed: #4315 Use W, A, S, D to navigate in editor

[ddnet:master] 2 new commits

ae8ccdf Don't send entityex to old clients or for stationary pickups - trml 7e9f1cc Merge #4306 - bors[bot]

08:18

[ddnet/ddnet] Pull request closed: #4306 Small optimization of EntityEx snapping

https://www.thecodedmessage.com/posts/cpp-move/

C++ Move Semantics Considered Harmful (Rust is better)

This post is part of my series comparing C++ to Rust, which I introduced with a discussion of C++ and Rust syntax. In this post, I discuss move semantics. This post is framed around the way moves are implemented in C++, and the fundamental problem with that implementation, With that context, I shall then explain how Rust implements the same feat...

08:33

call the article "Move Semantics: C++ vs Rust" instead

well its his opinion

I don't think an article with that title is going to produce a useful discussion, that's why I suggested a different one

i disagree

09:08

there are lot of articles with titles like this "considered harmful" and i see plenty of discussion on hn

09:08

unrelated to rust

I stole the title I liked better from the very author who also posted it on the rust subreddit

09:09

https://old.reddit.com/r/rust/comments/qlycje/move_semantics_c_vs_rust/

r/rust - Move Semantics: C++ vs Rust

375 votes and 111 comments so far on Reddit

well idk then

09:10

the post looks interesting tho

09:14

https://swc.rs/

Rust-based platform for the Web – SWC

SWC is an extensible Rust-based platform for the next generation of fast developer tools. It's used by tools like Next.js, Parcel, and Deno, as well as companies like Vercel, ByteDance, Tencent, Shopify, and more.

09:14

xd

09:14

SWC is 20x faster than Babel on a single thread and 70x faster on four cores.

09:14

poggers

09:15

https://openjdk.java.net/jeps/8277131

09:16

java is modernizing a little bit monkalaugh

monkalaugh

09:16

JEP draft: Virtual Threads (Preview)

09:17

https://news.ycombinator.com/item?id=29236375

dzonga

Java Virtual Threads Preview

heinrich5991

I don't think an article with that title is going to produce a useful discussion, that's why I suggested a different one

I completely agree. Makes it sound like a hit piece. And I hate the original "goto consudered harmful" article too. So it's doubly annoying for me

heinrich5991

what about shifting into the sign bit?

while I accidentally summoned you with the clickbait title, do you know about this?

I wouldn't read the article if I just saw the title

heinrich5991

while I accidentally summoned you with the clickbait title, do you know about this?

Shifting into the sign bit is indeed undefined in C, I can't find the same thing in C++14 though

ah, thanks

Oh actually found it

09:33

C++14 5.8p2, it's not UB in C++14

nice, the code I merged wasn't UB

undefined and c name a better duo

I couldn't think of a way to do it without UB, especially since I thought that uint → int conversion was UB

greenthing

when out of range of the target type

Otherwise, if E1 has a signed type and non-negative value, and E1 ×2E2 is representable in the corresponding unsigned type of the result type, then that value, converted to the result type, is the resulting value; otherwise, the behavior is undefined.

09:34

E1 * 2^{E2} that is

nice

The cast back and forth to the signed type I'm unsure about though

09:35

Atleast the operation itself isn't UB that's for sure

Robyte said that it merely has an implementation defined result

09:36

which is good enough for me, I assume two's complement and no compiler magic

Let me give it a quick look over just in case

https://github.com/ddnet/ddnet/pull/4340

Add functions for packing/unpacking int/unsigned using char arrays ...

Add uint_to_bytes_be and bytes_be_to_uint functions from upstream and use them where applicable to reduce duplicate code. Checklist Tested the change ingame Provided screenshots if it is a visua...

Yep it's fine C++14 4.7p2:

If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [ Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). — end note

+ 4.7p3

f the destination type is signed, the value is unchanged if it can be represented in the destination type; otherwise, the value is implementation-defined

09:41

Since two's complement is guaranteed that only leaves compiler goofs, and neither clang nor gcc is insane enough to break that

09:41

Though one could use memcpy there too, I doubt it'd end up in different assembly and that one is guaranteed to recreate the bit pattern

[ddnet/ddnet] Issue opened: #4356 Jumping right after spawning sometimes triggers the double jump animation

On the map HearTbeaT, I ran into death tiles while trying to jump. This often caused me to jump right after death. The double jump animation was sometimes shown, but it shouldn't, since the spawn is right on the ground (and I still had my double jump).

fwiw I've been missing so many sounds lately :/

sounds?

mostly dj and hammer sounds on GER1

09:47

GER1 kinda became unplayable for me

hm i hear them

I think it's only me, if it happened to everyone we'd have a riot at hand

macos?

09:49

monkalaugh

nope, windows and linux both

09:50

feels like huge packet loss

is ur internet ok

yep, it's completely fine in FRA and I get like 28 ping on GER1 aswell

maybe ur pc is diying

why would it only suffer on GER1 tho?

dying*

I would bet on ddnet being buggy instead of his computer dying

i just repeated the word dying a lot and it sounds weird now

I really think we need to take a look at the snap stuff :/ I'm not sure if it's operating as intended

what was changed?

Especially now that we are at the very edges of it's capabilities

09:52

We have way too many objects now, it's testing the limits

https://github.com/ddnet/ddnet/pull/4306/files

Small optimization of EntityEx snapping by trml · Pull Request #430...

This drops sending entityex to old client versions, and for stationary pickups not in switch layer (since they don't benefit from entity ex for prediction). It also slightly changes how m_S...

lots of edgecases never before exposed

ah

i found something hilarious on stackoverflow

Image attachment

I'd so delete my account after that shame

@Discord Mod

1

thanks

how to debug ddnet client freezes? I tried running with gdb and doing sigkill but that deletes the stack as well

18:29

image.png

Image attachment

ctrl-c in gdb when it hangs

18:29

then bt

ctrl+c wont respond since its frozen

ctrl-c in gdb is handled by gdb, not ddnet client

well outside of gdb ctrl+c does nothing

18:29

ah oke

18:30

nice ima try that if i catch da bitch again

18:30

thanks

18:32

could probably also be found by looking at all loops the client does based on server data

you also need to interrupt a couple times and bt to get a couple samples

yea gl to me with that

19:02

id say it happens on average every 6 hours

19:03

But since its a full freeze chances are high one sample is enough because i feel if it gets in the loop once it never gets out

Hi, there is a clientcrash with projectiles. If ddnet client receives a normal projectiles, not ddnet projectile, and the VelY has a specific amount, so that flag 512 (IS_DDNET) is set, it will try to extract the projectile as if it was a with extrainfo packed ddnet projectile and theirfore it will falsly unpack it and set a wrong m_Owner, which should have been -1 but will be 94 or 98 in my cases. This leads to a crash in IsOtherTeam(), trying to access m_aClients with such a high clientid.

19:12

I need some help here, I dont like this compatibility managing so I just use normal proejctiles for ddnet client too, since there is not much needed from the new one. How can I fix this now? and why does the client need to try to unpack it that way if it gets told its NOT a ddnet projectile... To support old servers?

19:13

I think the whole projectile managing is a mess, I would appreciate some help here

the reason this compatibility mapping exists is old servers, yes

And who thought it was a good idea to make this dependent on the VelY?

are old servers even supported?

the inventor of this extrainfo

that is

probably someone like greyfox or so

i wasnt abled to zoom with latest ddnet client on my 9.0.2 based mod

meh, can we get rid of it

chillerdragon

i wasnt abled to zoom with latest ddnet client on my 9.0.2 based mod

yeah, old servers are not really supported

My question is why do you have projectiles going at such an insane speed?

i think the only old ddnet server in use is kog

19:16

and thats maintained so qshar can handle it

Learath2

My question is why do you have projectiles going at such an insane speed?

I have a trail that is made ouf of stable projectiles, which have a manually calculated vel to stay in position without flickering

19:16

and if you fall down at a very sane speed, they will follow behind you, and that probably makes the calculated vel too high

19:16

too high for this flag, at least

19:17

falling for 2 seconds or so is enough to trigger this

Okay, I have an answer for you, the person who made the extrainfo didn't think anyone would need such high speed projectiles

they are not high speed D:

512 is pretty darn fast, are you sure you aren't dividing by zero somewhere?

definitely

19:19

its not 512, it out-calculates the real projectile tuning, so that it will stay in place

19:19

it "moves" at normal speed

19:19

it re-calculates vel and position to be sent every 4 ticks

Okay, I don't get it, the calculation doesn't turn out larger than 512 but it is?

well, it does, but thats not the actual speed of the projectile

19:20

the projectile itself doesnt have a speed, its static

19:21

but

19:21

in order to trick the client to show it as stable, and not falling, it will calculate the velocity

19:21

not stable, not flickering, just clean and stable in the air

okay, have you tried sending extrainfo projectiles to ddnet and old projectiles to old clients?

that seems to be the only solution, sadly xd

https://github.com/ddnet/ddnet/commit/03bc769c09c6dc0f100510c21cd16fef3b6f7553#diff-d76009083687ba43c59dc7bb2c7357457c999c2eb9d913967d598e913c6fd01fR729-R769

prediction of hammer (hits) and grenade (explosions) · ddnet/ddnet@...

19:23

introduced in 2014 by trml

19:23

(since you asked)

:P

back then we didn't have extra projectiles

ddnet*

who had custom snapshot objects?

no, i mean you didnt have ddnet projectiles

ah

"CLIENTID_BIT{}".format(i) for i in range(8)]

19:25

what is htis?

the client ID is encoded in the lower 8 bits

ah

19:29

@Learath2 how can I use ddnet projectile tho, if I can not manually set the velocity

19:30

there is actually no solution

19:30

well

19:30

I somehow need to get that into the angle

19:30

lul

19:30

ah, thats probbaly done

Yeah, it doesnt work ._.

19:47

Just looks buggy af

19:50

oh, i might have it

19:52

okay no, it doesnt seem to work with ddnet projectiles

Why not?

ddnet projectiles might have dropped the velocity?

yeah, they only have the angle...

and how does the prediction derive the velocity?

tuning

ah, makes sense

this is bullshit ._.

it's bullshit that we didn't think of how you might use velocity in 7 years when we improved our prediction?

exactly!

if only we weren't so short sighted

no, its bullshit that there doesnt seem to be a solution

.. ... / - .... .. ... / - .... . / .-. . .- .-.. / .-.. .. ..-. . ..--.. / .. ... / - .... .. ... / .--- ..- ... - / ..-. .- -. - .- ... -.-- ..--.. / -.-. .- ..- --. .... - / .. -. / .- / .-.. .- -. -.. ... .. -.. . --..-- / -. --- / . ... -.-. .- .--. . / ..-. .-. --- -- / .-. . .- .-.. .. - -.-- / --- .--. . -. / -.-- --- ..- .-. / . -.-- . ... --..-- / .-.. --- --- -.- / ..- .--. / - --- / - .... . / ... -.- .. . ... / .- -. -.. / ... . . --..-- / .. .----. -- / .--- ..- ... - / .- / .--. --- --- .-. / -... --- -.-- --..-- / .. / -. . . -.. / -. --- / ... -.-- -- .--. .- - .... -.-- --..-- / -... . -.-. .- ..- ... . / .. .----. -- / . .- ... -.-- / -.-. --- -- . --..-- / . .- ... -.-- / --. --- --..-- / .-.. .. - - .-.. . / .... .. --. .... --..-- / .-.. .. - - .-.. . / .-.. --- .-- --..-- / .- -. -.-- / .-- .- -.-- / - .... . / .-- .. -. -.. / -... .-.. --- .-- ... / -.. --- . ... -. .----. - / .-. . .- .-.. .-.. -.-- / -- .- - - . .-. / - --- / -- . --..-- / - --- / -- .

IS THIS THE REAL LIFE? IS THIS JUST FANTASY? CAUGHT IN A LANDSIDE, NO ESCAPE FROM REALITY OPEN YOUR EYES, LOOK UP TO THE SKIES AND SEE, I'M JUST A POOR BOY, I NEED NO SYMPATHY, BECAUSE I'M EASY COME, EASY GO, LITTLE HIGH, LITTLE LOW, ANY WAY THE WIND BLOWS DOESN'T REALLY MATTER TO ME, TO ME

1

19:55

translated

@fokkonaut don't we have some flag somewhere to tell the client we don't do extrainfo projectiles?

if yes i didnt see it

19:56

but i think no

I don't htink we have one

okay, i have come up with a very ugly hack right now

20:11

wait a second, why doesnt this crash trigger on another extra, the astom??

astom?

atom*

20:15

funny

20:15

it does

I don't understand the sentence

there is trail and atom, those extras use the stable projectile

20:16

now, in debug mode i got a crash with atom, but in normal release mode i dont

ah, these are things in your mod?

yes

20:16

this just gets weirder and weirder ._.

20:17

its sad that we can not use ddnet projectile nor normal projectile for modding ._.

20:19

can we remove extrainfo unpacking for non-ddnet-projectiles?

20:19

i doubt there is any server even using this

I would guess KoG is using it

20:20

if someone wants to remove it, I'd expect them to check all online servers for it

heinrich5991

I would guess KoG is using it

no, they have updated and created their kog2.0

heinrich5991

if someone wants to remove it, I'd expect them to check all online servers for it

just did

20:21

there are no servers with versions even close to that

20:21

oldest is 11.3 or so, but thats only 1 server

what did you do? you joined these servers and checked that they don't send this projectile?

i checked browser

and what version did you compare it to?

20:22

which version number?

i see, the wrong one probably

also, I'd expect you to actually check KoG

20:23

I don't think they rolled out new servers already

they did xd

I wasn't seeing ghosts the other day

20:23

for /spec'ed tees

20:24

did they intentionally remove that feature?

i dont know

20:24

last time i checked it out they had it

20:24

i talked to avo at some point even

20:24

idk tbh

please test the feature

20:25

I have the feeling your information is wrong

well, i have another idea without removing it completely

adding another projectile type might be an option

lmao

I don't know if I'd like overloading the existing one even more

20:29

idk, what do you think about this? @Learath2

I didn't like the original extrainfo patch either

20:36

@trml why did we decide on using angle and pos? to get more precision?

which "original extrainfo patch"?

Ah, it was to make space for flags, right?

I think it was just angle and pos because it tried to fit into the original projectile

20:36

yes

20:37

the "original extrainfo patch" was from 2014, I don't think we were reviewing PRs back then

One issue about a new projectile object is the uuid stuff is really becoming a bit of a bottleneck

not an unoptimizable one, but yes, one that should be fixed

Maybe we should get the server and client to discuss the mapping from internal type id to uuid through netmsgs, but that causes snaps to become reliant on netmsgs

20:39

Also makes demos weird :/

because there are too many items/too much data in the snap?

That and if the mapping is set for the entire session it's very trivial to cache

20:40

Otherwise the client needs to rebuild a map each time it receives a snap from the NETOBJTYPE_EXs

@heinrich5991 the ddnet projectiles sends positions multiplied by 100, unlike vanilla, cant we just check whether X or Y is > map width/height, and then say its an extra projectile? Then we could ignore the is_ddnet flag, only downside is that projectiles shot around 1 block around 0,0 would not be shown then

it could optimistically assume that it's the same and only check for differences

@heinrich5991 it'd still need to iterate through the entire snap to extract the objects with the mappings tho, no?

that sounds like as hackish as the other hack you are complaining about @fokkonaut

20:41

@Learath2 we iterate the whole snap when diffing the snapshots already

well, that would at least not create problems for kog, and would solve my issue :P

but it'd cause problems for fokkonaut2 7 years down the road

xD

"which idiot came up with this hack that I can't send projectiles in (0,0)

20:42

"

well, you can, if the velY will not trigger is ddnet flag then :P

heinrich5991

@Learath2 we iterate the whole snap when diffing the snapshots already

true, I've sort of been relying on what other people here told me, I should probably profile this myself :/

I did not profile

20:43

I'm only looking at the problem from the code

fokkonaut

well, you can, if the velY will not trigger is ddnet flag then :P

512 is a completely sane cap for the speed imo, no one could foresee you wanting to do some prediction hack years down the line

its actually timakros hack, not mine

20:44

@heinrich5991 other idea, if raw X or Y is further away from u than it would be "possible" due to netwrok clipping, then we know its an extra projectile

heinrich5991

I'm only looking at the problem from the code

Also, I don't remember what we ended up doing with the capability stuff but how would we actually decide on what kind of projectile to send which client?

20:44

I don't think clients can send capabilities, right?

we didn't do client capabilities, only version

@heinrich5991 that would also let you send projectiles in 0,0 again

So we do a 15.6.3 with a new projectile object and do a version check as with the others?

i remember trying to add capabilities when adding a feature to show weapons while frozen

no, we only add the projectile for fokkonaut and don't use it ourselves

xDDDDDDD

https://github.com/ddnet/ddnet/issues/2252

Current weapon crosshair in freeze · Issue #2252 · ddnet/ddnet

This is a simple idea that I think would be useful. When you are frozen (or deep-frozen) your crosshair should represent the weapon you are currently holding, instead of showing the ninja crosshair...

20:45

https://github.com/ddnet/ddnet/pull/2307

add client capabilites and show weapon on freeze by edg-l · Pull Re...

cl_show_ninja 1 cl_ninja_particles 1 cl_show_ninja 0 cl_ninja_particles 1 cl_show_ninja 0 cl_ninja_particles 0 cl_show_ninja 1 cl_ninja_particles 0 With the feature disabled (cl_show_weapon_fre...

20:45

:)

heinrich5991

no, we only add the projectile for fokkonaut and don't use it ourselves

Uh, why not? Might aswell migrate ourselves to a clean non hacky object, the extrainfo stuff was back when we couldn't have extended netobjs

we have a non-hacky version of that already ^^

20:46

we already use a extended netobj for it (I did it to make the code a little cleaner)

20:46

fokkonaut is just annoyed by the backward compatibility that still recognizes the old hack

20:47

https://github.com/ddnet/ddnet/blob/fb23d4637b07e4c3c8f67a091564fb858c6f44eb/datasrc/network.py#L257-L266

20:47

ok, "non-hacky" might be too much, let's say "less hacky"

heinrich5991

fokkonaut is just annoyed by the backward compatibility that still recognizes the old hack

i am annoyed that we can not use vanilla objects like vanilla objects, yes

20:48

i will try out my x y idea

20:48

if that works, i'll pr

@heinrich5991 Um, why does it assume the same in-memory representation as projectile?

don't add more hacks there

heinrich5991

don't add more hacks there

should have been there from the beginning

because it uses the struct to read out CNetObj_Projectile as well, I think @Learath2

20:50

(the backward compatibility)

fokkonaut

i will try out my x y idea

Don't think we'll accept a patch that requires an absolute mess of compatibility code to serve 3-4 different projectile objects just so you can have this one weird functionality

its not weird

20:51

its a shame that you say that, its weird that we can not just have a stable projectile at all

@Learath2 https://github.com/ddnet/ddnet/blob/fb23d4637b07e4c3c8f67a091564fb858c6f44eb/src/game/client/projectile_data.cpp#L20-L22

@heinrich5991 I was thinking a new extended projectile that just gets rid of the angle and uses velocity again, and adds a new int for flags we need to add in

+1

@Learath2 yes, that works

20:52

(it's also what I proposed, just fokkonaut wanted to pile on more hacks)

no, i wanted to avoid more objects and more compatibility code

20:53

and i wanted to avoid an object that would only serve me

heinrich5991

adding another projectile type might be an option

^

The problem I'm not exactly comfortable with is serving the correct projectile object to the correct clients

heinrich5991

@Learath2 yes, that works

But I also want us to not send the angle stuff to newer clients so we can hopefully in a decade or so drop the ancient representation, maybe with the move to 0.7

20:54

We keep so much legacy baggage it's making me cry every night before sleep

you mean move from angle to velx, vely?

yes

would it make you less cry if I tried moving it to a central place?

we can just drop the old ddnetprojectile and send normal proejctiles again to older clients

Could you even? I tried this when doing the 0.7 stuff, it's surprisingly hard to rip these things out of their contexts

fokkonaut

we can just drop the old ddnetprojectile and send normal proejctiles again to older clients

can't, breaks prediction, need the flags on the client

I did it for 0.5/0.6, but I guess I haven't tried for 0.7

oh no, antiping on old clients, they can just update no

Learath2

We keep so much legacy baggage it's making me cry every night before sleep

^

20:56

at least they can play with their old client and see the projectiles

and you'll sell the idea to old players that refuse to update I presume?

dont let them join

20:57

for real, every other game literally just makes it impossible to play without updates

why didn't I think of that, essentially banning pro players

why do we have to care about it sooo much

just like Learath2 doesn't like dropping performance unnecessarily, I don't like dropping compatibility unnecessarily

20:58

with clients that are still in use by real people

then what about having statistics

20:58

then we know

20:58

you have teehistorian

20:58

and antibot

@heinrich5991 if you can actually make sense of the code there and can actually rework it to support the new projectile I'm okay with getting in more compatibility code

lets see how many people actually use clients that we still support that are 10 years old

and if there are actually people using these clients you'd drop your case?

at least more than just assuming there are some

20:59

or, assuming there are a lot, or "pro players"

20:59

xd

I don't think there are "a lot" of players, but I think there are some

21:00

I think the latest ddrace version for android is very old, too

then lets convince aoe to update

21:01

9.3.1

21:01

dont we have android code back in again

idk

https://github.com/ddnet/ddnet/commit/b216b6744ab2ad4aa2efa03f7b4385424f97f6d2

@heinrich5991 can I pay you to make netobjs upgradable?

adding a new more general projectile would be nice

@Learath2 as in larger?

as in either larger or smaller

hmm

21:32

you mean only larger with later versions?

21:32

or do you want support for shrinking them in future versions?

21:32

(only larger and communicating in both directions)

would adding some reserved/unused fields/ints at the end be an option?

Since you intend to keep like every version of the game ever released supported, I can imagine a future where we have something like projectile-v12@ddnet.tw and a dozen branches wherever we send a projectile

21:34

Hm, actually smaller is impossible since old clients would misunderstand it :/

Only if its repacked xd

All I ever wanted was clean code

there was a post on hn today that said "clean code is a big no no"

21:35

21:35

I also like clean code

I guess at some point we have to bite the bullet and do a v2 of the player object

i wonder why the teeworlds api was never pr-ed

I want teams in there instead of teamstate

21:38

teeworlds api?

ye

someone made one?

indeed

21:39

custom netobjects, images etc

21:39

all from the server

21:40

i cant remember where i saw it

@Learath2 thats made with it

22:00

where did you gooo

22:03

Omg i finally found it, collision for bigger entities!!

@fokkonaut ?

Hi

I made some tea and helped a friend with something

https://m.youtube.com/watch?v=4KDsXsgw-vY

Teeworlds 0.7.4

Learath2

I made some tea and helped a friend with something

what kind of tea

What does this have to do with an api? Is there like a protocol for the client to request these new images and stuff?

fokkonaut

what kind of tea

oolong

whats that?

Well it's a chinese tea, not very common in europe. Not very sure how I'd describe the taste

Learath2

What does this have to do with an api? Is there like a protocol for the client to request these new images and stuff?

Its made using the api, prediction, objects, custom net msgs, all can be send by server and loaded by the client

22:13

Images of course too, yes

A more fruity green tea maybe

Custom weapons, skins, removable blocks -> ingame block changing with prediction update

Learath2

A more fruity green tea maybe

That sounds nice

22:14

I like tea with honey

Green tea with honey is my favourite thing to drink when I have a cold

Yes thats very tasty

22:16

@Learath2 are you not impressed yer

22:16

yet

Looks nice, I'm sure I wouldn't like the implementation

It’s just building on android. But no full mobile support with touch controls. (@fokkonaut)

dont we have android code back in again

why

22:32

Why did it not get added back lol xdd

Because nobody made it

That was probably the easiest thing

22:32

we had it before

22:32

problem was building with sdl2 iirc

I guess that's a thing we accept PRs for

I’d prefer Linux touch support over some niche android

Learath2

@trml why did we decide on using angle and pos? to get more precision?

btw, this was to get a sufficient amount of precision (and saving space), yes, without having to clamp the velocity/direction in the server. however, an easier way to get "full precision" could have been to send the unnormalized direction of the projectile (the original mouse input from the player), and a flag to tell that it should be normalized. (or to just clamp the values a little in the server, after scaling a little bit)

22:47

meant quantize, not clamp

mh, why was the extra precision needed?

it's mostly because the precision becomes low when the velocity vector is normalized to 100 length and then rounded to int, like vanilla does/did

22:50

although the effect becomes greater when the projectile travels further

Hm, wait so how are the projectiles handled on the serverside? I thought all entities stored x, y and v_x, v_y. How is having more accuracy in the protocol than that changing anything?

here is a discussion about it in vanilla https://github.com/teeworlds/teeworlds/issues/1458

22:53

and was solved in vanilla by quantizing so that the server uses the same values that are sent (not sure if that precision would be good enough for ddnet, escpecially for things like hooking through edges/corners)

22:53

in the server you can have infinite precision, in theory

22:53

(for the angle)

22:54

since you send an arbirary X and Y integer as mouse input

Ah, on the server we have floats for position and velocity and in the snap we send rounded versions, that's the issue?

yeah

I think we quantize hook stuff

22:55

before applying it to the game

22:55

just not for projectiles, I think

Could we maybe just send floats? Floats are also 4 bytes

floats over the network are a bit meh, but I guess it could work

Well assuming both sides have IEEE754 floats there is no actual issue there, is there?

nan encoding is unspecified and actually different across architectures, probably need to guard against +inf, -inf, etc.

How about we only have IEEE754 floats in the protocol and unpack them into platform floats? On most architectures it'd be a no-op

ieee754 floats have unspecified nan patterns for signaling/non-signaling nan ^^

23:02

afaik

23:02

but I guess we could standardize on intel or something

23:03

I think conventional wisdom about floating point is that you should not send it over the network. I guess I'll try to find the article to see whether it applies to us

This is why we need fixed point arithmetic

yes, floating point compatibility is perhaps to some extent already assumed in other parts of the code too

oh, it looks like hook is quantized yes. always assumed it wasn't. so maybe something like that wouldn't have been too bad for projectiles

Exported 402 message(s)