00:00 < bridge> <kebscs> the pr looks good i thought its going to be more complicated
00:01 < bridge> <kebscs> for me id prefer if leader was tied to team instead a field in every player
00:01 < bridge> <kebscs> other than that is good imo
00:06 < bridge> <swarfey> yeah i had it on my mind for 2 weeks at this point. I havent had such a flawless coding session in a long time, i usually never think about code in advance
00:07 < bridge> <swarfey> true, i think it would be better like that as well
00:07 < bridge> <swarfey> ill change that
00:24 < bridge> <gorp_tw> is there really no way to determine the cause of a disconnection to be a ban other than checking for "banned" in the reason string?
00:24 < bridge> <gorp_tw> i was hoping for some int/enum thing but i guess that works
00:25 < bridge> <chillerdragon> Yes that’s the way to go
00:25 < bridge> <chillerdragon> And it works pretty well
00:25 < bridge> <gorp_tw> alright. should i be concerned about case-sensitivity? i am only connecting to ddnet servers if this helps
00:25 < bridge> <gorp_tw> i think lowercase will always catch it, since its in the first bit, before any specified reason
00:25 < bridge> <chillerdragon> I think it’s always the same message
00:26 < bridge> <chillerdragon> „You have been banned for x minutes“
00:26 < bridge> <chillerdragon> iirc I am on phone
00:26 < bridge> <gorp_tw> yeah it is that, thank you :3
00:26 < bridge> <chillerdragon> I just get banned a lot so I happen to know it well
00:26 < bridge> <gorp_tw> xD
01:07 < bridge> <swarfey> what are you trying to do?
01:16 < bridge> <gorp_tw> ```js
01:16 < bridge> <gorp_tw> const on_disconnect = (client, reason) => {
01:16 < bridge> <gorp_tw>   const ip = ip_of(client)
01:16 < bridge> <gorp_tw>   console.log(`disconnected from ${ip}: ${reason}`)
01:16 < bridge> <gorp_tw>   if (reason.includes('banned')) kicks.add(ip)
01:16 < bridge> <gorp_tw>   clients.delete(ip)
01:16 < bridge> <gorp_tw> }
01:16 < bridge> <gorp_tw> ```
01:16 < bridge> <gorp_tw> it works already but i was just wondering if there was a better way. chiller said there's not so idk
01:20 < bridge> <gorp_tw> having another sorta weird issue, im still trying to avoid checking snapshot events, but there's no way to tell if i was renamed joining a server with someone with my name already taken without the snaps?
01:21 < bridge> <gorp_tw> because client.name is still kept as 'original'
01:21 < furo> Yes, there is no kick or ban in the protocol itself. They're just different reasons sent with the control close packet.
01:22 < bridge> <gorp_tw> im also trying to figure out how the name renegotiation works, if the server knows the wanted name and doesnt require that the client re-request it
01:22 < bridge> <kebscs> if your name is displayed differently in scoreboard then you got renamed
01:22 < bridge> <gorp_tw> checking if a player is "me" requires snaps, i think
01:23 < bridge> <gorp_tw> `client.SnapshotUnpacker.OwnID` is the most light thing ive been using, but i have to compare that against the events i have
01:27 < bridge> <kebscs> no idea then if its not in game
01:31 < furo> gorp_tw: The server does not care about your wanted name (if your name was taken). DDNet client keep resending the "ChangeInfo" packet until it gets the name it wants.
01:52 < bridge> <gorp_tw> ah okay, so i will have to figure out if this lib handles it or send that
02:29 < bridge> <swarfey> it doesnt, you would have to implement that manually (i think client.game.SendChangeInfo or something something changeinfo)
02:29 < bridge> <swarfey> you would have to check through the snapshotunpacker to find your own client_info (it has the same id as client.SnapshotUnpacker.OwnID) and check the name of that
02:30 < bridge> <swarfey> it doesnt, you would have to implement that manually (client.game.ChangePlayerInfo)
04:05 < chillerbot123> Elo @teero777 I just wanted to remind you that: fix demo tests
04:36 < bridge> <HenryDarkLordOfDeath> hi
04:50 < bridge> <louis> Hi
09:29 < bridge> <gorp_tw> hm, suddenly i need NETMSGTYPE_SV_TEAMSSTATE
09:30 < bridge> <gorp_tw> that ID is unfortunately not already defined in the ts lib AFAICT
09:33 < ws-client> **<ChillerDragon>** go send pr to lib then
09:33 < bridge> <gorp_tw> yeah, im figuring out if more netmsgs are missing, then just trying to add them
09:53 < bridge> <gorp_tw> laughs in trailing tab character
09:53 < bridge> <gorp_tw> https://cdn.discordapp.com/attachments/293493549758939136/1453309474092875828/image.png?ex=694cfb6b&is=694ba9eb&hm=ebce9cc0e97123b08e6bf6d0a1946075caf9b65623aa548536a2d90e9f8874da&
10:30 < bridge> <gorp_tw> iiiiyaaaa i am scratching my head at this
10:33 < bridge> <gorp_tw> https://github.com/MilkeeyCat/ddnet/commit/3f81e3588ed84d8e7d0c550bc0e9accc03293664 so it seems like Milkeey added this to fork but it's not in upstream network.py
10:33 < bridge> <gorp_tw> but then there's definitely client handling in https://github.com/ddnet/ddnet/blob/c6be37c78228932d2673130d508301fa8730ee2c/src/game/client/gameclient.cpp#L1112
10:34 < ws-client> **<ChillerDragon>** how did you end up at milkeeys fork??
10:34 < bridge> <gorp_tw> i cast a wide net to try to find any information xD
10:35 < bridge> <gorp_tw> just what popped up, this was in January
10:35 < ws-client> **<ChillerDragon>** speaking of milkeey @milkeeycat sos
10:35 < ws-client> **<ChillerDragon>** https://github.com/MilkeeyCat/ddnet_protocol/blob/2e51204054f09e159b4db054f16f87f4d425e526/include/ddnet_protocol/packer.h#L70
10:35 < ws-client> **<ChillerDragon>** i ran into a circular dependency issue
10:35 < ws-client> **<ChillerDragon>** the packer depends on `DDNetMessageKind` which pulls in literally everything as a dependency
10:36 < ws-client> **<ChillerDragon>** imo the packer should not depend on the entire protocol it should just pack
10:36 < ws-client> **<ChillerDragon>** idk wat to do
10:36 < ws-client> **<ChillerDragon>** i guess ill move the message kind enum to the packer 🤷
10:36 < bridge> <heinrich5991> that doesn't sound like a circular dependency issue? it's just a "I wish it had less dependencies"?
10:37 < ws-client> **<ChillerDragon>** oh yea
10:37 < ws-client> **<ChillerDragon>** but now it became one for me
10:37 < bridge> <heinrich5991> that library is a bit annoying for using the `ddnet_` prefix in functions
10:38 < ws-client> **<ChillerDragon>** annoying for who?
10:38 < bridge> <heinrich5991> that should be reserved for ddnet code ^^
10:38 < ws-client> **<ChillerDragon>** ah i see
10:38 < ws-client> **<ChillerDragon>** but ddnet doesnt use it right?
10:38 < bridge> <heinrich5991> maybe use something like ddnetp or so
10:38 < bridge> <heinrich5991> not right now, no
10:38 < ws-client> **<ChillerDragon>** we can change it as soon as ddnet uses it i guess
10:39 < ws-client> **<ChillerDragon>** otherwise we have an longer uglier prefix without even solving a real problem
10:39 < ws-client> **<ChillerDragon>** but its milkeeys call
10:39 < bridge> <heinrich5991> I guess I'll open an issue
10:39 < ws-client> **<ChillerDragon>** <:poggers2:1008007455936094328>
10:39 < bridge> <gorp_tw> what was the motivation for NetMessageEx? not sure if i need to make special considerations about these
10:39 < ws-client> **<ChillerDragon>** ddnet_protocol christmas activity
10:40 < ws-client> **<ChillerDragon>** @gorp_tw ddnet extension basically
10:40 < bridge> <gorp_tw> tslib does handle UUIDManager
10:40 < ws-client> **<ChillerDragon>** ddnet adds messages in a way to not conflict with teeworlds
10:40 < bridge> <Assa> Ex is alsways extension, there is also NetObjectEx
10:40 < ws-client> **<ChillerDragon>** you dont need to worry about it @gorp_tw 
10:40 < ws-client> **<ChillerDragon>** blazingly typescript is handling it all for u
10:40 < bridge> <gorp_tw> alright. im not even sure if sv_teamsstate is what i need really... im kinda tired and need sleep
10:40 < ws-client> **<ChillerDragon>** only thing that could be interesting for you is that non ddnet servers dont send it
10:40 < bridge> <gorp_tw> but i do need to figure out ddrace teams
10:41 < bridge> <Assa> the teams are inside the ddnetplayer as far as I remember
10:41 < bridge> <Assa> like they are not a seperate netmessage, just an ID per player
10:42 < bridge> <milkeeycat> > <ChillerDragon> i guess ill move the message kind enum to the packer 🤷
10:42 < bridge> <milkeeycat> does that mean I have to include packer in `chunk.h` to have access to `DDNetMessageKind`? xd
10:42 < bridge> <heinrich5991> it seems they're in `Sv_TeamsState` message
10:42 < bridge> <heinrich5991> which is bad an there's probably an issue for that
10:42 < ws-client> **<ChillerDragon>** @milkeeycat yes but better than the other way around imo
10:42 < ws-client> **<ChillerDragon>** better everyone including the packer than the packer including everyone
10:42 < bridge> <Assa> 🤔 maybe I also don't understand how teams are handled on the network side
10:43 < ws-client> **<ChillerDragon>** it solved the compilation issue for me and i feel like it will be easier to work with in the future @milkeeycat 
10:43 < ws-client> **<ChillerDragon>** its just a bit odd to have all the message names in the packer header 
10:43 < ws-client> **<ChillerDragon>** but eh ... idk how to avoid that
10:44 < bridge> <heinrich5991> I don't see it in the `DDNetCharacter`/`DDNetPlayer`
10:44 < bridge> <gorp_tw> yeah that was what i gathered, but having a tough time finding exactly where this is
10:45 < bridge> <gorp_tw> my thought was Character -> CharacterCore
10:45 < bridge> <gorp_tw> since its not part of the outer fields in this lib
10:45 < bridge> <Assa> the scoreboard uses m_Team, I believe it was from the ClientData, but I'd need to look it up
10:45 < bridge> <gorp_tw> all other references to teams in this lib are 0 for ddrace (vanilla teams)
10:46 < bridge> <Assa> `CNetObj_PlayerInfo` @heinrich5991
10:47 < bridge> <heinrich5991> I don't see it in there, either
10:47 < bridge> <Assa> contains m_Team
10:47 < bridge> <heinrich5991> or are we not talking about ddnet teams?
10:47 < bridge> <gorp_tw> that is the vanilla team, IIRC
10:47 < ws-client> **<ChillerDragon>** its a vanilla object so its a vanilla team
10:47 < bridge> <gorp_tw> i verified this by changing teams live and inspecting the net change
10:47 < bridge> <Assa> oh huh
10:47 < bridge> <gorp_tw> yeah so i have no idea where ddrace team anything is XD
10:48 < bridge> <Assa> oh yes it is, whater CTeamsCore does
10:48 < bridge> <heinrich5991> https://github.com/ddnet/ddnet/issues/3795
10:48 < bridge> <heinrich5991> I think it's just the message you found earlier, @gorp_tw
10:49 < bridge> <heinrich5991> `Sv_TeamsState`
10:49 < bridge> <heinrich5991> someone™ should put that into the snapshot instead
10:49 < bridge> <heinrich5991> because it breaks demo playback otherwise
10:49 < bridge> <gorp_tw> yeah it had data and now it does not
10:49 < bridge> <Assa> `MsgId == NETMSGTYPE_SV_TEAMSSTATE || MsgId == NETMSGTYPE_SV_TEAMSSTATELEGACY)`
10:49 < bridge> <gorp_tw> according to network.py at least
10:49 < bridge> <heinrich5991> yes, network.py is incorrect there
10:49 < bridge> <heinrich5991> you need to manually unpack the 64 twints
10:50 < bridge> <gorp_tw> yeah sorry, ive just been leaning on network.py as a quicker reference
10:50 < bridge> <gorp_tw> cool beans
10:50 < bridge> <gorp_tw> but it is correct that it is int[64]
10:51 < bridge> <heinrich5991> apparently `int[128]`
10:51 < bridge> <heinrich5991> https://github.com/heinrich5991/libtw2/blob/763a1d9782b3c12730a23f803f0bc4f938941775/gamenet/generate/spec/ddnet-19.1.json#L721-L733
10:52 < bridge> <gorp_tw> re: `|| MsgId == NETMSGTYPE_SV_TEAMSSTATELEGACY)`, is this given as 64?
10:52 < bridge> <gorp_tw> or what is the difference with `LEGACY`?
10:53 < ws-client> **<ChillerDragon>** just ignore legacy
10:53 < ws-client> **<ChillerDragon>** its old 
10:53 < ws-client> **<ChillerDragon>** ..
10:53 < bridge> <gorp_tw> if im PRing this to a general library, i should probably consider it
10:53 < ws-client> **<ChillerDragon>** a
10:53 < bridge> <gorp_tw> like you told me to go do
10:53 < bridge> <heinrich5991> the difference is that `SV_TEAMSSTATELEGACY` isn't a extended message
10:54 < bridge> <Assa> I guess it contains only 16 integers if I understand that correctly oO
10:54 < bridge> <heinrich5991> and `SV_TEAMSSTATELEGACY` isn't sent anymore by ddnet servers to new clients
10:54 < bridge> <heinrich5991> the difference is that `SV_TEAMSSTATELEGACY` isn't an extended message
10:54 < ws-client> **<ChillerDragon>** just dont implement anything legacy helps us to move forward
10:54 < bridge> <gorp_tw> hm, so they still unpack the same
10:54 < bridge> <gorp_tw> but one is namespaced
10:54 < ws-client> **<ChillerDragon>** speaking of
10:54 < ws-client> **<ChillerDragon>** btw that js lib is still 0.6
10:54 < bridge> <gorp_tw> yes i know
10:54 < ws-client> **<ChillerDragon>** you should consider sending a pr to use 0.7 technology instead
10:55 < ws-client> **<ChillerDragon>** hrhrhrhhr
10:55 < bridge> <gorp_tw> i am just a dog
10:55 < bridge> <gorp_tw> i dont know things
10:55 < ws-client> **<ChillerDragon>** no u pro
10:55 < bridge> <gorp_tw> i dont even know how to write CPP and i am translating CPP into TS
10:56 < bridge> <heinrich5991> I wouldn't use the 0.7 protocol, it's essentially dead
10:56 < bridge> <heinrich5991> the only thing keeping it alive is servers and clients _also_ supporting it
10:56 < bridge> <gorp_tw> it does seem like basically everything uses 0.6 and extensions
10:56 < bridge> <gorp_tw> so i didnt bother looking at any 0.7
10:58 < ws-client> **<ChillerDragon>** you cant even play on recent vanilla servers with the js lib -.-
10:58 < ws-client> **<ChillerDragon>** but you could join ddnet servers with 0.7
10:58 < ws-client> **<ChillerDragon>** but who am i to judge
10:58 < ws-client> **<ChillerDragon>** i am literally writing a 0.6 snapshot parser right now :D 
11:00 < bridge> <heinrich5991> I think the low-level snapshot format didn't change between 0.6 and 0.7
11:05 < ws-client> **<ChillerDragon>** not much ye
11:05 < bridge> <heinrich5991> at all?
11:06 < ws-client> **<ChillerDragon>** possibly at all yes
11:06 < bridge> <heinrich5991> ok, was just wondering whether you knew more
11:07 < ws-client> **<ChillerDragon>** i recently implemented both in python but i already forgot -.
11:07 < bridge> <heinrich5991> I think my libtw2 parser didn't have to change between these versiosn
11:07 < ws-client> **<ChillerDragon>** 0.7 just has the race edge case
11:07 < ws-client> **<ChillerDragon>** GAME_DATA_RACE, PLAYER_INFO_RACE
11:08 < ws-client> **<ChillerDragon>** that were added after the 0.7 release
11:08 < ws-client> **<ChillerDragon>** so they send the size
11:08 < bridge> <remakepower> I wonder that
11:08 < bridge> <heinrich5991> ah right, you need different default object sizes
11:08 < bridge> <heinrich5991> between versions
11:08 < bridge> <gorp_tw> ```js
11:08 < bridge> <gorp_tw> } else if (chunk.msgid == NETMSG.Game.SV_TEAMSSTATE) {
11:08 < ws-client> **<ChillerDragon>** yea that too
11:08 < bridge> <gorp_tw>   let unpacker = new MsgUnpacker(chunk.raw);
11:08 < bridge> <gorp_tw>   const teams = Array.from({ length: 64 }).map(() => unpacker.unpackInt())
11:08 < bridge> <gorp_tw>   this.emit("teams", teams) 
11:08 < bridge> <gorp_tw> }
11:08 < bridge> <gorp_tw> ```
11:08 < bridge> <gorp_tw> i am tired but i think this is right
11:08 < bridge> <gorp_tw> gn
11:08 < bridge> <heinrich5991> good night 🙂
11:08 < ws-client> **<ChillerDragon>** ???
11:08 < ws-client> **<ChillerDragon>** bro its 11am
11:09 < ws-client> **<ChillerDragon>** ah u told it to him xd
11:09 < bridge> <remakepower> ```
11:09 < bridge> <remakepower>             // create delta
11:09 < bridge> <remakepower>             m_SnapshotDelta.SetStaticsize(protocol7::NETEVENTTYPE_SOUNDWORLD, m_aClients[i].m_Sixup);
11:09 < bridge> <remakepower>             m_SnapshotDelta.SetStaticsize(protocol7::NETEVENTTYPE_DAMAGE, m_aClients[i].m_Sixup);
11:09 < bridge> <remakepower> ```
11:09 < bridge> <remakepower> what is this magic?
11:09 < ws-client> **<ChillerDragon>** thats basically what heino said
11:09 < ws-client> **<ChillerDragon>** different item sizes for 0.6 and 0.7
11:09 < ws-client> **<ChillerDragon>** so it adjusts the sizes based on who receives the snap
11:10 < ws-client> **<ChillerDragon>** its a bit funny that it passes a bool as size tho xd
11:10 < ws-client> **<ChillerDragon>** i remember looking into that once i forgot my findings already
11:11 < bridge> <remakepower> That's was what I wanted to know
11:11 < bridge> <remakepower> why it passes a boolean??
11:11 < bridge> <remakepower> How could it works?
11:11 < ws-client> **<ChillerDragon>** well its just 1 and 0 as size then :D 
11:12 < bridge> <heinrich5991> looks like a bug
11:13 < ws-client> **<ChillerDragon>** setting it for 0.6 to 0 doesnt really matter
11:13 < ws-client> **<ChillerDragon>** because the type ids are not used in 0.6
11:13 < ws-client> **<ChillerDragon>** the highest snap type id in 0.6 is `20 event_damage_indicator`
11:14 < ws-client> **<ChillerDragon>** and protocol7 sound world and damage are 21 and 22
11:14 < ws-client> **<ChillerDragon>** but their size is not 1
11:14 < ws-client> **<ChillerDragon>** i guess the size doesnt matter at all because its not even used i assume
11:15 < ws-client> **<ChillerDragon>** wait it sets the 0.6 sizes :D
11:15 < ws-client> **<ChillerDragon>** lel
11:15 < ws-client> **<ChillerDragon>** ok this code does nothing
11:15 < bridge> <Assa> :thonk:
11:15 < ws-client> **<ChillerDragon>** it sets a for 0.6 out of range value only for 0.6
11:16 < ws-client> **<ChillerDragon>** i am 90% sure that deleting this code breaks nothing
11:16 < ws-client> **<ChillerDragon>** but cba to test it
11:16 < bridge> <remakepower> No
11:17 < bridge> <remakepower> That's a part of sixup.
11:17 < bridge> <remakepower> You can't delete it
11:17 < bridge> <remakepower> I have tested if we removed it 🙁
11:18 < bridge> <remakepower> And then I found the 0.7 clients wouldn't get any CNetObj_SoundWorld.
11:18 < ws-client> **<ChillerDragon>** well then i dont get it :D 
11:18 < ws-client> **<ChillerDragon>** 0.7 should not depend on m_aItemSizes if there is also m_aItemSizes7
11:19 < bridge> <remakepower> m_aItemSizes7 is used for the client
11:19 < ws-client> **<ChillerDragon>** aaaa
11:19 < bridge> <remakepower> m_aItemSizes is used for the server sixup
11:19 < bridge> <remakepower> idk why
11:19 < ws-client> **<ChillerDragon>** i see
11:19 < ws-client> **<ChillerDragon>** so passing the bool is a bit funny
11:20 < ws-client> **<ChillerDragon>** and doing it on tick too
11:20 < ws-client> **<ChillerDragon>** can probably be done once on startup
11:20 < ws-client> **<ChillerDragon>** i assume this is the if statement that uses the value https://github.com/ddnet/ddnet/blob/c6be37c78228932d2673130d508301fa8730ee2c/src/engine/shared/snapshot.cpp#L338
11:21 < bridge> <remakepower> oh
11:21 < bridge> <remakepower> Oh I got it.
11:22 < bridge> <remakepower> A comment from vanilla 0.7 code
11:22 < bridge> <remakepower> ```
11:22 < bridge> <remakepower>     // HACK: only set static size for items, which were available in the first 0.7 release
11:22 < bridge> <remakepower>     // so new items don't break the snapshot delta
11:22 < bridge> <remakepower> ```
11:22 < ws-client> **<ChillerDragon>** ye thats the thing i mentioned earlier
11:22 < ws-client> **<ChillerDragon>** thats four the race stuff tho right?
11:22 < ws-client> **<ChillerDragon>** not sound world and damage
11:23 < bridge> <remakepower> I think it was here:
11:23 < bridge> <remakepower> ```
11:23 < bridge> <remakepower> const bool IncludeSize = pCurItem->Type() >= MAX_NETOBJSIZES || !m_aItemSizes[pCurItem->Type()];
11:23 < bridge> <remakepower> ```
11:23 < bridge> <kebscs> Merry Christmas 🎄 🎁
11:24 < bridge> <remakepower> Oh
11:24 < bridge> <remakepower> The client must got the size of CNetObj_SoundWorld
11:24 < bridge> <remakepower> in the delta pack
11:25 < bridge> <remakepower> https://cdn.discordapp.com/attachments/293493549758939136/1453332736197656668/image.png?ex=694d1115&is=694bbf95&hm=b8260ce5a68de0f42dfbd8b920205105cc27199076320df3884bb983c3d83ae3&
11:26 < bridge> <Assa> @kebscs can we close #10505 ?
11:26 < bridge> <DDNet> https://github.com/ddnet/ddnet/pull/10505
11:26 < bridge> <remakepower> Yeah
11:26 < bridge> <remakepower> That was it
11:26 < bridge> <remakepower> You must send the size of NetObj in the snap delta.
11:26 < bridge> <remakepower> ```
11:26 < bridge> <remakepower> 
11:26 < bridge> <remakepower>         int ItemSize;
11:26 < bridge> <remakepower>         const short *pItemSizes = Sixup ? m_aItemSizes7 : m_aItemSizes;
11:26 < bridge> <remakepower>         if(Type < MAX_NETOBJSIZES && pItemSizes[Type])
11:26 < bridge> <remakepower>             ItemSize = pItemSizes[Type];
11:27 < bridge> <remakepower>         else
11:27 < bridge> <remakepower>         {
11:27 < bridge> <remakepower>             if(pData + 1 > pEnd)
11:27 < bridge> <remakepower>                 return -103;
11:27 < bridge> <remakepower>             if(*pData < 0 || (size_t)*pData > std::numeric_limits<int32_t>::max() / sizeof(int32_t))
11:27 < bridge> <remakepower>                 return -204;
11:27 < bridge> <remakepower>             ItemSize = (*pData++) * sizeof(int32_t);
11:27 < bridge> <remakepower>         }
11:27 < bridge> <remakepower> ```
11:27 < bridge> <kebscs> If you have a better solution
11:28 < bridge> <remakepower> Wait a minute
11:28 < bridge> <remakepower> Oh
11:29 < bridge> <remakepower> You shouldn't pack the size of NetObj in the snap delta(
11:29 < bridge> <remakepower> :thonk:
11:30 < bridge> <remakepower> If you send the size of CNetObj_SoundWorld, the client wouldn't trigger 
11:30 < bridge> <remakepower> ```
11:30 < bridge> <remakepower> ItemSize = (*pData++) * sizeof(int32_t);
11:30 < bridge> <remakepower> ```
11:30 < bridge> <remakepower> Then it would unpack failed.
11:30 < bridge> <remakepower> :frozen:
11:30 < bridge> <remakepower> Teeworlds magic.
11:36 < bridge> <gorp_tw> @swarfey i punted this down the road a bit but i think i made a mistake somewhere adding the new types to client.ts: https://github.com/kaitlynia/teeworlds-library-ts/blob/d6a0d0e5db279e87449b2de0b08e48a15c4e268b/lib/client.ts#L27C509-L27C562
11:36 < bridge> <gorp_tw> (ie. `"SV_TEAMS_STATE", "CL_SHOW_OTHERS_LEGACY"` were already there but they may not be in the right place?)
11:36 < bridge> <gorp_tw> if you're open to review i appreciate it ^^
11:36 < bridge> <gorp_tw> gn
11:42 < bridge> <teero777> LOL gemini 3 pulls up ddnet testing logs xD
11:43 < bridge> <teero777> https://ddnet.org/testlogs/show/Bouncy#:~:text=yea,01%2F2024%208%3A50%20PM
11:43 < bridge> <teero777> https://cdn.discordapp.com/attachments/293493549758939136/1453337207703212198/image.png?ex=694d1540&is=694bc3c0&hm=8dc7c848cb243242d5521ba3dbdbc82cb6b607f7e739e98ad2c42701f6a52405&
11:43 < bridge> <teero777> XDDDDDD
11:43 < bridge> <alw5> $decline
11:43 < bridge> <DDNet> This command was not found.
11:49 < ws-client> **<ChillerDragon>** @teero777 is that public info? or did discord sell the data?
11:49 < bridge> <teero777> the logs are public
11:50 < bridge> <teero777> no idea how it has that link though
11:51 < bridge> <alw5> google scraping
11:51 < bridge> <remakepower> I wonder that
11:51 < bridge> <remakepower> Do we have any test on big endian?
11:51 < bridge> <teero777> i guess
11:52 < bridge> <Assa> the others suggested putting it into a snap message, that's why I asking, isn't the current PR fundamentally flawed?
11:52 < bridge> <alw5> gemini is made by google right?
11:52 < bridge> <teero777> yea,
11:52 < bridge> <teero777> yea
11:52 < bridge> <alw5> yea google prolly has the page indexed
11:52 < bridge> <alw5> and just scraped everything
11:53 < ws-client> **<ChillerDragon>** @remakepower in ddnet yes
11:53 < ws-client> **<ChillerDragon>** search for ARCH_ENDIAN
11:53 < bridge> <remakepower> I means test
11:53 < ws-client> **<ChillerDragon>** for example here https://github.com/ddnet/ddnet/blob/c6be37c78228932d2673130d508301fa8730ee2c/src/engine/shared/datafile.cpp#L1064-L1081
11:53 < ws-client> **<ChillerDragon>** oh tests
11:53 < ws-client> **<ChillerDragon>** not sure 
11:53 < bridge> <remakepower> I knowed that we have ARCH_ENDIAN from vanilla teeworlds
11:54 < bridge> <louis> ddnet.org/testlogs
11:54 < bridge> <louis> But discord prolly selling data too anyways
11:54 < bridge> <remakepower> But I found we didnt't upgrade endian-related code to C++20 std::endian
12:08 < bridge> <kebscs> It works fine
12:08 < bridge> <kebscs> And is full client side
12:11 < bridge> <totar> This is not a duplicate imo
12:15 < bridge> <louis> yeah those arent dupes. the two listed in it are dupes though
12:17 < bridge> <kebscs> Isn't it better to close old issues for new ones
12:17 < bridge> <kebscs> For visibility
12:20 < bridge> <totar> Entity automapper is probably the next thing ill work on when I do more new tclient features
12:21 < bridge> <remakepower> Entity automapper?
12:22 < bridge> <totar> Do you know what automapper is?
12:22 < bridge> <totar> For editor
12:22 < bridge> <remakepower> I knowed automapper and auto rules
12:22 < bridge> <remakepower> but I didn't understand what is entity automapper
12:23 < bridge> <totar> Same idea for entities?
12:23 < bridge> <remakepower> entities layer?
12:23 < bridge> <totar> Yes?
12:24 < bridge> <totar> It puts design on entities
12:25 < bridge> <remakepower> Could you give me a example?
12:26 < bridge> <remakepower> I could't imagine what it is used for.
12:26 < bridge> <totar> It doesn't exist yet
12:26 < bridge> <remakepower> I couldn't imagine what it is used for.
12:26 < bridge> <remakepower> Yeah
12:27 < bridge> <remakepower> I mean, what will it be used for?
12:28 < bridge> <remakepower> :thonk:
12:28 < bridge> <totar> To put design on entities :justatest:
12:29 < bridge> <louis> So we can fully remove all design in 2026 and have everyone just play w their own designs
12:30 < bridge> <totar> Most people already live in this reality
12:30 < bridge> <remakepower> Oh
12:31 < bridge> <gorp> tc outlines with extra steps
12:31 < bridge> <remakepower> :thonk:
12:32 < bridge> <gorp> yeah im not asleep yet, smack me with a fucking 2x4 board
12:32 < bridge> <remakepower> So
12:33 < bridge> <remakepower> the normal automapper
12:33 < bridge> <louis> yeah i wonder if anyone will actually use entiry automapper other than to remove the inner lines between blocks
12:33 < bridge> <remakepower> is for putting tiles.
12:34 < bridge> <remakepower> And
12:35 < bridge> <remakepower> sorry I still didn't understand what entity automapper is.
12:35 < bridge> <remakepower> :frozen:
12:36 < bridge> <gorp> entity automapper is a bad name for it anyway. it implies it's mapping something in the file itself. just imagine you're using entities only and your game just "hallucinates" some design on top that isn't part of the map. thats the idea (I think)
12:37 < bridge> <gorp> its possible I'm misunderstanding it too tho
12:38 < bridge> <remakepower> I have thought that entity automapper is a formatter.
12:38 < bridge> <remakepower> which could clean the rotation of your game tiles.
12:38 < bridge> <remakepower> But it seems not.
12:39 < bridge> <remakepower> However, I still didn't understand 🙁
12:39 < bridge> <gorp> i just have to assume tater doesn't mean the editor cus that already exists
12:39 < bridge> <remakepower> I don't know why that
12:40 < bridge> <remakepower> game layer, tele layer, switch layer, and front layer are entities layers.
12:40 < bridge> <remakepower> I always think entities layers is a layer contains hundreds of CEntity.
12:41 < bridge> <remakepower> :frozen:
12:42 < bridge> <remakepower> they are not entities.
12:42 < bridge> <remakepower> they are just tiles.
12:42 < bridge> <remakepower> sets of tiles.
12:42 < bridge> <remakepower> :thonk:
12:44 < bridge> <gorp> pretty good point. too bad they called design tiles already
12:45 < bridge> <remakepower> Also I don't know why we have 
12:45 < bridge> <remakepower> ```
12:45 < bridge> <remakepower>     LAYERTYPE_FRONT,
12:45 < bridge> <remakepower>     LAYERTYPE_TELE,
12:45 < bridge> <remakepower>     LAYERTYPE_SPEEDUP,
12:45 < bridge> <remakepower>     LAYERTYPE_SWITCH,
12:45 < bridge> <remakepower>     LAYERTYPE_TUNE,
12:45 < bridge> <remakepower> ```
12:46 < bridge> <remakepower> And `LAYERTYPE_GAME` is not unused
12:46 < bridge> <remakepower> but we have a comment:
12:46 < bridge> <remakepower> `    LAYERTYPE_GAME, // unused`
12:46 < bridge> <remakepower> (it's unused in the vanilla teeworlds)
12:47 < bridge> <remakepower> So we just use that `LAYERTYPE`s for our editor.
12:48 < bridge> <gorp> you should be able to specify any number of layers. and smaller layers (like speedup, tele, and tune) should have been part of the same "misc" grid. but meh
12:49 < bridge> <remakepower> And we have 
12:50 < bridge> <remakepower> ```
12:50 < bridge> <remakepower> 
12:50 < bridge> <remakepower>     LAYERTYPE_SOUNDS_DEPRECATED, // deprecated! do not use this, this is just for compatibility reasons
12:50 < bridge> <remakepower>     LAYERTYPE_SOUNDS,
12:50 < bridge> <remakepower> ```
12:51 < bridge> <remakepower> And those types are LAYERTYPE_TILES in the map file.
12:54 < bridge> <remakepower> 3 years ago, I didn't know why we have 
12:54 < bridge> <remakepower> ```
12:54 < bridge> <remakepower>     int m_Tele;
12:54 < bridge> <remakepower>     int m_Speedup;
12:54 < bridge> <remakepower>     int m_Front;
12:54 < bridge> <remakepower>     int m_Switch;
12:54 < bridge> <remakepower>     int m_Tune;
12:54 < bridge> <remakepower> ```
12:54 < bridge> <remakepower> today, I still don't know why 🙁
12:55 < bridge> <remakepower> I think we can use `m_Data` instead, which is only used by GameLayer.
12:56 < bridge> <remakepower> But we need to keep back compat now :3
13:04 < bridge> <Assa> because in teeworlds there was only a game layer and everything was layertype tiles or layertype quads
13:04 < bridge> <remakepower> no
13:04 < bridge> <remakepower> Gamelayer is LAYERTYPE_TILE, too
13:04 < bridge> <remakepower> Gamelayer is LAYERTYPE_TILES, too
13:04 < bridge> <Assa> read my message again
13:05 < bridge> <remakepower> Oh
13:05 < bridge> <remakepower> Yeah
13:05 < bridge> <remakepower> You are right.
13:05 < bridge> <remakepower> No
13:05 < bridge> <remakepower> Wait
13:05 < bridge> <remakepower> Read my message again :3
13:06 < bridge> <remakepower> What I said is `LAYERTYPE_GAME is not unused`
13:06 < bridge> <Assa> You must know, some layers like speedup or switch have bigger tiles, and thus another memory layout
13:07 < bridge> <remakepower> Hm
13:07 < bridge> <remakepower> Yes
13:07 < bridge> <remakepower> And then?
13:08 < bridge> <remakepower> Oh
13:08 < bridge> <Assa> then you can read the map format for this layers idk what your goal is
13:08 < bridge> <remakepower> You means we need to have a backcompat with vanilla clients
13:09 < bridge> <Assa> yes
13:09 < bridge> <remakepower> :thonk:
13:10 < bridge> <Assa> I am just trying to explain why things are how they are
13:10 < bridge> <remakepower> I see
13:10 < bridge> <remakepower> ```
13:10 < bridge> <remakepower> 
13:10 < bridge> <remakepower>                     CTile *pEmptyTiles = (CTile *)calloc((size_t)pLayerTiles->m_Width * pLayerTiles->m_Height, sizeof(CTile));
13:10 < bridge> <remakepower>                     mem_zero(pEmptyTiles, (size_t)pLayerTiles->m_Width * pLayerTiles->m_Height * sizeof(CTile));
13:10 < bridge> <remakepower>                     Item.m_Data = Writer.AddData((size_t)pLayerTiles->m_Width * pLayerTiles->m_Height * sizeof(CTile), pEmptyTiles);
13:10 < bridge> <remakepower>                     free(pEmptyTiles);
13:10 < bridge> <remakepower> ```
13:11 < bridge> <Assa> yes, a CSpeedupTile is bigger for example
13:11 < bridge> <Assa> so you have more bytes
13:12 < bridge> <remakepower> :frozen:
13:47 < bridge> <swarfey> "SV_TEAMS_STATE", "CL_SHOW_OTHERS_LEGACY" are both messages that have been deprecated and moved to NetMessageEx later on
13:48 < bridge> <swarfey> i think my library was created at times where they were not deprecated yet, which is why SV_TEAMS_STATE doesnt have legacy behind it yet. in official ddnet they are called legacy now as well:
13:49 < bridge> <swarfey> https://cdn.discordapp.com/attachments/293493549758939136/1453368931564654672/image.png?ex=694d32cb&is=694be14b&hm=21a219d07c5d118a9007e57aac32a9ecc47a15ac94b863356823151c5ea2d516&
13:51 < bridge> <swarfey> for netmessages with UUID's (thats all NetMessageEx) you would need to register the uuids here: https://github.com/kaitlynia/teeworlds-library-ts/blob/d6a0d0e5db279e87449b2de0b08e48a15c4e268b/lib/client.ts#L207
13:52 < bridge> <swarfey> something like this `        this.UUIDManager.RegisterName("sv-vote-option-group-end@netmsg.ddnet.org", NETMSG.System.svvoteoptiongroupend);` should work for the messages to be parsed correctly by the library
13:55 < bridge> <swarfey> the messageTypes array that you changed in your version is only used for normal NetMessages without UUIDs. i dont think its actually used anywhere but to make logs look nicer (so you dont have to double check which message is which with the enums)
13:57 < bridge> <swarfey> i think my library was created at times where they were not deprecated yet, which is why SV_TEAMS_STATE doesnt have legacy behind it yet. in official ddnet they are called legacy now as well. but the message id's are still reserved for these deprecated messages, so they are at the correct spot:
14:34 < bridge> <byfox> ```
14:34 < bridge> <byfox> if(g_Config.m_SvRegisterCommunityToken[0])
14:35 < bridge> <byfox> {
14:35 < bridge> <byfox>     if(g_Config.m_SvFlag != -1)
14:35 < bridge> <byfox>     {
14:35 < bridge> <byfox>         JsonWriter.WriteAttribute("country");
14:35 < bridge> <byfox>         JsonWriter.WriteIntValue(g_Config.m_SvFlag); // ISO 3166-1 numeric
14:35 < bridge> <byfox>     }
14:35 < bridge> <byfox> }
14:35 < bridge> <byfox> ```
14:35 < bridge> <byfox> I don't understand why there is a check for sv_register_community_token here?
14:35 < bridge> <byfox> ```cpp
14:35 < bridge> <byfox> if(g_Config.m_SvRegisterCommunityToken[0])
14:35 < bridge> <byfox> {
14:35 < bridge> <byfox>     if(g_Config.m_SvFlag != -1)
14:35 < bridge> <byfox>     {
14:35 < bridge> <byfox>         JsonWriter.WriteAttribute("country");
14:35 < bridge> <byfox>         JsonWriter.WriteIntValue(g_Config.m_SvFlag); // ISO 3166-1 numeric
14:35 < bridge> <byfox>     }
14:35 < bridge> <byfox> }
14:35 < bridge> <byfox> ```
14:35 < bridge> <byfox> I don't understand why there is a check for sv_register_community_token here?
15:18 < bridge> <teero777> :frozen:
15:18 < bridge> <teero777> https://cdn.discordapp.com/attachments/293493549758939136/1453391281253388391/image.png?ex=694d479c&is=694bf61c&hm=af549463191576c2060bb0a8715b650ce156e8b67875767f3fd76fab93089549&
15:55 < bridge> <melon> STOP FINDING THESE THINGS
15:55 < bridge> <melon> actively ruining my christmas spirit ong
15:57 < bridge> <teero777> idk, big tech just doesn't pay attention to detail
15:57 < bridge> <teero777> https://cdn.discordapp.com/attachments/293493549758939136/1453401193543110717/image.png?ex=694d50d7&is=694bff57&hm=a9b77b4c27d6c8627e3570b58148c5332ff6e5d3233b95f06758cf32f5360cae&
15:57 < bridge> <melon> actually you know what
15:57 < bridge> <melon> fuck u
15:57 < bridge> <melon> https://cdn.discordapp.com/attachments/293493549758939136/1453401210034851981/image.png?ex=694d50db&is=694bff5b&hm=9ec9db8aef75ecbe35e11b357c7ab3653329f900ba2962f2998d8daa88d4b5ba&
15:57 < bridge> <teero777> XD
16:00 < bridge> <learath2> I have this theory that nobody takes pride in their work anymore. I could not possibly sleep if my work looked like that
16:01 < bridge> <teero777> same
16:02 < bridge> <teero777> im currently debugging my particle system for frametee and there is a bug that is 99% not noticeable where when reversing in slowmo and looking at ninja powerup shine particles they sometimes dissapear. im not gonna push a release with that lol
16:10 < bridge> <alximik0178> Hi, I was banned for accidentally using a VPN. Can you tell me how to fix this?
16:11 < bridge> <alw5> #✉-create-a-ticket
16:11 < bridge> <alw5> admin-mail i think?
16:11 < bridge> <alw5> admin mail i think?
16:11 < bridge> <alw5> ban apeal ticket
16:14 < bridge> <learath2> You can just turn off the VPN and you'll be fine, those bans are for the ip, nothing else
16:15 < bridge> <alw5> oh i mis understood the question
16:16 < bridge> <alximik0178> I tried to turn off the VPN and log into the server, but it didn't help.
16:32 < bridge> <alximik0178> https://cdn.discordapp.com/attachments/293493549758939136/1453410085761187901/20251224202444_1.jpg?ex=694d591f&is=694c079f&hm=f9f90cb004a4359e2c2db14ad9b1f0351bf92e280df7c711640f59c815988b63&
16:35 < bridge> <kebscs> https://ddnet.org/vpn/
16:42 < bridge> <alximik0178> is this ban forever?
16:46 < bridge> <robyt3> VPNs are generally banned. Disable your VPN then you are not banned anymore.
17:07 < bridge> <milkeeycat> that's why you're jobless :santatrollet:
17:47 < bridge> <milkeeycat> chillerdragon: are you here?
18:21 < bridge> <dilmaev> what is that?
18:21 < bridge> <dilmaev> https://cdn.discordapp.com/attachments/293493549758939136/1453437450255990988/Base_Profile_Screenshot_2025.12.24_-_20.20.10.63.png?ex=694d729b&is=694c211b&hm=3f340f992ec3ec3dbad9b869fe4ee0888b4a9aba657994f69dde7476203b9480&
18:21 < bridge> <dilmaev> i play with steam version every time
18:23 < bridge> <dilmaev> i play with steam version all time
18:26 < bridge> <alw5> #
18:26 < bridge> <alw5> #✉-create-a-ticket
18:26 < bridge> <alw5> ban apeal
18:26 < bridge> <dilmaev> thanks
20:59 < bridge> <gorp> good mornyan just woke up
21:00 < bridge> <gorp> thanks Swarfy ill finish the PR today
21:21 < bridge> <gorp_tw> this could be a CSS rendering bug technically. this is an issue on random browsers, when it really SHOULD appear flush but there's a rounding issue with the pixels.
21:22 < bridge> <gorp_tw> i wish they could all agree about how to treat rounding
21:22 < bridge> <gorp_tw> it's also a problem with relative units i think
22:48 < bridge> <chillerdragon> @milkeeycat: here
22:50 < bridge> <milkeeycat> as a possible solution for `DDNetMessageKind` in `packer.h`, what do you think about moving `ddnet_packer_init_msg` into `message.h`?
22:50 < bridge> <milkeeycat> chillerdragon ^
22:52 < bridge> <gorp_tw> my muscle memory to type nano is pissing me off
22:52 < bridge> <gorp_tw> im going to have to alias nano to micro
22:53 < bridge> <melon> oh i heard about micro, but never used it
22:53 < bridge> <gorp_tw> micro is really sweet
22:53 < bridge> <gorp_tw> ive been using it for a couple weeks now
22:53 < bridge> <gorp_tw> it just does all the things nano should have
22:54 < bridge> <gorp_tw> buffers are tabs by default, you can drag click to select like a GUI notepad
22:54 < bridge> <melon> oh yeah it looks sweet indeed
22:54 < bridge> <gorp_tw> plugins seem capable, lua system like nvim
22:54 < bridge> <gorp_tw> i dont usually like to use language servers though just highlighting
22:55 < bridge> <melon> ye was gonna say, builtin semantic highlightning too - cool
22:55 < bridge> <melon> i used a LOT of terminal editors, but i usually stick with nvim for quick and dirty edits and fallback to emacs/vscode for bigger projects
22:55 < bridge> <gorp_tw> it removes trailing whitespace as you blank lines and skip them, which i thought was nice
22:55 < bridge> <gorp_tw> not just when you save
22:56 < bridge> <gorp_tw> the bracket matching seems smart enough, but knowing when you make a pair of brackets or not is incorrect sometimes
22:57 < bridge> <gorp_tw> i dont doubt that using a proper language server would fix this problem
23:01 < bridge> <chillerdragon> @milkeeycat: that is then a packer function not in the packer header I don’t think it will be found if needed
23:01 < bridge> <chillerdragon> Both are meh but I feel like mine is less meh
23:04 < bridge> <milkeeycat> I don't really think it belongs to packer, yes it takes `DDNetPacker` as an argument but it works with message kind(packer has nothing to do with message kinds), you did the same for snapshots, `ddnet_decode_snapshot` takes `DDNetUnpacker` but the function is defined in `snapshot.h`, not `packer.h`.
23:04 < bridge> <chillerdragon> I see
23:04 < bridge> <chillerdragon> It’s past my working hours tho
23:05 < bridge> <chillerdragon> Can you repost this on GitHub and I will have a look tomorrow :)
23:18 < bridge> <chillerdragon> Score broken again???
23:42 < bridge> <gorp_tw> is WHISPER_SEND not acked?
23:42 < bridge> <gorp_tw> (by the server)