01:40 <+bridge> [ddnet] <tela> you happen to get a chance to check this one out yet?
02:03 <+bridge> [ddnet] <uwu> Fake news are mostly directed at discrediting someone
02:07 <+bridge> [ddnet] <uwu> Onion is more a satire as heinrich said, they let you know they're just making fun of Elon's latest moves
04:48 <+bridge> [ddnet] <Alexander> Ah alright, my bad
08:03 <+ChillerDragon> Does upper mean left or right? Is this me being stupid or could this be more obvious with some ttt ttt iii iiii graphic? https://github.com/heinrich5991/libtw2/blob/48a2573af66105fc38f032fe22cfcc60f95f7485/doc/snapshot.md#item-key
08:03 <+ChillerDragon> wow i failed to press a letter 4 times 3 times xd
08:04 <+ChillerDragon> sometimes i wish irc had edit message
08:20 <+ChillerDragon> @Learath2 is the snap item data size in bytes or in 4 bytes (32 bit integers)
08:21 <+ChillerDragon> i assume the latter since you said its ALL ints. Also 1 byte per field might be not enough since the fields are all ints
08:23 <+bridge> [ddnet] <Ryozuki> https://www.reddit.com/r/rust/comments/yvw47o/psa_stdsyncmpsc_is_now_implemented_in_terms_of/
08:23 <+ChillerDragon> if i use 1 byte as size unit my data looks much better tho :c
08:30 <+ChillerDragon> ouuu boi that looks promising https://zillyhuhn.com/cs/.1668670193.png
08:30 <+ChillerDragon> but thats using size as bytes so its not all 32 bit ints? :D
08:32 <+ChillerDragon> @swarfey yo here?
08:42 <+bridge> [ddnet] <Jupstar ✪> When will you implement default member initialization per Attribute
08:42 <+bridge> [ddnet] <Jupstar ✪> Really annoying that such simple thing doesn't exists without the default trait
08:45 <+bridge> [ddnet] <Ryozuki> the default trait
08:45 <+bridge> [ddnet] <Jupstar ✪> Yeah yeah completely stupid
08:45 <+bridge> [ddnet] <Jupstar ✪> When i read the RFC. Everyone wants this
08:45 <+bridge> [ddnet] <Ryozuki> @Not Keks btw in rust its not idiomatic to represent a default value for an integer with e.g 0, you would use Option
08:46 <+bridge> [ddnet] <Ryozuki> and option implements default
08:46 <+bridge> [ddnet] <Ryozuki> @Not Keks where is the rfc
08:46 <+bridge> [ddnet] <Jupstar ✪> I know
08:47 <+bridge> [ddnet] <Jupstar ✪> I had to do that and unwrap all shit manually
08:47 <+bridge> [ddnet] <Jupstar ✪> Bcs typing .. Default::default on frontend sucks hard
08:47 <+bridge> [ddnet] <Jupstar ✪> 1594
08:48 <+bridge> [ddnet] <Jupstar ✪> It also links to some rust forum and other issues
08:48 <+bridge> [ddnet] <Ryozuki> oh rust made you handle unexisting values!
08:48 <+bridge> [ddnet] <Jupstar ✪> I prefer to set a default
08:49 <+bridge> [ddnet] <Ryozuki> i dont
08:49 <+bridge> [ddnet] <Jupstar ✪> Like pretty much all languages allow
08:49 <+bridge> [ddnet] <Jupstar ✪> I hope that you are aware that rust always to implement a default per type
08:50 <+bridge> [ddnet] <Jupstar ✪> Since that is allowed there is no reason to not allow it on member variable level too
08:50 <+bridge> [ddnet] <Jupstar ✪> E.g #[default] for enumerations
08:51 <+bridge> [ddnet] <Ryozuki> they implement the default trait
08:51 <+bridge> [ddnet] <Ryozuki> just implement default if you want a default
08:51 <+bridge> [ddnet] <Ryozuki> so you are explicit about choosing to use a default
08:55 <+bridge> [ddnet] <Jupstar ✪> Imo {} is just as explicit
08:57 <+bridge> [ddnet] <Ryozuki> Ew
09:10 <+ChillerDragon> My client claims to have a gamedata snap item with a starttick of 343449 which is 0x00 0x00 0x86 0x2d or the other way around how ever you wanna endian it. But when looking at the traffic in wireshark I can not find a single snapshot payload that includes 0x2d or 0x86 how can that be? https://zillyhuhn.com/cs/.1668672344.png
09:38 <+ChillerDragon> okay got it 
09:39 <+ChillerDragon> https://zillyhuhn.com/cs/.1668674323.png
09:39 <+ChillerDragon> the 32 bits are packed so you gotta unpack the 4 bytes to get the actual number 343449
10:07 <+bridge> [ddnet] <Learath2> Oh yeah Default::default is so unwieldy. It needs some sugar
10:09 <+ChillerDragon> leeeraaaaaato im losing my sanity here :c
10:10 <+bridge> [ddnet] <Jupstar ✪> Please move#developer back
10:10 <+ChillerDragon> i feel like solving a sudoku here and i hate sudokus
10:10 <+ChillerDragon> wot u mean jopstar?
10:10 <+bridge> [ddnet] <Jupstar ✪> Someone moved discord channel
10:11 <+ChillerDragon> discordo problem os
10:11 <+bridge> [ddnet] <Jupstar ✪> Instant kick
10:11 <+bridge> [ddnet] <Learath2> Not me, I dont even think you can move them on android :F
10:11 <+bridge> [ddnet] <Jupstar ✪> Xd
10:11 <+ChillerDragon> im sure jopstar did it client side
10:11 <+ChillerDragon> 2iq
10:12 <+bridge> [ddnet] <Learath2> Ok you can but it has very weird UX
10:12 <+ChillerDragon> lerato
10:12 <+ChillerDragon> send brain
10:12 <+ChillerDragon> i can parse the first snap item just fine but there is no way to interpret the remaining bytes as something valid :(
10:13 <+ChillerDragon> https://zillyhuhn.com/cs/.1668676391.png
10:13 <+ChillerDragon> look at where the first white bytes start what should that be?
10:14 <+ChillerDragon> the first row does make sense its the first snap the client got and the first item is game data
10:14 <+ChillerDragon> with id 3 and its type is 6
10:14 <+ChillerDragon> wait what why does gamedata even have an id? xd
10:14 <+ChillerDragon> anyways game data is 3 ints ``m_GameStartTick, m_GameStateFlags, m_GameStateEndTick`` so i read 3 times 4 bytes? ye?
10:15 <+bridge> [ddnet] <Learath2> Makes sense
10:15 <+ChillerDragon> but then i end up with 91 02 00 80
10:16 <+ChillerDragon> and no matter how i jiggle, flip, sniff, repack, 7zip them they wont give me any valid snap type :(
10:16 <+bridge> [ddnet] <Learath2> Is this a ddnet server?
10:16 <+ChillerDragon> no vanilla 0.7
10:16 <+ChillerDragon> the last 2 bytes should be swapped to 0x80 0x00 i think
10:16 <+ChillerDragon> that should make up the type
10:17 <+ChillerDragon> but thats like 32768
10:17 <+ChillerDragon> which seems a bit big for a snap item type :(
10:17 <+ChillerDragon> also the id is higher than snoop dog
10:18 <+bridge> [ddnet] <Learath2> Gamedata is always sent with id 0
10:18 <+ChillerDragon> also how are the bytes ``00 0a 00 a9`` unpacked to ``0`` and how are the bytes ``d8 2e 90 04`` ALSO unpacked to ``0``?!
10:18 <+ChillerDragon> ok good lead
10:18 <+ChillerDragon> so i  parsed game data wron alr
10:18 <+ChillerDragon> thanks
10:19 <+ChillerDragon> ah ye lel i even printed that in the client and didnt realize https://zillyhuhn.com/cs/.1668676756.png
10:19 <+ChillerDragon> ok so?
10:19 <+ChillerDragon> aw98dh89awh98dawd
10:19 <+ChillerDragon> im about to mental breakdown
10:20 <+bridge> [ddnet] <Learath2> First of all, are you sure this is the correct snap we are looking at?
10:20 <+ChillerDragon> as in?
10:20 <+ChillerDragon> name a sample of incorrect
10:20 <+bridge> [ddnet] <Learath2> As in is this the correct packet? Is this really supposed to have a gamedata in it
10:20 <+ChillerDragon> a
10:20 <+ChillerDragon> somewhat sure xd
10:21 <+ChillerDragon> i check it like this https://zillyhuhn.com/cs/.1668676863.png
10:21 <+ChillerDragon> and in on_snapshot i only do the print if it is a snapsingle
10:21 <+ChillerDragon> the other switch case branches do work fine and get my client in a very happy state so i assume my msg id unpacker is fine
10:22 <+ChillerDragon> i might have unpacked the snap chunk payload wrong. maybe i cut off too little or too much in the beginning to get for the snap header
10:22 <+ChillerDragon> but my parsed snap header looks very good too
10:22 <+bridge> [ddnet] <Learath2> Is this the whole packet? Have you handled the header first?
10:22 <+ChillerDragon> https://zillyhuhn.com/cs/.1668676967.png
10:23 <+ChillerDragon> yes
10:23 <+ChillerDragon> here the whole packet with header
10:23 <+ChillerDragon> i mean it the whole chunk not packet
10:23 <+ChillerDragon> i did parse the tw packet header
10:24 <+ChillerDragon> and also the chunk header and also the chunk payload snap message header
10:24 <+ChillerDragon> maybe heinrich was right after all
10:24 <+ChillerDragon> and there is no CHUNK field
10:24 <+ChillerDragon> so chunk_num is not in the header but the id of gamedata?
10:25 <+ChillerDragon> that would be 0x00
10:25 <+ChillerDragon> ah wait no
10:25 <+ChillerDragon> would be 0x00 0x03 -> 0x03 0x00 -> 768
10:25 <+ChillerDragon> also too high
10:26 <+ChillerDragon> i would assume i totally missed some 3rd unpack step if i would parse the start tick so correct 34349
10:27 <+ChillerDragon> wouldn't
10:29 <+bridge> [ddnet] <Learath2> Mh, fwiw what's at the start of that delta isn't exactly sane to me either
10:32 <+ChillerDragon> u dont approve ``delta_tick=440241`` ?
10:34 <+ChillerDragon> I it is close to the game tick ``game_tick=457770 delta_tick=457771`` thats also what the vanilla client ususally shows
10:34 <+ChillerDragon> https://zillyhuhn.com/cs/.1668677687.png
10:39 <+bridge> [ddnet] <Learath2> Are you sure you decompressed this first?
10:39 <+bridge> [ddnet] <Learath2> Nothing about these values make much sense to me
10:40 <+bridge> [ddnet] <Learath2> e.g. have you seen `CVariableInt::Decompress`
10:41 <+ChillerDragon> i have seen but not understood CVariableInt::Decompress
10:41 <+ChillerDragon> i just do a regular unpacker get_int
10:41 <+ChillerDragon> imo the header looks very fine doesnt it?
10:42 <+ChillerDragon> its the same i get in the vanilla client
10:42 <+ChillerDragon> but yea varint::decompress is only applied on the data not the header
10:42 <+bridge> [ddnet] <Learath2> The packet stuff looks fine. The header of the delta looks insane
10:42 <+ChillerDragon> what exactly looks insane to you?
10:42 <+bridge> [ddnet] <Learath2> 11 ae d8 2e deleted objects??
10:43 <+ChillerDragon> wait where do you see deleted objects xd
10:43 <+bridge> [ddnet] <Learath2> Or af d8 2e b3 updated ones?
10:43 <+ChillerDragon> wait wot
10:43 <+ChillerDragon> the 11 is NETMSG_SNAPSINGLE
10:44 <+bridge> [ddnet] <Learath2> The first 3 ints of deltashots give you the amount of objects deleted, updates and one other int
10:44 <+ChillerDragon> okay i totally ignored those
10:44 <+bridge> [ddnet] <Learath2> Oh that is the netmsg header
10:44 <+ChillerDragon> lemme add those and see if it helps xd
10:44 <+ChillerDragon> its 3 ints of 4 bytes?
10:45 <+ChillerDragon> of the payload right?
10:45 <+bridge> [ddnet] <Learath2> Yes
10:45 <+ChillerDragon> ok lemme add those bois
10:46 <+ChillerDragon> honestly i did not get the whole delta part
10:46 <+ChillerDragon> this is the first snap i get against what can it delta?
10:46 <+bridge> [ddnet] <Learath2> But you cant just add those before doing the decompress
10:47 <+ChillerDragon> isnt the decompress just doing a unpacker get int?
10:47 <+bridge> [ddnet] <Learath2> The deltashot is an array of integers basically but they are all packed
10:47 <+bridge> [ddnet] <Learath2> Yes, you should be able to just do get int until the end
10:48 <+ChillerDragon> yes i do that
10:48 <+ChillerDragon> so this compress() https://github.com/teeworlds/teeworlds/blob/26d24ec061d44e6084b2d77a9b8a0a48e354eba6/src/engine/server/server.cpp#L599
10:48 <+ChillerDragon> is basically the same as this addint() https://github.com/teeworlds/teeworlds/blob/26d24ec061d44e6084b2d77a9b8a0a48e354eba6/src/engine/server/server.cpp#L610
10:48 <+ChillerDragon> but for multiple values right?
10:49 <+bridge> [ddnet] <Learath2> Yes, which is also how I know that everything should align nicely on a 4 byte grid 😄
10:50 <+ChillerDragon> so smort
10:51 <+bridge> [ddnet] <Learath2> No, just too much time in this one codebase
10:51 <+ChillerDragon> hehe
10:51 <+ChillerDragon> so expierenced
10:51 <+ChillerDragon> omg when do i learn typing
10:51 <+bridge> [ddnet] <Learath2> Parsing a single delta against snapempty is honestly the easy part
10:52 <+ChillerDragon> ah delta against empty
10:52 <+ChillerDragon> that could be added to the snap doc
10:52 <+ChillerDragon> first delta is against empty
10:52 <+bridge> [ddnet] <Ryozuki> Add it
10:56 <+bridge> [ddnet] <Learath2> Chiller, your development methods are quite chaotic if I may say 😄
10:56 <+bridge> [ddnet] <Learath2> Why don't you just open the source and follow the flow?
10:57 <+ChillerDragon> imo looking at something i can test against like the actual bytes is more graspable than looking at the c++ code
10:57 <+ChillerDragon> https://zillyhuhn.com/cs/.1668679001.png
10:58 <+ChillerDragon> the first 3 ints of the payload are a bit high
10:58 <+ChillerDragon> also the unpacker does not read the full 4 bytes because they do not have the extended bits set
11:01 <+ChillerDragon> good quote added to my github profile :D
11:04 <+bridge> [ddnet] <Learath2> chunk_num?
11:06 <+ChillerDragon> CHUNK NUM!
11:06 <+ChillerDragon> ? wdym
11:06 <+ChillerDragon> its this https://github.com/teeworlds/teeworlds/blob/26d24ec061d44e6084b2d77a9b8a0a48e354eba6/src/engine/server/server.cpp#L613
11:08 <+bridge> [ddnet] <Learath2> I’m fairly certain snapsingle doesn’t have part and num_parts at all
11:10 <+ChillerDragon> yes it does not
11:10 <+ChillerDragon> i display the default in that case
11:12 <+bridge> [ddnet] <Learath2> Part size should be unpacked after chunk_no, no?
11:12 <+ChillerDragon> yo lerato do u get emails when i tag u on github? bcs i rly like to do that xd
11:13 <+bridge> [ddnet] <Learath2> I do get emails 😛
11:13 <+ChillerDragon> opsi xd
11:13 <+ChillerDragon> chunk_no is the very last field before data init?
11:13 <+ChillerDragon> https://github.com/teeworlds/teeworlds/blob/26d24ec061d44e6084b2d77a9b8a0a48e354eba6/src/engine/server/server.cpp#L613
11:13 <+ChillerDragon> and part size is not part of the payload
11:13 <+ChillerDragon> wait or is it? xd
11:15 <+bridge> [ddnet] <Voxel> i love how fat the og tee is
11:15 <+ChillerDragon> ?
11:16 <+bridge> [ddnet] <Voxel> in the tw github icon
11:16 <+ChillerDragon> send pic or it didnt happen
11:16 <+bridge> [ddnet] <Learath2> That Chunk there is the part size
11:16 <+ChillerDragon> i was about to say it xd
11:16 <+ChillerDragon> https://github.com/teeworlds/teeworlds/blob/master/src/engine/client/client.cpp#L1386
11:17 <+ChillerDragon> i am totally not doing this: https://zillyhuhn.com/cs/.1668680208.png
11:17 <+ChillerDragon> xd
11:17 <+bridge> [ddnet] <Learath2> I am dying of starvation so I need go go away for a minute
11:17 <+ChillerDragon> same
11:17 <+ChillerDragon> minus the actually eat part
11:17 <+ChillerDragon> xd
11:55 < Qame> I use Arch btw
11:55 <+bridge> [ddnet] <chillerdragon> Still don’t know how decompress ensures 4 byte alignment
11:56 <+bridge> [ddnet] <chillerdragon> UnpackInt could read 1 to unlimited bytes depending on the extension bit
12:06 <+bridge> [ddnet] <Sorah> did someone finally came up with a good reason to not add something to get the old UI and stuff back ? or is it still no bad for you get used to it ?
12:15 <+bridge> [ddnet] <Jupstar ✪> What old ui
12:16 <+bridge> [ddnet] <Jupstar ✪> Tw ui is already from stone ages
12:17 <+bridge> [ddnet] <Jupstar ✪> If you mean HUD. There is no logical reason. If you mean in game stars. Well
12:20 <+bridge> [ddnet] <Learath2> It is only ever passed 4 byte ints. Look at ::Compress. It even uses sizeof(int) there
12:21 <+bridge> [ddnet] <chillerdragon> Hmm how do you pack a number lower than 63 on four bytes?
12:25 <+ChillerDragon> look at thet line from thex hexdump for example ``00 0b 00 08`` it reads the first byte as 0 and is done
12:25 <+bridge> [ddnet] <Learath2> Packed it is smaller than 4 bytes
12:25 <+ChillerDragon> if you read another int you read the ``0b`` not the next line
12:26 <+ChillerDragon> but the unpacker stops at the first byte that misses the extension bit right?
12:26 <+bridge> [ddnet] <Learath2> But when you unpack you will always get 4 bytes, if you get less you need to pad with 0
12:26 <+ChillerDragon> and the next unpack continues there
12:26 <+ChillerDragon> ou hm wot
12:26 <+ChillerDragon> so how would i read that line?
12:26 <+ChillerDragon> i read 0 and pad it with 3 bytes to become 00 00 00 00 ?
12:27 <+ChillerDragon> and what do i read next?
12:27 <+bridge> [ddnet] <Learath2> Yes
12:27 <+ChillerDragon> 0b?
12:27 <+bridge> [ddnet] <Learath2> Yes
12:27 <+ChillerDragon> interesting
12:27 <+bridge> [ddnet] <Sorah> yes there is no logical reason to not give a option to get the old look back
12:28 <+ChillerDragon> so 0b misses the negative and the extension bit
12:28 <+ChillerDragon> https://zillyhuhn.com/cs/.1668684494.png
12:28 <+ChillerDragon> so it gets interpreted as 11
12:28 <+ChillerDragon> and padded by 3 0 bytes?
12:28 <+bridge> [ddnet] <Learath2> If you mean the stars I don't mind there being an option to mimic them client side. I just haven't had the time for it
12:29 <+ChillerDragon> then this is read next? ``00 0b <00> 08`` ?
12:29 <+ChillerDragon> 0 
12:29 <+bridge> [ddnet] <Learath2> Makes sense to me
12:29 <+ChillerDragon> + 3 pad bytes
12:29 <+ChillerDragon> then 08
12:29 <+ChillerDragon> which is 8 + 3 pad bytes
12:29 <+bridge> [ddnet] <Sorah> well ye the other stuff i can just turn off  but yes  the stars / sword thing
12:29 <+ChillerDragon> oke
12:29 <+ChillerDragon> thanks a lot learto
12:29 <+bridge> [ddnet] <Learath2> This will get you to the original snapshot that was compressed
12:30 <+bridge> [ddnet] <Sorah> would be really nice =P
12:30 <+ChillerDragon> so thats why the payload has not to have align with 4
12:30 <+ChillerDragon> because you do not unpack 4 bytes at a time
12:30 <+ChillerDragon> but to 4 bytes
12:30 <+ChillerDragon> that def bamboozeld me
12:31 <+bridge> [ddnet] <Sorah> ah and from what i have been told there is also no way to turn off the sitting animation ? ( idk if running animation is in yet )
12:31 <+ChillerDragon> yes f3 on removing the new stuff
12:31 <+ChillerDragon> while at it can we also remove a bunch of tiles and all tune zones thanks  hehe
12:32 <+bridge> [ddnet] <Sorah> dont even need option  like checkbox just in F1 would be enough for people that care about it
12:33 <+ChillerDragon> @Sorah you can try asking @Tater he is big on config options in the tater client ddnet fork
12:33 <+bridge> [ddnet] <Learath2> Let's remove everything about ddnet. Honestly, I think we perverted teeworlds enough
12:33 <+ChillerDragon> maybe he can make something happen for you :) 
12:33 <+bridge> [ddnet] <Learath2> We should return to vanilla
12:33 <+bridge> [ddnet] <Sorah> ah good to know :O thanks
12:34 <+ChillerDragon> @Learath2 unpopular opinion but vanilla + freeze is pretty good already. Finish and start line is dope too. Thats about all you need. the rest is bloat. We can argue about hook through thats borderline okay.
12:34 <+bridge> [ddnet] <Sorah> cant we just remove the spawn tile ?
12:34 <+ChillerDragon> no that good
12:35 <+ChillerDragon> for measuring times
12:35 <+bridge> [ddnet] <Learath2> I agree. Remove all the antiping too. We should only predict what matricks wanted to predict
12:35 <+ChillerDragon> as for commands those are cool /rank /points /mapinfo /cmdlist /info the rest is bloat
12:35 <+ChillerDragon> nono antiping good
12:35 <+bridge> [ddnet] <Learath2> Tees should be able to rubberband in and out of freeze all the time as that's how it was intended
12:35 <+ChillerDragon> i only talked about tiles
12:36 <+ChillerDragon> soon ima replace my ddnet++ project by ddnet-- project the ddnet-lite fork xd without bloat
12:36 <+bridge> [ddnet] <Learath2> Nono, go all out, remove everything that isn't vanilla
12:37 <+ChillerDragon> btw i have been playing with a icecube freeze skin since that came up in some conversation here
12:37 <+ChillerDragon> and i did not get used to it yet
12:38 <+ChillerDragon> tho you gotta count in that i basically rq tw.
12:38 <+ChillerDragon> changing stuff is always tricky
12:38 <+bridge> [ddnet] <Jupstar ✪> For HUD? Tell me which... The hearts that show ur ddrace life?
12:39 <+bridge> [ddnet] <Sorah> ye my bad i meant the stars while in freeze and the sword
12:39 <+ChillerDragon> @Learath2 yo the int padding is basically useless isnt it? if i pad 0x08 with 3 null bytes i still end up with decimal 8 in the end dont i?
12:40 <+bridge> [ddnet] <Learath2> Yes. But that is what the original snapshot had to begin with before compression
12:40 <+ChillerDragon> so i use the padded size to count the amount 
12:40 <+ChillerDragon> like the snap item payload size
12:40 <+ChillerDragon> is the uncompressed?
12:41 <+bridge> [ddnet] <Learath2> I don't remember and I don't have my tablet with me to check
12:41 <+ChillerDragon> so i can do some getint and everytime i do a getint i increment my red_bytes variable by 4?
12:41 <+ChillerDragon> ok ill give some tries
12:41 <+ChillerDragon> i really do appreciate helping me!
12:41 <+ChillerDragon> its so cute <3
12:41 <+ChillerDragon> you*
12:41 <+ChillerDragon> omg
12:41 <+bridge> [ddnet] <Learath2> I think the size of the snapshot is given uncompressed and the crc is also calculated from the uncompressed version
12:42 <+ChillerDragon> i mean the individual snap item sizes
12:42 <+bridge> [ddnet] <Swarfey> Crc is the Data of all items Combined
12:42 <+ChillerDragon> like gamedata obj being size 3
12:42 <+ChillerDragon> is that 3 * 4 bytes compressed or uncompressed?
12:42 <+ChillerDragon> o helo swarfi
12:43 <+ChillerDragon> nodelsuf
12:45 <+bridge> [ddnet] <Learath2> That is definitely uncompressed
12:46 <+ChillerDragon> interesting
12:46 <+ChillerDragon> is that so obvious and im being weird minded or is that something that could be mentioned somewhere?
12:47 <+ChillerDragon> so me splitting it in lines of 4 bytes suddenly makes less sense huh? @Learath2
12:47 <+bridge> [ddnet] <Learath2> It is pretty obvious but as I said I spent way too much time in this codebase, so maybe it's not
12:48 <+bridge> [ddnet] <Learath2> Well I thought you were working with decompressed data, not just raw packets
12:48 <+ChillerDragon> ye
12:48 <+ChillerDragon> i like it raw
12:48 <+ChillerDragon> raaaaaaaaaaaawr
12:49 <+bridge> [ddnet] <Learath2> Raw packets you'll have to just split some other way
12:49 <+ChillerDragon> ye
12:49 <+ChillerDragon> migh split it in 2 byte rows :shrug:
12:50 <+bridge> [ddnet] <Learath2> Deleted items are 1 byte each
12:58 <+ChillerDragon> 1 byte? o.O is that only their id then i assume?
12:59 <+ChillerDragon> wait but what if you have more than 64 snap items their id should exceed 1 byte?
13:34 <+bridge> [ddnet] <murpi> This should still be picked up I think
13:35 <+bridge> [ddnet] <murpi> just w/o accounts
13:42 <+bridge> [ddnet] <Jupstar ✪> Lol why rq deen :/. Can also provide optional accounts
13:42 <+bridge> [ddnet] <Jupstar ✪> Without any new features
13:42 <+bridge> [ddnet] <Jupstar ✪> No archivements etc
13:52 <+bridge> [ddnet] <uwu> No balls :feelsbadman:
13:52 <+bridge> [ddnet] <Ryozuki> F
14:00 <+bridge> [ddnet] <deen> As I said, everyone has different imagination for what s2 is supposed to be. I don't have time for even 10% of that and the other half would be unhappy with the result
14:11 <+bridge> [ddnet] <Jupstar ✪> Mh
14:11 <+bridge> [ddnet] <Jupstar ✪> 10% Sounds good to me
14:12 <+bridge> [ddnet] <Jupstar ✪> Die season 3 another 10%
14:18 <+bridge> [ddnet] <deen> what value is it without accounts? you can just reset someone else's rating then
14:32 <+bridge> [ddnet] <Learath2> 1 int*
14:32 <+bridge> [ddnet] <Learath2> https://www.cnil.fr/en/discord-inc-fined-800-000-euros
14:33 <+bridge> [ddnet] <Learath2> Get rekt nsa front
14:34 <+bridge> [ddnet] <Stepfunn> I mean why is the whole accounts idea canceled now. Just clarify to people that we only get accounts. That would be a huge change already. Dont throw the whole idea out of the window because of peoples expectations
14:38 <+bridge> [ddnet] <murpi> we could start collecting data how people would rate each individual map after finish
14:38 <+bridge> [ddnet] <murpi> AFAIK the novice map pool is quite unbalanced
14:47 <+ChillerDragon> yo @Learath2 do my colors make sense to you? https://zillyhuhn.com/cs/.1668692677.png
14:47 <+ChillerDragon> it sadly put the start tick into the flags :(
14:48 <+ChillerDragon> i feel like my code parses the bytes as you described and yet the result does not match my expectation
14:50 <+bridge> [ddnet] <deen> If we just add accounts and reset all points to 0, many players will be unhappy
14:50 <+bridge> [ddnet] <deen> they expect large changes, which we are not able to provide yet
14:50 <+ChillerDragon> but that was never your idea deen was it?
14:50 <+bridge> [ddnet] <Learath2> Hm, you seem to unpack the first item and the headers just fine
14:50 <+ChillerDragon> i thought both systems stay
14:50 <+ChillerDragon> nono lerato
14:50 <+ChillerDragon> look at the payload of the first item
14:50 <+ChillerDragon> the very first payload byte is 0x00
14:50 <+ChillerDragon> which should be the gamestart tick
14:51 <+ChillerDragon> and that should never be 0x00
14:51 <+ChillerDragon> but yea up until there it also looks good to me
14:51 <+bridge> [ddnet] <Learath2> Oh, you do seem 1 byte off, hm
14:51 <+ChillerDragon> yes!
14:51 <+ChillerDragon> but what is that one nullbyte
14:54 <+bridge> [ddnet] <Learath2> Let me take a quick thinking session about it
14:54 <+Ryozuki> chiller document ur findings
14:55 <+Ryozuki> will be useful for my rust port 
14:55 <+ChillerDragon> i try :C
14:57 <+Ryozuki> i have teeint
14:57 <+Ryozuki> im doing teeman
14:57 <+bridge> [ddnet] <Learath2> That null right there is the ID
14:57 <+Ryozuki> and then teeprot
14:57 <+Ryozuki> my rustyman doesnt work well with tw cuz tw huffman has quirks
14:57 <+Ryozuki> eof symbol etc
14:57 <+Ryozuki> so i made teeman
14:58 <+ChillerDragon> @Learath2 so i unpack 2 integers? one for type and one for id?
14:58 <+bridge> [ddnet] <louis> i guess time to major in cs to become a ddnet dev :monkaS:
14:58 <+ChillerDragon> because heinrichs doc say that type and id share one 32 bit int 
14:59 <+Ryozuki> lower 16 bit and upper 16
14:59 <+Ryozuki> iirc
14:59 <+ChillerDragon> yes
14:59 <+bridge> [ddnet] <Learath2> I honestly don’t know why we do this, but it seems when creating the delta we separate them again
14:59 <+ChillerDragon> wat
14:59 <+Ryozuki> i also notice a lot of "size" variables reprsented with "int" and not "unsigned int" or "size_t"
14:59 <+bridge> [ddnet] <Learath2> snapshot.cpp:L322 and L323
15:00 <+ChillerDragon> whcih codebase and tag?
15:00 <+ChillerDragon> vanilla master?
15:00 <+bridge> [ddnet] <Learath2> This is tw legacy, I prefer uints too but I think heinrich made some argument that I couldn’t argue against 😛
15:00 <+bridge> [ddnet] <Learath2> ddnet master is all I have on this ipad, sorry. That’s the reference
15:00 <+ChillerDragon> if we would rewrite in bash there would not be any confusion about int vs unsigned int
15:01 <+ChillerDragon> all good i just gotta know xd
15:01 <+ChillerDragon> yea i see 
15:01 <+Ryozuki> coding on ipad?
15:01 <+ChillerDragon> gigachad
15:01 <+bridge> [ddnet] <Learath2> Why on earth do we store type and ID together but send it over the network as 2 ints idk
15:01 <+Ryozuki> idk
15:02 <+ChillerDragon> so heinrichs docs are trap?
15:02 <+ChillerDragon> cuz code is trap?
15:02 <+bridge> [ddnet] <Learath2> At a lecture, so I only took my ipad with me
15:02 <+Ryozuki> focus on the lecture
15:02 <+Ryozuki> kek
15:02 <+ChillerDragon> was about to say it
15:02 <+bridge> [ddnet] <Learath2> Ddnet master is on here incase sth breaks majorly while I’m on vacation 😄
15:03 <+ChillerDragon> vacation from your dayjob ddnet? xd
15:03 <+bridge> [ddnet] <Learath2> Doesn’t matter. I already know the material, just here so I don’t end up watching 8 hours of youtube at home instead
15:03 <+ChillerDragon> pro
15:03 <+ChillerDragon> go send picture from your university
15:04 <+ChillerDragon> i wanna see where u vibe rn
15:04 <+ChillerDragon> go dox
15:04 <+bridge> [ddnet] <Learath2> Maybe after the lecture. I’m too socially inept to take pix during lecture
15:04 <+ChillerDragon> nob
15:04 <+ChillerDragon> inept
15:04 <+ChillerDragon> thats not even a word
15:05 <+ChillerDragon> maybe it is not the id
15:05 <+bridge> [ddnet] <Learath2> It is probably the id
15:05 <+ChillerDragon> maybe there is some nulltermination 
15:05 <+ChillerDragon> because look at the end tick
15:05 <+ChillerDragon> it shouldnt be 0 either
15:05 <+ChillerDragon> even if i shift them
15:05 <+ChillerDragon> wait lemme send update
15:06 <+ChillerDragon> https://zillyhuhn.com/cs/.1668693952.png
15:06 <+ChillerDragon> i just skip the 0 byte now
15:06 <+ChillerDragon> starttick is good now!
15:06 <+ChillerDragon> flags i guess too
15:06 <+ChillerDragon> but end tick wasnt 0 i think lemme check client
15:06 <+bridge> [ddnet] <Learath2> End tick 0 sounds fine to me
15:07 <+ChillerDragon> nvm
15:07 <+ChillerDragon> yes u rite
15:07 <+bridge> [ddnet] <Learath2> That 0 is def the id
15:07 <+ChillerDragon> https://zillyhuhn.com/cs/.1668694015.png
15:07 <+ChillerDragon> thats exactly what the client gets
15:07 <+ChillerDragon> pog
15:07 <+ChillerDragon> lemme try to put these 100 lines of spagehtii code into a loop so i can parse more than 1 snap item xd
15:07 <+ChillerDragon> brb in 2hours
15:08 <+bridge> [ddnet] <Learath2> gl
15:12 <+ChillerDragon> https://zillyhuhn.com/cs/.1668694366.png
15:13 <+ChillerDragon> at least it did not crash :shrug:
15:13 <+ChillerDragon> it looks okayish right?
15:14 <+ChillerDragon> could almost be real snap data
15:14 <+ChillerDragon> i see my aim 0 10 i see my pos 177 272
15:14 <+ChillerDragon> HOLY SHIT THIS LOOKS GOOD
15:15 <+ChillerDragon> thank you so much @Learath2 drinks are on me when we meet
15:16 <+bridge> [ddnet] <Learath2> Fix the type and id thing and you are golden
15:16 <+bridge> [ddnet] <Learath2> That 0 is definitely the id 😄
15:16 <+ChillerDragon> but its 0 for all?
15:16 <+ChillerDragon> is that correct?
15:16 <+bridge> [ddnet] <Learath2> You only have 1 character
15:16 <+ChillerDragon> ah ye
15:16 <+ChillerDragon> it is 
15:16 <+ChillerDragon> i somehow thought ids are uniq
15:16 <+ChillerDragon> but only unique per type huh?
15:16 <+bridge> [ddnet] <Learath2> Gamedata and other stuff like that have only one instance so id 0 always
15:17 <+bridge> [ddnet] <Learath2> Yeah ids are unique per type
15:17 <+ChillerDragon> but getting the id of the first 16 bits of the type byte also works :D
15:17 <+ChillerDragon> lemme join a player and check
15:17 <+bridge> [ddnet] <uwu> Create new fork or new repo and start doing smth cool with accounts on free time, when smth will be done, say: "Look what we got, we will reset points BUT you will get cool <feature name>" There were a lot of developers who wanted accounts and left this game because of ddnet's progress procrastination, maybe some new developers or even old ones will hear the news and help with development 🧐
15:17 <+ChillerDragon> https://zillyhuhn.com/cs/.1668694668.png
15:18 <+ChillerDragon> yes you are rite lerato
15:18 <+ChillerDragon> mr 0 becomes mr 1
15:18 <+ChillerDragon> and the upper 16 bits stay 0
15:18 <+bridge> [ddnet] <Learath2> It can't work properly, the type will always have 00 00 significant nibble
15:18 <+ChillerDragon> NIBBLE hihi
15:18 <+ChillerDragon> so bug in heinrich dox?
15:19 <+bridge> [ddnet] <Learath2> Idk, show docs?
15:19 <+ChillerDragon> https://zillyhuhn.com/cs/.1668694749.png
15:19 <+bridge> [ddnet] <deen> every developer has a different interpretation of what accounts should do, mostly not compatible
15:19 <+ChillerDragon> https://github.com/heinrich5991/libtw2/blob/48a2573af66105fc38f032fe22cfcc60f95f7485/doc/snapshot.md#item-key
15:19 <+ChillerDragon> or is that deleted ones?
15:19 <+ChillerDragon> maybe thats deleted only
15:19 <+bridge> [ddnet] <uwu> Thats what issues and pull requests are for🥸
15:20 <+bridge> [ddnet] <Learath2> No docs correct, ur reading the wrong part...
15:20 <+ChillerDragon> classic
15:20 <+ChillerDragon> xd
15:20 <+ChillerDragon> its deleted keys right?
15:20 <+bridge> [ddnet] <uwu> Milestones and etc
15:20 <+bridge> [ddnet] <Learath2> Look at how he describes deltas. There he does tell you it's 2 ints separately for type and id
15:20 <+bridge> [ddnet] <Learath2> Deletions are by key, yes
15:20 <+ChillerDragon> omagawd xd
15:20 <+ChillerDragon> docs cant safe me
15:20 <+ChillerDragon> yes its so well documented haha
15:21 <+bridge> [ddnet] <deen> I can't even keep up with reading the comments on season 2, let alone start implementing anything, so no chance
15:22 <+bridge> [ddnet] <heinrich5991> I just finished reading the backlog
15:22 <+bridge> [ddnet] <heinrich5991> what Learath2 says, I think you're reading the wrong part of the docs
15:23 <+bridge> [ddnet] <heinrich5991> but if you do find errors, please PR fixes 🙂
15:23 <+bridge> [ddnet] <heinrich5991> particularly fancy is this item btw:
15:23 <+bridge> [ddnet] <heinrich5991> `_zero` is a padding field which must be zeroed by any snapshot delta writer and ignored by any snapshot delta reader.
15:23 <+bridge> [ddnet] <heinrich5991> as part of snapshot deltas
15:24 <+bridge> [ddnet] <Learath2> Ignoring the degenerate content. I spotted a unicode truncation error in the wild \\o/. It's not only us
15:24 <+bridge> [ddnet] <Learath2> https://cdn.discordapp.com/attachments/293493549758939136/1042807349301235812/Screenshot_20221117_152316.jpg
15:24 <+bridge> [ddnet] <uwu> Just start with the basics, i saw most devs liked matodor's server<->client interactions, after common registration/login are done you can start building more with the basement you already have
15:24 <+bridge> [ddnet] <uwu> https://cdn.discordapp.com/attachments/293493549758939136/1042807404892536932/unknown.png
15:24 <+bridge> [ddnet] <Learath2> Youtube community posts truncate unicode wrong
15:24 <+bridge> [ddnet] <uwu> No need to rush and make everything parallel
15:25 <+ChillerDragon> o helo heinrich
15:25 <+bridge> [ddnet] <Learath2> The technical part we probably can agree on, but it seems we all have different expectations of what even registration entails
15:25 <+ChillerDragon> sori for spammin da baklok
15:25 <+bridge> [ddnet] <deen> feels weird having the same conversation again in every channel
15:26 <+ChillerDragon> i do first blame the docs before i blame my self to keep my confidence up thats what keeps me going haha
15:26 <+ChillerDragon> @heinrich5991 if you need help on understand the snaps let me know :p
15:26 <+bridge> [ddnet] <uwu> Well, that sucks😄
15:26 <+bridge> [ddnet] <heinrich5991> proper way is to do it at grapheme boundaries
15:26 <+bridge> [ddnet] <Learath2> Heinrich and deen seem to want something extremely seamless. Mods and I seem to want some sort of verification with it
15:27 <+bridge> [ddnet] <heinrich5991> this one
15:27 <+ChillerDragon> wat is grapheme boundaries
15:27 <+bridge> [ddnet] <heinrich5991> what a user calls a character
15:27 <+ChillerDragon> is that a discord reply or what do you mean 
15:27 <+ChillerDragon> i dont get it
15:28 <+bridge> [ddnet] <Learath2> It is a discord reply to my broken unicode truncation example in youtube
15:28 <+bridge> [ddnet] <Ryozuki> Rust
15:28 <+ChillerDragon> a
15:28 <+ChillerDragon> ty
15:28 <+bridge> [ddnet] <heinrich5991> 👪
15:29 <+bridge> [ddnet] <Ryozuki> I think in rust its ub to have invalid utf8 in a str
15:29 <+bridge> [ddnet] <heinrich5991> how many characters is this?
15:29 <+bridge> [ddnet] <Ryozuki> So that would be hard in rust
15:29 <+bridge> [ddnet] <heinrich5991> users would say 1
15:29 <+bridge> [ddnet] <Ryozuki> Probs 2
15:29 <+bridge> [ddnet] <Ryozuki> Emojis are 2 usually
15:29 <+bridge> [ddnet] <heinrich5991> no, usually one
15:29 <+bridge> [ddnet] <heinrich5991> but the family one is amazingly bloated
15:29 <+bridge> [ddnet] <Ryozuki> Ah i mean codepoints
15:29 <+bridge> [ddnet] <Ryozuki> Or graphemes
15:29 <+bridge> [ddnet] <Ryozuki> Or jdk
15:29 <+bridge> [ddnet] <Ryozuki> Idk the words
15:29 <+bridge> [ddnet] <heinrich5991> one grapheme, many codepoints
15:29 <+bridge> [ddnet] <heinrich5991> yo uprobably mean utf-16 code units
15:30 <+bridge> [ddnet] <Learath2> 😄
15:30 <+bridge> [ddnet] <Ryozuki> Xd
15:30 <+bridge> [ddnet] <heinrich5991> emojis are the reason why some of the java developers woke up and found out that char isn't actually one full character
15:30 <+bridge> [ddnet] <heinrich5991> and mysql
15:30 <+bridge> [ddnet] <heinrich5991> and js
15:30 <+bridge> [ddnet] <heinrich5991> and dotnet
15:30 <+bridge> [ddnet] <Ryozuki> When i copied the chinese flag emoji to vim it ahowed me 2 characters that say C N
15:30 <+bridge> [ddnet] <heinrich5991> yes
15:30 <+bridge> [ddnet] <Learath2> This is why everyone gets unicode stuff wrong. Sticking to the terminology in the unicode specs is really your best bet
15:30 <+bridge> [ddnet] <heinrich5991> flags are a special case
15:30 <+bridge> [ddnet] <heinrich5991> because unicode didn't want to say which flags exist
15:31 <+bridge> [ddnet] <heinrich5991> so they just did the latin alphabet and said "encode your flag according to this country standard"
15:31 <+ChillerDragon> lmao political encoding
15:31 <+Ryozuki> also flags over ssh over tmux over vim break my vim display quite a bit
15:31 <+Ryozuki> i noticed this when putting flags on my next gen web
15:32 <+bridge> [ddnet] <heinrich5991> sounds like something is broken
15:32 <+bridge> [ddnet] <heinrich5991> in between
15:33 <+Ryozuki> yeah
15:33 <+bridge> [ddnet] <heinrich5991> have you configured utf-8 locales on your server?
15:33 <+Ryozuki> im sshing to my home pc
15:33 <+Ryozuki> but yeah
15:33 <+Ryozuki> its my gentoo
15:33 <+bridge> [ddnet] <fokkonaut> my commit messages be like: https://whatthecommit.com/
15:33 <+Ryozuki> LANG=en_US.utf8
15:33 <+Ryozuki> LC_CTYPE="en_US.utf8"
15:33 <+Ryozuki> LC_NUMERIC="en_US.utf8"
15:33 <+Ryozuki> LC_TIME="en_US.utf8"
15:33 <+Ryozuki> LC_COLLATE="en_US.utf8"
15:33 <+Ryozuki> LC_MONETARY="en_US.utf8"
15:33 <+Ryozuki> LC_MESSAGES="en_US.utf8"
15:33 <+Ryozuki> LC_PAPER="en_US.utf8"
15:33 <+Ryozuki> LC_NAME="en_US.utf8"
15:33 <+Ryozuki> LC_ADDRESS="en_US.utf8"
15:33 <+Ryozuki> LC_TELEPHONE="en_US.utf8"
15:34 <+Ryozuki> LC_MEASUREMENT="en_US.utf8"
15:34 <+Ryozuki> LC_IDENTIFICATION="en_US.utf8"
15:34 <+bridge> [ddnet] <Learath2> mfw spam
15:34 <+Ryozuki> LC_ALL=
15:34 <+Ryozuki> discord bot so slow
15:34 <+Ryozuki> its rly easy to make the bot detect new messages under a ms and group them as a single chat with newlines to discord
15:34 <+Ryozuki> a good feature for the bot
15:37 <+ChillerDragon> ``git commit -m "$(curl https://whatthecommit.com/ --silent | grep -F '<p>' | cut -d '>' -f2)"``
15:37 <+ChillerDragon> ^ commit with one of those phrases in one command @fokkonaut xd
15:38 <+ChillerDragon> requires unix tooling tho :p
15:39 <+bridge> [ddnet] <fokkonaut> my everyday routine
15:39 <+Ryozuki> i just put "ok" or "progress" or "fix"
15:39 <+Ryozuki> i should alias it
15:40 <+Ryozuki> "ok"
15:40 <+Ryozuki> and commits ok
15:40 <+bridge> [ddnet] <fokkonaut> https://cdn.discordapp.com/attachments/293493549758939136/1042811398511665152/image.png
15:41 <+bridge> [ddnet] <fokkonaut> https://cdn.discordapp.com/attachments/293493549758939136/1042811605357961226/image.png
15:41 <+bridge> [ddnet] <heinrich5991> Ryozuki: is en_US.utf8 correct?
15:41 <+bridge> [ddnet] <heinrich5991> it's en_US.UTF-8 for me
15:48 <+Ryozuki> thats my doubt
15:48 <+Ryozuki> but on gentoo it looks like its like mine
15:48 <+Ryozuki> idk
15:48 <+Ryozuki> @Learath2 ?
15:50 <+bridge> [ddnet] <Learath2> It’s en_US.utf8 for me too
15:53 <+Ryozuki> print("{:08b}", your_byte);
15:53 <+Ryozuki> rust is poggers
15:53 <+Ryozuki> ez binary print
15:54 <+Ryozuki> 10110001 00001000 00101010 01101110 00000000
15:54 <+bridge> [ddnet] <heinrich5991> I think c++xy or cxy had it as well
15:54 <+Ryozuki> what is cxy
15:57 <+bridge> [ddnet] <heinrich5991> c20 or sth
15:57 <+bridge> [ddnet] <heinrich5991> or c++17
15:58 <+bridge> [ddnet] <heinrich5991> idk
15:58 <+bridge> [ddnet] <heinrich5991> the version
15:59 <+bridge> [ddnet] <heinrich5991> ah, maybe not
15:59 <+bridge> [ddnet] <heinrich5991> can't find it on cppreference.com
15:59 <+ChillerDragon> yes i use that
16:07 <+bridge> [ddnet] <Learath2> I remember reading a proposal for it in C20 but iirc it didnt make it in
16:08 <+bridge> [ddnet] <heinrich5991> I like how extensible rust's version of printf is
16:08 <+bridge> [ddnet] <heinrich5991> makes printf debugging a lot easier 🙂
16:09 <+bridge> [ddnet] <heinrich5991> but don't tell Learath2 I sometimes don't use debuggers
16:10 <+bridge> [ddnet] <heinrich5991> btw @Learath2; https://github.com/ddnet/ddnet/issues/5411#issuecomment-1315788190 you don't have time to have an opinion on it or don't want to have an opinion on it?
16:12 <+bridge> [ddnet] <Stepfunn> @deen i get that you want to make the majority of players happy but i feel like just starting off with something basic would make a lot of people happy non the less. I had a really nice idea where we could maybe have a little talk about the season 2 plans. Give the community a better insight in how much work the features are that they ask for. Would help people understand and probably value the small features way more
16:12 <+bridge> [ddnet] <Learath2> I didn't have time for it, but I'll try to give one tonight
16:14 <+bridge> [ddnet] <Learath2> I think it'll be along the lines of I'm not sure whether we can realistically replace such a core part of the code with rust, but before saying that I'll need to take a look at how we handled the minimum rust version requirement
16:15 <+bridge> [ddnet] <Jupstar ✪> Can you also make sure no sys calls in main thread at the time of implementing. Would be really 👍
16:16 <+bridge> [ddnet] <Learath2> Hm, so move the networking to a new thread altogether? Is that really beneficial I wonder with the requirement of an introduction of a new synchronization point
16:16 <+bridge> [ddnet] <Jupstar ✪> A sys call is also kinda sync point xd
16:16 <+bridge> [ddnet] <Jupstar ✪> So yes worth it
16:16 <+bridge> [ddnet] <Learath2> I wanted to see if it actually helped once upon a time but the coupling was too tight for me to untangle for a quick test
16:16 <+bridge> [ddnet] <Jupstar ✪> I tested it already
16:16 <+bridge> [ddnet] <Jupstar ✪> And was worth it
16:17 <+bridge> [ddnet] <Jupstar ✪> Just listened with select and changed a atomic bool
16:17 <+bridge> [ddnet] <Jupstar ✪> On windows
16:17 <+bridge> [ddnet] <Jupstar ✪> Tbf
16:17 <+bridge> [ddnet] <heinrich5991> can you remind me what "worth it" was?
16:17 <+bridge> [ddnet] <Learath2> And you got better frametimes? Or what improved?
16:17 <+bridge> [ddnet] <heinrich5991> I remember we talked about it before
16:18 <+bridge> [ddnet] <Jupstar ✪> 20-30%
16:18 <+bridge> [ddnet] <heinrich5991> 20-30% of what?
16:18 <+bridge> [ddnet] <Jupstar ✪> If 100%
16:18 <+bridge> [ddnet] <Jupstar ✪> Of
16:18 <+bridge> [ddnet] <heinrich5991> frame times? input delay?
16:18 <+bridge> [ddnet] <Jupstar ✪> I dunno search the ddnet issue
16:18 <+bridge> [ddnet] <heinrich5991> map loading?
16:18 <+bridge> [ddnet] <Jupstar ✪> If the total program execution time
16:18 <+bridge> [ddnet] <Learath2> I can imagine it improving frametimes
16:18 <+bridge> [ddnet] <Jupstar ✪> All the time
16:19 <+bridge> [ddnet] <Jupstar ✪> Yeah ofc also more fps xd
16:19 <+bridge> [ddnet] <heinrich5991> I don't understand how we can have 30% run time reduction if the client is open for a user-determined time
16:19 <+bridge> [ddnet] <heinrich5991> what did you measure?
16:19 <+bridge> [ddnet] <Jupstar ✪> It's a profiler
16:19 <+bridge> [ddnet] <Jupstar ✪> Just look inside the issue
16:20 <+bridge> [ddnet] <heinrich5991> link?
16:20 <+bridge> [ddnet] <Jupstar ✪> Cmon sucks on mobile
16:20 <+bridge> [ddnet] <Jupstar ✪> Search recvfrom
16:20 <+bridge> [ddnet] <heinrich5991> https://github.com/ddnet/ddnet/issues/1996
16:20 <+bridge> [ddnet] <Robyt3> #1996
16:20 <+bridge> [ddnet] <DDNet> https://github.com/ddnet/ddnet/issues/1996
16:21 <+bridge> [ddnet] <Learath2> So you did select on another thread and signalled the main one to do a recvfrom only if the boolean flag is set?
16:22 <+bridge> [ddnet] <Learath2> I guess that should be easy enough to test out
16:23 <+bridge> [ddnet] <Learath2> Oh I already commented some sane suggestions on that issue 😛
16:25 <+Ryozuki> :D
16:25 <+bridge> [ddnet] <Jupstar ✪> Yes
16:26 <+bridge> [ddnet] <heinrich5991> so you still did syscalls on the main thread, but only when it was signalled
16:26 <+bridge> [ddnet] <heinrich5991> sounds comparatively easy to do
16:27 <+bridge> [ddnet] <heinrich5991> yea, the rust in a core component sounds annoying indeed
16:28 <+bridge> [ddnet] <heinrich5991> I'm not sure what to implement with rust. this is something that I wanted to do for a long time, and it seems like a good fit for rust, but I agree that we haven't even had a release with rust yet
16:29 <+bridge> [ddnet] <Learath2> It is still a tad absurd to me that recvfrom is so slow on windows. I might actually dig into that sometime
16:29 <+bridge> [ddnet] <heinrich5991> 😄
16:30 <+bridge> [ddnet] <heinrich5991> when do you start working at microsoft? ^^
16:30 <+bridge> [ddnet] <heinrich5991> you could fix this perf issue
16:30 <+bridge> [ddnet] <Learath2> :d
16:30 <+bridge> [ddnet] <Learath2> No we release ddnet kernel driver to monkeypatch it
16:30 <+bridge> [ddnet] <heinrich5991> oof
16:30 <+bridge> [ddnet] <Learath2> The ultimate spaghetti
16:32 <+Ryozuki> ddnet has linux first class support
16:32 <+Ryozuki> ddnet second class
16:32 <+bridge> [ddnet] <Learath2> Maybe the http module? I did fail to finish the curl multi thing again, might aswell
16:32 <+Ryozuki> based
16:32 <+Ryozuki> windows
16:32 <+Ryozuki> *
16:32 <+Ryozuki> yeah i also thought about the http module
16:33 <+bridge> [ddnet] <heinrich5991> what's missing from the curl multi thing again?
16:33 <+bridge> [ddnet] <heinrich5991> wasn't it basically finished?
16:33 <+bridge> [ddnet] <Learath2> I mean I did technicay finish the multi thing but I couldn't get it to compile on windows, then I got dragged into real life busyness
16:33 <+bridge> [ddnet] <Learath2> Technically*
16:34 <+bridge> [ddnet] <heinrich5991> ah
16:34 <+bridge> [ddnet] <heinrich5991> so fixing it on windows is the remaining step
16:34 <+bridge> [ddnet] <heinrich5991> I'll pretend to take a look at it and forget about it
16:35 <+bridge> [ddnet] <Learath2> Sounds perfect
16:37 <+bridge> [ddnet] <heinrich5991> errors look like straightforward type errors to me
16:37 <+bridge> [ddnet] <heinrich5991> something like atomic int not supporting = operator for ints
16:37 <+bridge> [ddnet] <Learath2> Which makes no sense really 😄
16:37 <+Ryozuki> emojis look so funny in terminal
16:38 <+bridge> [ddnet] <heinrich5991> I think atomic ints only support .store and .load, no?
16:39 <+bridge> [ddnet] <heinrich5991> https://en.cppreference.com/w/cpp/atomic/atomic/operator%3D
16:39 <+bridge> [ddnet] <heinrich5991> ah, apparently not, in C++
16:39 <+bridge> [ddnet] <Learath2> They have proper overloads
16:39 <+bridge> [ddnet] <heinrich5991> hmm
16:39 <+bridge> [ddnet] <heinrich5991> not in MVSC++? ^^
16:40 <+bridge> [ddnet] <Learath2> Anyway, I couldn't figure it out by looking and I really didnt want to set up visual studio again so I gave up on it that night
16:40 <+bridge> [ddnet] <heinrich5991> wait, I think I have a windows vm
16:40 <+bridge> [ddnet] <heinrich5991> let me try a minimal example
16:40 <+bridge> [ddnet] <Learath2> Gtg for a bit. I really need to finish this proof
16:41 <+bridge> [ddnet] <Learath2> @heinrich5991 fwiw I thought the issue was with enum type but as said, didnt debug further
16:41 <+bridge> [ddnet] <heinrich5991> alright
16:41 <+bridge> [ddnet] <heinrich5991> see you 🙂
16:41 <+bridge> [ddnet] <heinrich5991> good luck
16:47 <+Ryozuki> heinrich5991: does the huffman from tw us numbits 0xFFFFFFFF to represent an unset value?
16:47 <+Ryozuki> or are they actual bits
16:47 <+Ryozuki> see, if only they were using options
16:50 <+bridge> [ddnet] <heinrich5991> I don't remember the huffman impl from ddnet that well
16:51 <+bridge> [ddnet] <heinrich5991> let me take a look
16:51 <+Ryozuki> code has some if(pNode->m_NumBits)
16:51 <+Ryozuki> so its hard to know if they are to know if num_bits is not 0 or is the unset value 0xfffffff
16:52 <+bridge> [ddnet] <heinrich5991> NumBits of 0xffff_ffff seem to mark a "to be set" value
16:52 <+bridge> [ddnet] <heinrich5991> NumBits of 0 seem to be for non-leaf nodes
16:53 <+Ryozuki> isnt it better to check if a node has leafs than using num_bits?
16:54 <+bridge> [ddnet] <heinrich5991> *shrug*
16:54 <+bridge> [ddnet] <heinrich5991> either is fine, I guess
16:54 <+bridge> [ddnet] <heinrich5991> they use 0xffff_ffff as a marker value
16:55 <+bridge> [ddnet] <heinrich5991> maybe ERROR is defined in some WINAPI header somewhere?
16:55 <+bridge> [ddnet] <heinrich5991> I cannot reproduce in my minimal example
16:56 <+bridge> [ddnet] <heinrich5991> this would be supported by the fact that it only complains about lines containing ERROR
16:57 <+bridge> [ddnet] <heinrich5991> but not for `m_State = RUNNING` e.g.
16:57 <+bridge> [ddnet] <Jupstar ✪> tbh i generally think put as much in threads as possible
16:57 <+bridge> [ddnet] <Jupstar ✪> 
16:57 <+bridge> [ddnet] <Jupstar ✪> main thread must be clean
16:57 <+bridge> [ddnet] <Robyt3> Windows.h defined a macro ERROR as 0
16:57 <+bridge> [ddnet] <Jupstar ✪> tripple A game ddnet needs it
16:57 <+bridge> [ddnet] <Robyt3> Windows.h defines a macro ERROR as 0
16:59 <+bridge> [ddnet] <Robyt3> Just `#undef ERROR` after including Windows.h?
16:59 <+bridge> [ddnet] <heinrich5991> if this improves performance (and not just for newest computers), sounds good
16:59 <+bridge> [ddnet] <heinrich5991> I don't think we should mess with windows.h there
16:59 <+bridge> [ddnet] <Jupstar ✪> oh no
16:59 <+bridge> [ddnet] <Jupstar ✪> not this again xD
16:59 <+bridge> [ddnet] <Jupstar ✪> our main target is new computers
16:59 <+bridge> [ddnet] <heinrich5991> no, I also want to run ddnet on my computer
16:59 <+bridge> [ddnet] <Jupstar ✪> its new
17:00 <+bridge> [ddnet] <Jupstar ✪> enough
17:00 <+bridge> [ddnet] <Jupstar ✪> i bet it has at least 4 threads
17:00 <+bridge> [ddnet] <Jupstar ✪> a network thread doesnt run all the time
17:00 <+bridge> [ddnet] <Jupstar ✪> so it can easily share resources with other threads like sound
17:01 <+bridge> [ddnet] <heinrich5991> it has extra resource cost, but it's probably not that bad
17:01 <+bridge> [ddnet] <heinrich5991> memory, I mean
17:01 <+bridge> [ddnet] <Jupstar ✪> true
17:01 <+bridge> [ddnet] <heinrich5991> spawning threads was slow on windows
17:01 <+bridge> [ddnet] <Jupstar ✪> at least on linux stack is lazy loaded for example
17:01 <+bridge> [ddnet] <heinrich5991> but it's only a one-time cost
17:02 <+bridge> [ddnet] <Jupstar ✪> i remove 2 skins then we have traded the perf lost ^^
17:02 <+bridge> [ddnet] <Jupstar ✪> of spawning
17:02 <+bridge> [ddnet] <heinrich5991> ^^
17:02 <+bridge> [ddnet] <Learath2> Idk if it's the best idea to yield so often to the whims of the kernel scheduler
17:03 <+bridge> [ddnet] <Jupstar ✪> i dunno if u arent using win98
17:03 <+bridge> [ddnet] <Jupstar ✪> i guess they designed to be able to
17:03 <+bridge> [ddnet] <Learath2> It might not be as good for peformance as you imagine. What if we yield on the main thread, the network thread doesnt get scheduled and now we are stuck?
17:04 <+bridge> [ddnet] <Jupstar ✪> why would u even yield on the main thread
17:04 <+bridge> [ddnet] <Learath2> Don't be so sure. I read about a chrome performance issue just 3 years ago that had to do with unlucky thread priorities
17:04 <+bridge> [ddnet] <Jupstar ✪> yeah but dunno
17:04 <+bridge> [ddnet] <Jupstar ✪> chrome probs spawns 100 threads
17:04 <+bridge> [ddnet] <Learath2> Well to acquire a lock e.g.
17:05 <+bridge> [ddnet] <Jupstar ✪> i wouldnt do that tbh
17:05 <+bridge> [ddnet] <Jupstar ✪> not for network
17:05 <+bridge> [ddnet] <Jupstar ✪> not on client
17:05 <+bridge> [ddnet] <Jupstar ✪> only fetch data if there is data
17:05 <+bridge> [ddnet] <Learath2> Well the main thread does have to sync stuff at some points. Otherwise everything would be UB
17:05 <+bridge> [ddnet] <heinrich5991> have you seen the problem description of your curl-multi PR? @Learath2 `windows.h` defines `ERROR`. hence your `m_State = ERROR` fails because it's `m_State = 0`
17:06 <+bridge> [ddnet] <Jupstar ✪> yes thats true, but only if its certain there is data
17:06 <+bridge> [ddnet] <Learath2> Aha, that makes sense. I will take a look after I finish this chapter of signal analysis. I'm learning about the discrete fourier transform for the 6th time
17:07 <+bridge> [ddnet] <Jupstar ✪> e.g.
17:07 <+bridge> [ddnet] <Jupstar ✪> on network side i'd never put a select inside the mutex that the client calls
17:07 <+bridge> [ddnet] <Jupstar ✪> 
17:07 <+bridge> [ddnet] <Jupstar ✪> m.lock
17:07 <+bridge> [ddnet] <Jupstar ✪> shareddata = gotdata
17:07 <+bridge> [ddnet] <Jupstar ✪> m.unlock
17:07 <+bridge> [ddnet] <Jupstar ✪> 
17:07 <+bridge> [ddnet] <Jupstar ✪> same on client
17:07 <+bridge> [ddnet] <Jupstar ✪> if it then yields then rip but its still better than whatever the windows kernel is doing
17:08 <+bridge> [ddnet] <Learath2> Anyway, point is it's not always the best idea to spawn a billion threads. Sometimes it might make sense to hog the cpu selfishly so the kernel doesn't affect our performance
17:08 <+bridge> [ddnet] <Jupstar ✪> i'd try to never go beyond the thread count of your CPU
17:08 <+bridge> [ddnet] <Learath2> As with all things parallelism related, we probably should guide that decision solely on testing, perhaps on a handful of computers with differing configurations
17:09 <+bridge> [ddnet] <Jupstar ✪> yeah, but idc about dual cores 1990 pcs
17:09 <+bridge> [ddnet] <Jupstar ✪> if its works for the rest
17:09 <+bridge> [ddnet] <Learath2> Because theory really might not align with testing sometimes
17:09 <+bridge> [ddnet] <heinrich5991> I have like a 2007 dual core at home
17:09 <+bridge> [ddnet] <Jupstar ✪> where is your window
17:09 <+bridge> [ddnet] <Learath2> Even for quad cores. What if a background application is hogging some of the cores and windows decides we should execute on only 2 cores?
17:09 <+bridge> [ddnet] <Jupstar ✪> throw it out
17:10 <+bridge> [ddnet] <Jupstar ✪> tbh its not really the core count. old pcs werent designed to be so extremly multi threaded
17:10 <+bridge> [ddnet] <Jupstar ✪> 
17:10 <+bridge> [ddnet] <Jupstar ✪> so minimizing sync points makes sense indeed
17:10 <+bridge> [ddnet] <Jupstar ✪> and ofc all new threads create new sync points (probably, if u use them)
17:11 <+bridge> [ddnet] <Learath2> Anyway, just saying it needs testing. Spamming threads isn't always a great answer
17:12 <+bridge> [ddnet] <Jupstar ✪> well what i generally mean is basically
17:12 <+bridge> [ddnet] <Jupstar ✪> 
17:12 <+bridge> [ddnet] <Jupstar ✪> move out network, sound, gpu calls, loading stuff & if it would be ddnet then probs also some floating point physics
17:13 <+bridge> [ddnet] <Jupstar ✪> well what i generally mean is basically
17:13 <+bridge> [ddnet] <Jupstar ✪> 
17:13 <+bridge> [ddnet] <Jupstar ✪> move out network, sound, gpu calls, loading stuff & if it would not be ddnet then probs also some floating point physics
17:14 <+bridge> [ddnet] <Jupstar ✪> and funnily enough with vulkan i'd move some backend stuff back to the main thread xd
17:21 <+Ryozuki> my LUT fails to find stuff
17:21 <+Ryozuki> f
17:21 <+Ryozuki> teeman failed me
17:21 <+Ryozuki> fg
17:21 <+bridge> [ddnet] <Jupstar ✪> everytime u write over quakenet i think its chillerdragon xD
17:21 <+bridge> [ddnet] <Jupstar ✪> bcs i see the fat [quakenet] first
17:22 <+Ryozuki> xd
17:22 <+Ryozuki> this is why i like explicit things
17:22 <+Ryozuki> if(pNode->m_NumBits) is trolling me
17:28 <+bridge> [ddnet] <Learath2> Get rekt nobo, learn2read
17:29 <+bridge> [ddnet] <Jupstar ✪> @Learath2 when do you become a kernel dev finally?
17:30 <+bridge> [ddnet] <Learath2> I should find something to do in the kernel
17:30 <+bridge> [ddnet] <Learath2> Maybe contribute to the ntfs driver? 😛
17:30 <+bridge> [ddnet] <Jupstar ✪> register signals with user pointers xd
17:31 <+bridge> [ddnet] <Jupstar ✪> yes pls
17:31 <+bridge> [ddnet] <Jupstar ✪> if the ntfs is in a "cleanup" state its readonly
17:31 <+bridge> [ddnet] <Jupstar ✪> 
17:31 <+bridge> [ddnet] <Jupstar ✪> i dunno the term, but its when windows wants to check your disk
17:31 <+bridge> [ddnet] <Jupstar ✪> very annoying xD
17:31 <+bridge> [ddnet] <Learath2> Ngl, I actually am confused at how huge the ntfs implementation is, like wtf is it doing?
17:31 <+bridge> [ddnet] <Jupstar ✪> i did ntfsfix then, and windows didnt work anymore xD
17:32 <+bridge> [ddnet] <Learath2> It has enough LoC to fit ddnet in it
17:32 <+bridge> [ddnet] <Jupstar ✪> wtf
17:32 <+bridge> [ddnet] <Jupstar ✪> why even
17:32 <+bridge> [ddnet] <Jupstar ✪> its not firmware is it?
17:32 <+bridge> [ddnet] <Jupstar ✪> only the ntfs itself
17:35 <+bridge> [ddnet] <Jupstar ✪> rust ate all my disk space shit xD
17:35 <+bridge> [ddnet] <Jupstar ✪> ur fault ryo
17:35 <+bridge> [ddnet] <Learath2> It’s just supposed to be handling ntfs stuff, I honestly don’t know, maybe ntfs is insanely complex
17:36 <+Ryozuki> do cargo clean
18:02 <+bridge> [ddnet] <ReiTW> :issou: discord having issues
18:03 <+Ryozuki> my bit_count overflows
18:03 <+Ryozuki> and rust panics
18:03 <+Ryozuki> i wonder if it happens on cpp
18:03 <+Ryozuki> huffman, decompress
18:03 <+Ryozuki> doing the nearly identical code as cpp 
18:03 <+bridge> [ddnet] <ReiTW> french authority said that discord has to pay 800k€ cuz they don't respect RGPD
18:03 <+bridge> [ddnet] <ReiTW> :sue:
19:26 <+bridge> [ddnet] <Cellegen | RiH> not like it's a lot of money to discord, but it's not reasonable
19:28 <+bridge> [ddnet] <Ryozuki> Why ppl care about corpoa
19:28 <+bridge> [ddnet] <Ryozuki> Corpos
20:50 <+bridge> [ddnet] <jao's hairy kebab> eat the rich
21:11 <+bridge> [ddnet] <uwu> Because we use their products and some people work for them