00:37 < bridge> <aegisub> counterargument: wavpack is cool
01:26 < bridge> <sonic (Solly)> because its old, weird and nothing supports it?
01:26 < bridge> <sonic (Solly)> (nothing is an overstatement)
01:50 < bridge> <pioooooo> Requires effort and doesn't benefit much
02:22 < bridge> <sonic (Solly)> what does
02:23 < bridge> <sonic (Solly)> removing wavpack, or keeping it?
02:26 < bridge> <pioooooo> remove
05:52 < bridge> <gorp_tw> please for the love of god switch to opus
05:54 < bridge> <cellegenrih> or to whatever format that works better
05:55 < bridge> <cellegenrih> what, converting all sounds in tw to a different format of choice can be done in a day, but converting other sounds onto wav... eh... gl
06:27 < bridge> <gorp_tw> PREACH
06:27 < bridge> <gorp_tw> opus is the most sensical possible format for this project
06:28 < bridge> <gorp_tw> it is incredibly good, incredibly libre, and supported by literally all modern software
06:29 < bridge> <gorp_tw> moving to something like .ogg is the only other thing i can think of, which is silly given they're the same container format
08:17 < bridge> <ryozuki> hi
08:32 < bridge> <Assa> good morning
09:28 < bridge> <kebscs> Gm
12:10 < bridge> <chillerdragon> @sedonya: can you turn on GitHub notifications so I don’t need to ping you here all the time? Xd
12:48 < bridge> <sedonya> sure
14:37 < bridge> <Assa> @kebscs what do you think of this https://github.com/ddnet/ddnet/issues/11405#issuecomment-3626972243 and would you do the PR?
14:40 < bridge> <kebscs> if you found already whats causing you can pr
14:40 < bridge> <kebscs> im bit tired today
14:40 < bridge> <Assa> I am at work I can't test yet
14:40 < bridge> <kebscs> but probably should be before 19.5
14:40 < bridge> <kebscs> but probably should be before 19.6
14:41 < bridge> <Assa> yes wrote and linked that already
14:50 < bridge> <Assa> I'll make the PR but I can only test at home in the evening
18:48 < bridge> <alw5> quick question, why cant we host 128p currently?
18:49 < bridge> <alw5> i already see servers in browser that has 128p
18:54 < bridge> <kebscs> supporting old clients
18:55 < bridge> <alw5> a
18:56 < bridge> <learath2> No this one is already solved
18:57 < bridge> <learath2> We don't have an implementation of 128p without bugs, fokkonaut tried to port his implementation but we had issues with it when we were running the test servers
18:58 < bridge> <learath2> I don't think anyone else worked on it since, it is afterall quite a hard problem, not many people around that have the motivation and the skillset and want to work on something that's pretty much only for Multeasymap and Linear players 😄
18:58 < bridge> <alw5> and hammer hit players / events
18:58 < bridge> <alw5> more people in a tournament server so u dont need to split it up
18:59 < bridge> <learath2> I have other personal issues with it like I feel 128p on one server is just too much clutter, but that is personal, nothing to do with ddnets position
18:59 < bridge> <kebscs> what were the bugs
18:59 < bridge> <kebscs> for newer clients it should be straightforward as upping max clients and fixing teams
19:00 < bridge> <learath2> I think people settled that just implementing 128p support properly in the client would be much easier than trying to fix the problems with trying to fit 128p into 64p. Then no one really worked on it afterwards
19:01 < bridge> <learath2> I do not remember right now, maybe look up the PR? We may have talked about it in there, or maybe we created individual issues. @0xdeen might remember better
19:01 < bridge> <learath2> I think there were edgecases with stale id map entries which led to crashes
19:02 < bridge> <alw5> i personally think its beneficial
19:02 < bridge> <alw5> sometimes it can feel empty on a 64p server
19:03 < bridge> <learath2> I like the chat a lot, and I find chat is already going way too fast on full 64p servers, that's probably why I'm personally not a huge fan of it
19:03 < bridge> <alw5> oh true i guess
19:03 < bridge> <alw5> well depends i guess
19:04 < bridge> <alw5> i dont think that many people will actually type at teh same time
19:04 < bridge> <alw5> i mean there could be a 128p server hosted right now that only newer clients can play on
19:04 < bridge> <alw5> to test
19:04 < bridge> <alw5> with real people
19:06 < bridge> <learath2> I think even the newer client part hasn't been solved yet, the scoreboard still needs work and I think we need to up all the bitmasks that are currently being used
19:07 < bridge> <nyrrcly_> How long until the next commit like this? I fixed one issue in urk D:
19:07 < bridge> <learath2> (going past 64 means lots of simple integers need to be replaced with `std::bitset`s)
19:08 < bridge> <broso56> man reading this as someone who has almost never seen even 32 players on a usa server is funny
19:08 < bridge> <learath2> but either way, work is definitely appreciated on that front, we already tried running servers with 128p so we are definitely willing to host some, especially in locations where we have the server capability
19:10 < bridge> <learath2> (also probably work on the idmapping would be appreciated, we probably do want a shim to let old clients still join 128p servers, but maybe someone works on a new one instead?, the old one is getting veeery spaghetti)
19:22 < ws-client> **<ChillerDragon>** @learath2 if your chat is too fast maybe `cl_show_chat_friends` works for you
19:22 < ws-client> **<ChillerDragon>** depends on which servers you play some servers are also half full with afks and chat is chill xd
19:23 < ws-client> **<ChillerDragon>** then sometimes parts of the chat is not interesting. On my todo there is the language filter. I don't wanna see all the russian chat anymore xd
19:23 < ws-client> **<ChillerDragon>** another idea is what @fokkonaut did in F-DDrace he turned team chat into activating local chat. Where you only see messages from players from the same part. Reduces the noise from teams you dont care about.
19:25 < ws-client> **<ChillerDragon>** @learath2 u remember why heinrich wanted translations client but not server side?
19:25 < bridge> <learath2> Is it not in the issue? I remember we talked about this, or at the very least I have written something about this
19:26 < bridge> <learath2> Probably the fact that the server will need to be informed of the locale of the player, and the server code gets a lot of new branches
19:28 < ws-client> **<ChillerDragon>** that is both true
19:28 < ws-client> **<ChillerDragon>** but why would that be bad?
19:28 < ws-client> **<ChillerDragon>** i see no issue with the client sending locale and the server looking up translations strings 
19:31 < ws-client> **<ChillerDragon>** server with 16 players runnin massif since the weekend at 1.9% ram. Empty server restarted on the weekend too at 11% ram -.-
19:31 < bridge> <learath2> I will not be making arguments for someone else. I just made guesses as to why
19:31 < ws-client> **<ChillerDragon>** ah oke
19:31 < bridge> <learath2> Seems #3090 is relevant
19:31 < bridge> <DDNet> https://github.com/ddnet/ddnet/pull/3090
19:32 < bridge> <learath2> > To expand: We can update the client with new messages, but we can't update the servers that other people run.
19:32 < ws-client> **<ChillerDragon>** so u agree that its stupid idea to do it client side?
19:32 < bridge> <learath2> said heinrich there
19:32 < ws-client> **<ChillerDragon>** that makes little sense to me
19:32 < ws-client> **<ChillerDragon>** is heinrich planning to add ddnet++ server string translations to the ddnet client or what?
19:32 < bridge> <learath2> no I would do it on the client too, but I don't have any strong opinion here, I think doing it on the client forces us to properly make things into events/netmsgs when needed, it's just good practice and I like good practice
19:33 < ws-client> **<ChillerDragon>** @learath2 you want one net message for all of the 100 errors in ddracechat.cpp?
19:33 < ws-client> **<ChillerDragon>** @learath2 you want a net message for every command description?
19:33 < ws-client> **<ChillerDragon>** @learath2 you want these net messages to go out of date with every server update?
19:33 < bridge> <learath2> this is a fair point, I think I brought this one up 6 years ago too, I think we thought about letting servers ship a set of localized strings, a translation package
19:34 < ws-client> **<ChillerDragon>** @learath2 you want no translation support for third party servers?
19:34 < ws-client> **<ChillerDragon>** ah packages
19:34 < bridge> <learath2> See this is why I did not want to argue about this, I don't care all that much and you want to ask 80 questions as if I murdered your pet or something
19:34 < ws-client> **<ChillerDragon>** sounds complicated
19:34 < ws-client> **<ChillerDragon>** whats the benefit?
19:34 < ws-client> **<ChillerDragon>** yea sori
19:34 < ws-client> **<ChillerDragon>** hein afk
19:34 < ws-client> **<ChillerDragon>** im curious
19:34 < ws-client> **<ChillerDragon>** doing it server side seems like a nobrainer to me
19:35 < bridge> <learath2> I think a `NETMSG_ERROR` is appropriate e.g. for all errors
19:35 < ws-client> **<ChillerDragon>** and whats the payload?
19:35 < ws-client> **<ChillerDragon>** a english string? xd
19:35 < ws-client> **<ChillerDragon>** then we dont need a net message at all
19:35 < ws-client> **<ChillerDragon>** can just translate all known strings sent as chat message
19:36 < ws-client> **<ChillerDragon>** the problem is that it then always depends on client support
19:36 < ws-client> **<ChillerDragon>** so third party is fucked
19:36 < ws-client> **<ChillerDragon>** and new servers only always get partial coverage depending on user client update status
19:36 < ws-client> **<ChillerDragon>** ddnet server restarts arent even in sync with client releases
19:37 < ws-client> **<ChillerDragon>** doing it client side makes it worse on every level and it also makes it more complex nobody is gonna implement that
19:38 < bridge> <nyrrcly_> @learath2 :nouis:
19:38 < ws-client> **<ChillerDragon>** i have yet to hear an actual pro
19:38 < ws-client> **<ChillerDragon>** man should i kill my server anyways and look at massif report?
19:38 < bridge> <learath2> I think you should tell these things to someone that cares more
19:38 < ws-client> **<ChillerDragon>** it didnt collect memory so idk what i expect
19:38 < ws-client> **<ChillerDragon>** @learath2 ye ik
19:38 < bridge> <learath2> don't if it didn't collect memory, makes no sense
19:38 < ws-client> **<ChillerDragon>** but ur the only one who is here
19:38 < ws-client> **<ChillerDragon>** so sadge
19:39 < bridge> <learath2> I guess I do care, but only as far as the fact that I want it implemented one way or the other
19:39 < ws-client> **<ChillerDragon>** i see
19:40 < bridge> <learath2> I don't really care if the server does it or the client, and I can see a way to make both of them decently good
19:40 < ws-client> **<ChillerDragon>** this massif tool is a blazingly runtime optimizer
19:40 < ws-client> **<ChillerDragon>** should just run all prod servers with it
19:40 < ws-client> **<ChillerDragon>** for better performance
19:41 < ws-client> **<ChillerDragon>** in feb i only had it on one vps i feel like my debian update infected the other server too
19:41 < ws-client> **<ChillerDragon>** fakin soydevs at glibc vibe coded too much 
19:41 < ws-client> **<ChillerDragon>** they vibed all the memleaks into ma compiler
19:42 < bridge> <learath2> I'm starting to think it has to be a race condition of sorts, massif really shouldn't be changing anything, it's basically a VM
19:43 < ws-client> **<ChillerDragon>** blazingly optimized VM
19:43 < ws-client> **<ChillerDragon>** like java
19:43 < ws-client> **<ChillerDragon>** this is also how java is faster than C
19:43 < ws-client> **<ChillerDragon>** good vm
19:44 < bridge> <learath2> You said even just linking to tcmalloc also fixes this right?
19:45 < bridge> <learath2> and you were not exaggerating that it just kept going up until OOM
19:45 < ws-client> **<ChillerDragon>** is that a question?
19:46 < bridge> <learath2> yes both questions
19:46 < ws-client> **<ChillerDragon>** yes tcmalloc and massif both fix it
19:46 < ws-client> **<ChillerDragon>** i run both atm
19:46 < ws-client> **<ChillerDragon>** on two different game servers not combined xd
19:47 < ws-client> **<ChillerDragon>** and about the OOM i haven't seen it my self but users reported connection problems once a day back when i only had 7GB ram
19:47 < ws-client> **<ChillerDragon>** then i upgraded to 10GB and they got fixed
19:47 < bridge> <learath2> Do you have any looong running servers you can take a look on and see how large it got?
19:48 < ws-client> **<ChillerDragon>** and when i restart a server they start and stay for a while at 0.8% ram usage and then they climb up to 11% where i restart them as soon as i see it to avoid disasters
19:48 < ws-client> **<ChillerDragon>** i just restarted the only one that was collecting
19:49 < ws-client> **<ChillerDragon>** on GER3 i have one thats running longe
19:49 < ws-client> **<ChillerDragon>** i think xd
19:49 < ws-client> **<ChillerDragon>** its at 15% but thats only 4GB ram server
19:50 < bridge> <learath2> Another function you might find interesting is `mallinfo(3)`, if it truly only happens with glibc malloc this is kinda the only thing we can use to try debug what is going on
19:50 < bridge> <learath2> I guess it's `mallinfo2(3)` nowadays, idk
19:50 < ws-client> **<ChillerDragon>** oh on GER8 might be the longest running server of them all
19:50 < ws-client> **<ChillerDragon>** thats 5% of 16GB
19:51 < bridge> <learath2> Actually apparently we even have `malloc_info(3)` now with fancy XML output 😄
19:51 < ws-client> **<ChillerDragon>** if i do ugly c++ std:: stuff like vectors
19:51 < ws-client> **<ChillerDragon>** does it get tracked by mallinfo?
19:52 < ws-client> **<ChillerDragon>** i wonder how this output would help me
19:52 < ws-client> **<ChillerDragon>** what would i be looking for?
19:53 < bridge> <learath2> It should be tracking C++ stuff too, they all use the same malloc at the end of the day
19:53 < ws-client> **<ChillerDragon>** oh you mean use it as a profiler
19:53 < ws-client> **<ChillerDragon>** so just dump it all like massif
19:53 < ws-client> **<ChillerDragon>** but without running massif so it actually collects memory
19:53 < ws-client> **<ChillerDragon>** i see
19:53 < ws-client> **<ChillerDragon>** good idea thanks
19:54 < ws-client> **<ChillerDragon>** will look into it
19:54 < bridge> <ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1447662709226078208/5lvW1EP.png?ex=69387076&is=69371ef6&hm=9a85d0937aa2f3cfd2821ea83461d1baee7af9f3e83a81e061fbe8540720caa0&
19:55 < bridge> <learath2> (idk if it will have very useful information tbh with you, but maybe you can spot something, maybe it is for some bizarre reason keeping too many arenas, maybe it has very high keepcost)
19:55 < ws-client> **<ChillerDragon>** oh shiet
19:55 < ws-client> **<ChillerDragon>** it doesnt show variables and stuff
19:55 < ws-client> **<ChillerDragon>** this will basically be as useful as gdb heap dump i fell
19:55 < ws-client> **<ChillerDragon>** feel*
19:58 < bridge> <learath2> In 2026 for sure
20:52 < bridge> <teero777> what is the freeze bar based on? im kind of confused. what triggers it to be rendered? is there a special netmsg?
20:54 < bridge> <robyt3> `m_FreezeEnd` and `m_FreezeStart` in the `DDNetCharacter` object
20:55 < bridge> <teero777> hmm okay then i must be doing something else wrong. in my custom demos the freezebars aren't rendered. i guess I'll do some debugging.
20:55 < bridge> <teero777> htanks
20:56 < bridge> <teero777> thanks
21:02 < bridge> <teero777> ah lol
21:02 < bridge> <teero777> i was setting the character to be in freeze
21:02 < bridge> <teero777> ```c
21:02 < bridge> <teero777>     if (c_cur->m_FreezeTime > 0) {
21:02 < bridge> <teero777>       dc->m_Flags |= DD_CHARACTERFLAG_IN_FREEZE;
21:03 < bridge> <teero777>     }
21:03 < bridge> <teero777> ```
21:03 < bridge> <teero777> thats wrong
21:09 < bridge> <teero777> okay it works :)
21:37 < ws-client> **<ChillerDragon>** @learath2 caught leak with malloc_info but it shows 0 for all xd https://github.com/ddnet-insta/ddnet-insta/issues/267#issuecomment-3628637021
21:40 < ws-client> **<ChillerDragon>** on arch locally i get way more output https://paste.zillyhuhn.com/a6
21:42 < ws-client> **<ChillerDragon>** is it showing 0 for all on my vps a indicator that glibc is actually bugged? xd
22:02 < bridge> <milkeeycat> Today's aoc made me feel like a brain dead moron who can't read :pepeW:
22:15 < bridge> <robyt3> Even if the sizes weren't all 0, isn't this info too coarse to find the leak? Maybe https://github.com/KDE/heaptrack helps if you can reproduce the leak with it.