13:30 < bridge_> <nazar_79968> What should I do if my screen is flickering?
13:31 < bridge_> <nazar_79968> Ddnet
13:32 < bridge_> <oxyzo.> #bugs 
13:32 < bridge_> <oxyzo.> Try changing fullscreen mode in GRAPHICS tab
13:32 < bridge_> <oxyzo.> Or render thing like opengl or vulkan
15:28 < bridge_> <meloƞ> @sollybunny the strength indicator is only rendered when both the icon and the number are selected, but not when its just the icon
15:28 < bridge_> <meloƞ> https://cdn.discordapp.com/attachments/293493549758939136/1363868922709016708/image.png?ex=6807996a&is=680647ea&hm=53486f0fbea742dfa74d7bd755cc699ef6fd44b54a4442994c89e574d6c0c6d6&
15:28 < bridge_> <meloƞ> https://cdn.discordapp.com/attachments/293493549758939136/1363868923077857522/image.png?ex=6807996a&is=680647ea&hm=bd3066f910c4a3eb9cdbe5dd8f6e9d1cf4f27dd8e97065114003cb15545ff90b&
15:56 < bridge_> <learath2> @sans._. && @tsfreddie I think you two were curious about it https://github.com/Learath2/ddnet-modactivity
15:56 < bridge_> <TsFredium> suddenly open source
15:57 < bridge_> <learath2> It is a bit of a mess tbh, but I can't be assed to clean it up for an internal tool really
16:11 < bridge_> <Solly (bun bun)> That's not good
16:17 < bridge_> <Solly (bun bun)> how the fuck have i done this
16:17 < bridge_> <Solly (bun bun)> why does the gap change
16:19 < bridge_> <Solly (bun bun)> the reaosn the icon doesnt show is that you dont have hook strength or weaketh with urself
16:19 < bridge_> <Solly (bun bun)> press preview dummy to show it
16:19 < bridge_> <Solly (bun bun)> this might be uniniutive so can be changed
16:23 < bridge_> <Solly (bun bun)> the gap changes due to my bad code in rendernameplateprevivew
16:23 < bridge_> <Solly (bun bun)> the bug isnt in game
16:44 < bridge_> <kebscs> @essigautomat on the door "glitch" video
16:44 < bridge_> <kebscs> https://cdn.discordapp.com/attachments/293493549758939136/1363888177814704379/image.png?ex=6807ab59&is=680659d9&hm=6dadc6cf1bbdeae81d5d3a3dc6a7b6419c795200ce5b41d261dc4d8154e790f9&
16:44 < bridge_> <kebscs> https://cdn.discordapp.com/attachments/293493549758939136/1363888178183929856/image.png?ex=6807ab59&is=680659d9&hm=9f526049122811c90118824f38b03d846496ce6d818ba763d9a3f9755f436904&
16:49 < bridge_> <kebscs> if the guy pressing off button it doesn always turn off the door visually
16:50 < bridge_> <kebscs> if the guy pressing off button is off screen, it doesn always turn off the door visually
16:53 < bridge_> <kebscs> or maybe its bcs on and off held at same time idk
16:56 < bridge_> <kebscs> yea if off is held you dont receive switchstate netobj when going into on
16:57 < bridge_> <kebscs> yea if off is held you dont receive switchstate netobj when going into on, but door can turn on/off
18:32 < bridge_> <fokkonaut> can anyone help with a curl_multi_perform crash in CHttp::RunLoop?
18:32 < bridge_> <fokkonaut> I recently updated register and http code to ddnet's master, but it still happens here and there
18:33 < bridge_> <robyt3> Maybe a mismatch between curl library and header versions, confirm the curl version being used in the headers and linked in the library
18:35 < bridge_> <robyt3> Do you only have IPv6? See #6011
18:35 < bridge_> <DDNet> https://github.com/ddnet/ddnet/issues/6011
18:35 < bridge_> <robyt3> No idea how to reproduce this and #7620 though
18:35 < bridge_> <DDNet> https://github.com/ddnet/ddnet/issues/7620
18:47 < bridge_> <kebscs> how do i remove a compile option flag in ddnet cmake?
18:48 < bridge_> <kebscs> im adding /ZI and i get this warning `warning D9025: overriding '/Zi' with '/ZI'`
18:48 < bridge_> <kebscs> `/Zi` isnt in the CMakeLists
18:51 < bridge_> <robyt3> https://stackoverflow.com/a/73902259
18:51 < bridge_> <robyt3> Maybe you need to set `CMAKE_CXX_FLAGS_DEBUG`
18:51 < bridge_> <kebscs> yea the problem is when i do ` message(STATUS "Debug flags: ${CMAKE_CXX_FLAGS_DEBUG}")` at the very bottom of cmake
18:52 < bridge_> <kebscs> theres no /Zi `Debug flags: /Ob0 /Od /RTC1`
18:52 < bridge_> <robyt3> Try in `CMakeCache.txt` where the flag comes from
18:52 < bridge_> <robyt3> Try search in `CMakeCache.txt` where the flag comes from
18:56 < bridge_> <matodor> xd, wtf?
18:56 < bridge_> <matodor> https://cdn.discordapp.com/attachments/293493549758939136/1363921440751227030/image.png?ex=6807ca53&is=680678d3&hm=0405e5fcf6fd34db4c444c8e7f179850bfc97fa230413a7be11c99f2e885918a&
18:57 < bridge_> <kebscs> its not there
18:59 < bridge_> <kebscs> no flags in it that were set with target_compile_options
18:59 < bridge_> <kebscs> no flags in it that were set with target_compile_options either
18:59 < bridge_> <robyt3> Check in `build.ninja` or `Makefile`
19:03 < bridge_> <kebscs> in build.ninja FLAGS has -Zi
19:04 < bridge_> <robyt3> Next debug how that is constructed :justatest:
19:14 < bridge_> <kebscs> i guess i could do a workaround but cmake needs to be 3.25+
19:29 < bridge_> <Ewan> can’t it be?
19:30 < bridge_> <Ewan> that’s a very realistic version of cmake to have even still
19:30 < bridge_> <Ewan> idk if ddnet already constrains on version off the top of my head
19:35 < bridge_> <kebscs> ddnet has cmake_minimum_required(VERSION 3.12...3.27.4)
19:35 < bridge_> <kebscs> i have 3.30 and i get no warnings or anything
19:52 < bridge_> <kebscs> the server doesnt even lag when reloading with it
19:52 < bridge_> <kebscs> https://cdn.discordapp.com/attachments/293493549758939136/1363935320877564156/hotreload.mp4?ex=6807d741&is=680685c1&hm=be50c9a40eb9704bc5a258790421bafadbc2262e6fd1af91f74154605f5006d0&
19:53 < bridge_> <Assa> is this latest master? dragger visuals changed
19:53 < bridge_> <kebscs> yes
19:53 < bridge_> <Assa> huh
19:54 < bridge_> <kebscs> if you mean the 3 dots
19:54 < bridge_> <Assa> yes
19:54 < bridge_> <kebscs> then seems like the assets didnt update
19:54 < bridge_> <kebscs> i fully rebuilt it too
19:54 < bridge_> <Assa> maybe they're behind the tee
19:54 < bridge_> <kebscs> nope dont have them
19:54 < bridge_> <kebscs> https://cdn.discordapp.com/attachments/293493549758939136/1363936007598113159/image.png?ex=6807d7e4&is=68068664&hm=9d6c4bccd74eb99ccab28b9c372aa58a65aed9b6b17bfef822dac9abd62de593&
19:54 < bridge_> <Assa> yeah looks missing
19:55 < bridge_> <Ewan> i think if u put a ceiling on the version it’ll just behave as if it is that version
19:55 < bridge_> <Ewan> i think if u put a ceiling on the version & yours is newer, it’ll just behave as if it is that version
19:56 < bridge_> <kebscs> probably
19:57 < bridge_> <Assa> but cool work :3
20:20 < bridge_> <fokkonaut> Same.
20:20 < bridge_> <fokkonaut> And yea could be, but I only use ipv4
20:20 < bridge_> <fokkonaut> how do i check all the versions?
20:22 < bridge_> <fokkonaut> @heinrich5991 you had no idea about this right?
20:22 < bridge_> <fokkonaut> I didnt know this was an issue in ddnet too
20:22 < bridge_> <robyt3> Check the console log for `I http: libcurl version 8.8.0 (compiled = 8.8.0)`
20:22 < bridge_> <fokkonaut> on startupM
20:23 < bridge_> <fokkonaut> ?*
20:23 < bridge_> <fokkonaut> where does it get logged from, i dont have the latest logger changes
20:24 < bridge_> <robyt3> Should get logged on startup from `http.cpp`
20:24 < bridge_> <fokkonaut> okay, will check when home, thanks
20:27 < bridge_> <fokkonaut> nevertheless, the crash also seems to happen on ddnet no?
20:28 < bridge_> <robyt3> It never happened to me, I don't know how to reproduce the open issues
20:28 < bridge_> <fokkonaut> me neither, i just run 8 servers and sometimes it happens
20:29 < bridge_> <fokkonaut> sometimes not for days, sometimes multiple times on a single day
20:30 < bridge_> <fokkonaut> sometimes at the same time on multiple servers
20:30 < bridge_> <fokkonaut> but not always, definitely
20:31 < bridge_> <fokkonaut> logs are clear, like only chat messages, nothing register related or anything
20:31 < bridge_> <robyt3> Try to get a backtrace from all threads with gdb
20:31 < bridge_> <fokkonaut> how to do that? I only have the normal backtrace
20:31 < bridge_> <robyt3> `thread apply all bt` inside `gdb`
20:34 < bridge_> <robyt3> Or non-interactively: `gdb ./DDNet-Server core.dmp -ex "thread apply all bt" -ex "detach" -ex "quit" > output.log`
22:59 < bridge_> <Jupstar ✪> @alw5 rage quitter
23:05 < bridge_> <teero777> @alw5 you would have neede to go through this with asan/ubsan if you hadn't yet. last time stormaxs showed me this it had a lot of UB XD
23:05 < bridge_> <teero777> @alw5 you would have needed to go through this with asan/ubsan if you hadn't yet. last time stormaxs showed me this it had a lot of UB XD
23:05 < bridge_> <teero777> @alw5 you would have needed to go through this with asan/ubsan if you hadn't yet. last time stormaxs showed me this it had a lot of UB afair XD
23:16 < bridge_> <fokkonaut> Can anyone point me to the discussion of m_TuneZoneOverride, m_aExpectingTuningForZone, m_aReceivedTuning?
23:16 < bridge_> <fokkonaut> It seems to be heavily off and unreliable, where as the old system was much better.
23:16 < bridge_> <fokkonaut> Also, why do we do all of this, when the client has all / most information to process tunings clientside (at least per zone tunings)
23:16 < bridge_> <fokkonaut> (unreliable if m_TuneZoneOverride is unset, i.e. -1)
23:17 < bridge_> <fokkonaut> it seems very messy
23:19 < bridge_> <kebscs> https://cdn.discordapp.com/attachments/293493549758939136/1363987649941078186/image.png?ex=680807fd&is=6806b67d&hm=5258a73e451c886fa18a03084d2f27ac6d00e486a8bb3071bc62a0a3257d654c&
23:20 < bridge_> <kebscs> why unreliable without override?
23:21 < bridge_> <kebscs> from my understanding this stuff is necessary, because when you enter a new zone, you dont instantly receive new tune params msg
23:21 < bridge_> <kebscs> so these are waiting few snaps for next zone msg to put into the new zone
23:21 < bridge_> <fokkonaut> Hm, maybe i do not understand it correct / use it correct? 
23:21 < bridge_> <fokkonaut> How can I debug this, I have a bunch of tune zones
23:21 < bridge_> <fokkonaut> yea but i mean, the whole thing could be predicted clientside...
23:21 < bridge_> <fokkonaut> the client knows the tunings
23:21 < bridge_> <fokkonaut> and has the underlying collision code, to access them
23:22 < bridge_> <fokkonaut> same for laser doors, and status
23:22 < bridge_> <kebscs> yea it knows the tunings because of map settings
23:22 < bridge_> <fokkonaut> client can just read the tunings from map file
23:22 < bridge_> <fokkonaut> yea
23:22 < bridge_> <kebscs> so on ddnet the tunes received by tuneparam msg are the same
23:22 < bridge_> <fokkonaut> yes
23:22 < bridge_> <kebscs> so it doesnt change anything bcs the receied is the same
23:23 < bridge_> <fokkonaut> it would predict tunezones properly
23:23 < bridge_> <kebscs> just handles the new param msgs for idk mods or something
23:23 < bridge_> <kebscs> it already dos
23:23 < bridge_> <kebscs> it already does
23:23 < bridge_> <fokkonaut> ah i didnt know
23:23 < bridge_> <kebscs> you can check <https://github.com/ddnet/ddnet/pull/10000/files>
23:24 < bridge_> <fokkonaut> how can i debug this:
23:24 < bridge_> <fokkonaut> `2025-04-21 23:19:08 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:08 I tunezone: waiting for tuning for zone 0
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:08 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:08 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:08 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:08 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:08 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:08 I tunezone: the tuning was missed
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:09 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:09 I tunezone: waiting for tuning for zone 4
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:09 I tunezone: waiting for tuning for zone 4
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:09 I tunezone: waiting for tuning for zone 4
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:09 I tunezone: waiting for tuning for zone 4
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:09 I tunezone: waiting for tuning for zone 4
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:09 I tunezone: the tuning was missed
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:09 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:09 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:09 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:10 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:10 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:10 I tunezone: the tuning was missed
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:10 I tunezone: waiting for tuning for zone 0
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:10 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:10 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:10 I tunezone: waiting for tuning for zone 2
23:24 < bridge_> <fokkonaut> 2025-04-21 23:19:10 I tunezone: waiting for tuning for zone 2`
23:24 < bridge_> <kebscs> easier to see what it does bcs its all in 1 place
23:24 < bridge_> <kebscs> `dbg_msg("tunezone", "the tuning was missed");`
23:24 < bridge_> <kebscs> is there in CGameClient::UpdatePrediction()
23:24 < bridge_> <fokkonaut> it doesnt happen always.
23:25 < bridge_> <fokkonaut> no idea what's heppening, whether client or serverside
23:25 < bridge_> <kebscs> ill explain the entire process how it handles the tunes
23:26 < bridge_> <fokkonaut> now it happened
23:26 < bridge_> <fokkonaut> again
23:26 < bridge_> <fokkonaut> but only for zone 0 and 2, can you maybe take a look at it?
23:29 < bridge_> <kebscs> 1. client enters new zone on map
23:29 < bridge_> <kebscs> 2. `m_aExpectingTuningSince` is set, this is for storing how long it waited
23:29 < bridge_> <kebscs> 3.  `m_aExpectingTuningForZone` is set, this stores the id of zone from map
23:29 < bridge_> <kebscs> 4. now its expecting `NETMSGTYPE_SV_TUNEPARAMS` message
23:29 < bridge_> <kebscs> 5. if not received yet `dbg_msg("tunezone", "waiting for tuning for zone %d",`
23:29 < bridge_> <kebscs> 5. if not received in 10 snaps `dbg_msg("tunezone", "the tuning was missed");` and stop waiting for it
23:29 < bridge_> <kebscs> 1. client enters new zone on map
23:29 < bridge_> <kebscs> 2. `m_aExpectingTuningSince` is set, this is for storing how long it waited
23:29 < bridge_> <kebscs> 3.  `m_aExpectingTuningForZone` is set, this stores the id of zone from map
23:29 < bridge_> <kebscs> 4. now its expecting `NETMSGTYPE_SV_TUNEPARAMS` message
23:29 < bridge_> <kebscs> 5. if not received yet `dbg_msg("tunezone", "waiting for tuning for zone %d",`
23:29 < bridge_> <kebscs> 5. if not received in 10 snaps `dbg_msg("tunezone", "the tuning was missed");` and stop waiting for it
23:29 < bridge_> <kebscs> 7. if received, update the zone with id of `m_aExpectingTuningForZone`
23:30 < bridge_> <kebscs> so im guessing in this case, the client enters new zone on map, and server doesnt send the `NETMSGTYPE_SV_TUNEPARAMS` message
23:31 < bridge_> <fokkonaut> does it handle spec correctly
23:31 < bridge_> <fokkonaut> getting moved through tune zones while in spec
23:31 < bridge_> <fokkonaut> pause
23:32 < bridge_> <kebscs> freeview?
23:32 < bridge_> <fokkonaut> i guess, any, i mean my server doesnt send the override at all
23:33 < bridge_> <kebscs> well on spec it shouldnt wait when entering zone during freeview bcs of `vec2 LocalCharPos = vec2(m_Snap.m_pLocalCharacter->m_X, m_Snap.m_pLocalCharacter->m_Y);`
23:33 < bridge_> <kebscs> <https://github.com/ddnet/ddnet/pull/10000/files> would change it so you can also enter zone with freeview and handle the tunemsg param, because it is sent
23:33 < bridge_> <kebscs> on master it only handles localplayer pos
23:33 < bridge_> <kebscs> <https://github.com/ddnet/ddnet/pull/10000/files> would change it so you can also enter zone with freeview and handle the tunemsg param, because it is sent by server
23:36 < bridge_> <kebscs> if you want to use override you have to send the tune param msg aswell
23:36 < bridge_> <kebscs> this worked in my tune lock tile pr
23:38 < bridge_> <fokkonaut> okay, i already thought that the whole idea of this is for tune lock. but imo not a good solution, because it has no flexibilitya t all
23:39 < bridge_> <kebscs> its alright i guess, you can use a zone thats not used on map and change the params+use override
23:40 < bridge_> <kebscs> so you have any settings you want dynamically
23:40 < bridge_> <always> ye
23:40 < bridge_> <fokkonaut> not really dynamic. cant combine anything, cant dynamically change it per rcon to whatever you want, etc
23:41 < bridge_> <kebscs> why not?
23:41 < bridge_> <kebscs> you change the params, set override and he has the new params with what youve set with rcon
23:41 < bridge_> <fokkonaut> how does the client get the new values
23:41 < bridge_> <kebscs> the `NETMSGTYPE_SV_TUNEPARAMS`
23:42 < bridge_> <fokkonaut> i still do not understand why we need the override parameter then
23:42 < bridge_> <fokkonaut> if we end up just sending a tune msg
23:43 < bridge_> <kebscs> the msg is just so it updated params for prediction
23:43 < bridge_> <kebscs> you send override so client locks that zone for themselves
23:43 < bridge_> <kebscs> e.g. override 2 = thinks its always in zone 2
23:43 < bridge_> <fokkonaut> yea, and how can it dynamically adjust the tuning parameters and values then
23:44 < bridge_> <fokkonaut> if it uses predefined tune zones as override
23:44 < bridge_> <kebscs> tune_zone rcon command
23:44 < bridge_> <fokkonaut> does that trigger an update on the tune zone list clientside?
23:45 < bridge_> <kebscs> it updates params+ send the tune param msg to everyone within that zone
23:45 < bridge_> <kebscs> it updates params+ sends the tune param msg to everyone within that zone
23:45 < bridge_> <fokkonaut> https://github.com/ddnet/ddnet/blob/31f8a933d8e6d38657aa64c9cfd2eff6977a471a/src/game/server/gamecontext.cpp#L3011-L3032
23:45 < bridge_> <kebscs> other people that arent in the zone do not, so thats the problem
23:45 < bridge_> <fokkonaut> i dont see any client update
23:45 < bridge_> <kebscs> `pSelf->SendTuningParams(-1, List);`
23:46 < bridge_> <fokkonaut> that does not update the tuning zone list
23:46 < bridge_> <fokkonaut> on the client
23:46 < bridge_> <fokkonaut> .
23:47 < bridge_> <kebscs> it does if youre standing inside that zone
23:47 < bridge_> <fokkonaut> no
23:47 < bridge_> <fokkonaut> what it does is, it updates the tunings
23:47 < bridge_> <fokkonaut> but not the zone specific tunes on the client
23:47 < bridge_> <fokkonaut> i.e. the override used for tune lock can not be changed dynamically
23:48 < bridge_> <fokkonaut> only using some kind of tracking of the message maybe xP
23:48 < bridge_> <kebscs> i dont understand
23:48 < bridge_> <kebscs> if i stay in zone 3, and type tune_zone 3 gravity 10
23:48 < bridge_> <kebscs> i get msg of all new params and it places them into world
23:48 < bridge_> <kebscs> so then client knows tune 3 has these new tunes
23:49 < bridge_> <fokkonaut> the client needs all correct values for all tees, in order to predict everything
23:49 < bridge_> <fokkonaut> ah, it tracks that?
23:49 < bridge_> <fokkonaut> see, so it doesnt use the map zones
23:49 < bridge_> <kebscs> yes this is what this does
23:49 < bridge_> <fokkonaut> the whole thing seems so bloaty, we need to change a lot of the tune handling
23:49 < bridge_> <kebscs> to update zones on map
23:49 < bridge_> <kebscs> the problem is you receive the param only if you stand in that tune
23:49 < bridge_> <fokkonaut> also on the serverside we do have the character tunezone, and the player tunezone based on viewpos
23:49 < bridge_> <kebscs> or reenter it
23:50 < bridge_> <fokkonaut> the problem is the whole thing it's way too large and based on strings
23:50 < bridge_> <kebscs> so if someone else is on different zone that got updated you wont be able to correctly predict them
23:50 < bridge_> <fokkonaut> yes
23:50 < bridge_> <tide8> Hey, quick questions. Does anyone have any good ways to read the teehistorian file output ?
23:51 < bridge_> <fokkonaut> i dont think there is any converter yet
23:51 < bridge_> <fokkonaut> but i might be wrong
23:51 < bridge_> <kebscs> yea it is kinda bad, but i managed to understand it XD
23:51 < bridge_> <kebscs> even though its bloaty it works fine, expect the updating tunes with rcon
23:51 < bridge_> <fokkonaut> @kebscs yes okay :D i understand now
23:51 < bridge_> <kebscs> even though its bloaty it works fine, expect the updating tunes with rcon for different zone
23:52 < bridge_> <fokkonaut> i have to debug it a little, to see what exactly is going on in this trouble 😄
23:53 < bridge_> <tide8> Im trying to debug a server crash, do you have anything better than teehistorian to try to debug that ? it kinda randomly happens so we're trying to figure out what is causing it
23:53 < bridge_> <fokkonaut> compile in debug mode and see the backtrace
23:55 < bridge_> <tide8> okay i will look more into it, thank you
23:55 < bridge_> <fokkonaut> https://github.com/ddnet/ddnet?tab=readme-ov-file#building-on-linux-and-macos