01:15 <+bridge_> <cherryex> @robyt3 Why is my pr merged but not present in 19.7?
01:15 <+bridge_> <cherryex> https://github.com/ddnet/ddnet/pull/11439
02:09 <+bridge_> <kebscs> probably merged after 19.7 pr was created
06:07 <+bridge_> <12944qwerty> I keep getting this when I build ddnet. I did install vulkansdk and the env vars are all set correctly. I'm on linux so the build flag is on by default too
06:07 <+bridge_> <12944qwerty> https://cdn.discordapp.com/attachments/293493549758939136/1467385958906204210/image.png?ex=6980312b&is=697edfab&hm=2d6237422b6dcb6bf5bb2f0f3afd7a287d2c59ebed03b3f1474893e00b0d403f&
06:25 <+bridge_> <12944qwerty> Might have to do with the fact that i'm pretty sure it's not building correctly?
06:25 <+bridge_> <12944qwerty> No errors, but any changes I make aren't shown. Strings edits for example
06:25 <+bridge_> <12944qwerty> Also, not using the vulkan sdk I downloaded and using an older version
06:27 <+bridge_> <12944qwerty> btw, even though the vulkan error happened before, it used to update whatever I was changing about a week ago
06:28 <+bridge_> <12944qwerty> this happens even when I rm -rf the build directory entirely
06:28 <+bridge_> <12944qwerty> this happens even when I rm -rf the build directory too
06:33 <+bridge_> <12944qwerty> correction, seems like it doesn't build for src/game/map/render_map.cpp (or directory) specifically
06:43 <+bridge_> <12944qwerty> also, anyone know how to fix the multitude of ⁨`file not foundclang(pp_file_not_found)`⁩ scattered all over when I have the project opened in vscode
07:12 <+bridge_> <12944qwerty> correction, seems like it doesn't build for src/game/map/render_map.cpp specifically
07:15 <+bridge_> <12944qwerty> nvm
08:03 <+bridge_> <chillerdragon> @essigautomat: I don’t know I am not associated with ddnet. I just know the ranks broke there :/ all my farmed stats gone
08:54 <+bridge_> <12944qwerty> super small but i was annoyed by this xd
08:56 <+bridge_> <12944qwerty> ngl tho, it kinda looks better (more like a tune) with an alpha, but not sure whether to do that or not
08:56 <+bridge_> <12944qwerty> https://cdn.discordapp.com/attachments/293493549758939136/1467428310051983382/image.png?ex=6980589c&is=697f071c&hm=b7456cd9ace80e98ea44f58977c1a7f8c09d280915cf8f575609fcbee3d9ad9c&
09:04 <+bridge_> <12944qwerty> ngl tho, it kinda looks better (more like a tune) with an alpha, but not sure whether to do that or not. Feels better if there's a large tuning area with the opacity so
09:04 <+bridge_> <12944qwerty> https://cdn.discordapp.com/attachments/293493549758939136/1467428310051983382/image.png?ex=6980589c&is=697f071c&hm=b7456cd9ace80e98ea44f58977c1a7f8c09d280915cf8f575609fcbee3d9ad9c&
09:13 <+bridge_> <gorp_tw> yo finally we have some text on the damn tile
09:14 <+bridge_> <gorp_tw> if ppl are gonna complain about oco again then we should have a map setting ⁨`sv_hide_tune_numbers`⁩
09:14 <+bridge_> <gorp_tw> but imo its crazy thing to complain about
09:14 <+bridge_> <gorp_tw> compared to literally any other worse problem in the game XD
09:33 <+bridge_> <12944qwerty> Why sv not cl?
09:33 <+bridge_> <12944qwerty> And oco?
09:42 <+bridge_> <12944qwerty> Why map setting not client setting?
09:50 <+bridge_> <efetee.> do i get masterban if i create 25 servers ( 2 server per gamemode )
09:52 <+ChillerDragon> @milkeeycat can i use unix `sort` on my visual selection in vim smh?
09:55 <+bridge_> <milkeeycat> chillerdragon: select the lines, press ⁨`:`⁩ and then ⁨`!sort`⁩
09:55 <+bridge_> <inv41idu53rn4m3> 25 isn't divisible by 2?
09:55 <+bridge_> <inv41idu53rn4m3> Also no, if the servers aren't spammy or breaking any rules, 25 seems like a perfectly reasonable number
09:56 <+ChillerDragon> holy shit i knew it was that simple i just couldnt google it xd thanks @milkeeycat this is amazing
09:56 <+bridge_> <milkeeycat> (you can execute regular terminal commands by prefixing them with ⁨`!`⁩)
09:56 <+bridge_> <efetee.> nvm i found a way to decrease it to 12 servers
09:56 <+bridge_> <milkeeycat> i often use ⁨`jq`⁩
09:56 <+bridge_> <milkeeycat> so prettify json
09:56 <+ChillerDragon> i knew about ! i just didnt know how it interacted with the buffer
09:57 <+bridge_> <milkeeycat> to prettify json
09:57 <+bridge_> <inv41idu53rn4m3> You can even skip the :
09:57 <+ChillerDragon> i thought its more for  stuff like !make
09:58 <+bridge_> <inv41idu53rn4m3> The entire point of ! is that it pipes the selection into the command
09:58 <+bridge_> <inv41idu53rn4m3> The feature is called filtering
09:58 <+ChillerDragon> pretty cool i hope ill remember it
09:59 <+ChillerDragon> maybe one day after years of using vim i will be actually more productive than in vscode xd
10:01 <+bridge_> <inv41idu53rn4m3> It's good for actual filtering, like !grep, or testing complex expressions, like !python
10:02 <+bridge_> <inv41idu53rn4m3> Or even compilation; write some markdown and hit it with ! markdown
10:02 <+bridge_> <inv41idu53rn4m3> Or even compilation; write some markdown and hit it with !markdown
10:29 <+ChillerDragon> i do not have a `markdown` command oO
10:36 <+bridge_> <Assa> should - if at all - be a client setting. Added some info to the PR
10:39 <+bridge_> <gorp_tw> because that map specifically is designed to troll you
10:39 <+bridge_> <gorp_tw> making a client setting is still gonna piss off the oco enjoyers
10:39 <+bridge_> <gorp_tw> i will make it clear again though that i personally do not care
10:39 <+bridge_> <gorp_tw> force it if you want
11:13 <+bridge_> <inv41idu53rn4m3> Not something I'd expect to be installed by default, and nowadays probably replaced by a different compiler
11:25 <+bridge_> <alw5> can you check map aardvark
11:26 <+bridge_> <alw5> with this enableed
11:26 <+bridge_> <alw5> with this enabled
11:40 <+bridge_> <gorp_tw> doesn't make sense to render tune settings when you can have an arbitrary amount of settings per tune zone
11:41 <+bridge_> <gorp_tw> you can check the map file to see what tunes do what if you cant keep the numbers clear in ur head, otherwise coloring tunes like nixus said would be better
11:45 <+bridge_> <robyt3> Players shouldn't be expected to open the map in the editor to see information relevant for gameplay
11:45 <+bridge_> <alw5> is seeing tunes relevant for gameplay?
11:46 <+bridge_> <robyt3> Coloring also makes sense additionally
11:46 <+bridge_> <robyt3> Well, technically makes should be playable without entities
11:46 <+bridge_> <robyt3> Well, technically maps should be playable without entities
11:46 <+bridge_> <gorp_tw> as it is you can't even tell after closing the editor, since the same such numbers arent there
11:46 <+bridge_> <alw5> yea and they should be designed well
11:46 <+bridge_> <gorp_tw> colors are not as useful if you are cross-referencing with the editor
11:47 <+bridge_> <robyt3> Color and labels, but don't repeat the labels everywhere
11:47 <+bridge_> <alw5> when there is a tune zone in a map the map does indicate somehnow
11:47 <+bridge_> <alw5> when there is a tune zone in a map the map does indicate somehow
11:47 <+bridge_> <gorp_tw> maybe but i already hate whatever chunking logic that is in the client
11:47 <+bridge_> <gorp_tw> since kebs' tele thing doesnt always work as expected, i found it frustrating to use
11:47 <+bridge_> <gorp_tw> maybe if that logic is cleaned up it can be used for what is a "region" for contigious tunezones
11:48 <+bridge_> <kebscs> What tele thing
11:48 <+bridge_> <gorp_tw> View
11:48 <+bridge_> <gorp_tw> it skips things that are not the same tile index
11:48 <+bridge_> <kebscs> It's not mine
11:48 <+bridge_> <gorp_tw> oh mb
11:48 <+bridge_> <robyt3> I think #6134 is mostly about entities mode without seeing the map design
11:48 <+bridge_> <DDNet> https://github.com/ddnet/ddnet/issues/6134
11:48 <+bridge_> <kebscs> It was even worse before I changed it a bit
11:48 <+bridge_> <gorp_tw> xd
11:49 <+bridge_> <gorp_tw> but yeah there's maybe some improvements, idk if it is based on flood-fill or some weird like scan-by-row thing
11:49 <+bridge_> <robyt3> I don't remember there being any flood-fill-like algorithm
11:49 <+bridge_> <gorp_tw> but i think i would prefer the same logic applies
11:50 <+bridge_> <gorp_tw> that way we dont have to maintain two different algorithms
11:50 <+bridge_> <alw5> also
11:50 <+bridge_> <alw5> why would you want to know exactly what a tune does
11:51 <+bridge_> <alw5> just enter it and find out
11:51 <+bridge_> <alw5> most of the time its safe
11:51 <+bridge_> <gorp_tw> idk like, i dont think its a big deal to show the number, i would have assumed if this was bad ppl would complain about tele number spam at least
11:51 <+bridge_> <gorp_tw> i get that its not really the same comparison cus tune is spammed way more sometimes
11:51 <+bridge_> <gorp_tw> unless its like sincera where its a jump pad
11:51 <+bridge_> <alw5> but you cant go into tele u can go into a tune
11:51 <+bridge_> <gorp_tw> yeah fair
11:51 <+bridge_> <gorp_tw> so it blocks the view
11:52 <+bridge_> <gorp_tw> we can always make it dbg only like we currently have
11:52 <+bridge_> <gorp_tw> and show only color otherwise
11:52 <+bridge_> <gorp_tw> not sure the best way.. probably best left to settings but to me this is already like 3 settings if at all
11:52 <+bridge_> <gorp_tw> which is probably bad
11:53 <+bridge_> <gorp_tw> cus you can have deduplicated numbers or always numbered, and then whether that shows in debug only or not, and then color and if it's debug only or not
11:53 <+bridge_> <robyt3> The argument was that you can't stay in all tune zones, otherwise ⁨`dbg_tuning 1`⁩ mostly solves this
11:53 <+bridge_> <gorp_tw> probably a sensible default is preferred but i think color should be off by default
11:54 <+bridge_> <alw5> can a map be provided?
11:54 <+bridge_> <gorp_tw> since its gonna fuck with a ton of ppls entities when similar colors are used
11:54 <+bridge_> <alw5> i swear this is like never the case
11:54 <+bridge_> <gorp_tw> yeah good luck trying to see what tunezone applies to u in volleyball with dbg_tuning
11:54 <+bridge_> <kebscs> Tunes are just bad design, idk if there's good way to display their info other than wall of text like dbg tuning command
11:54 <+bridge_> <gorp_tw> unless you have robot eyes
11:54 <+bridge_> <robyt3> https://github.com/ddnet/ddnet/issues/6134#issuecomment-1692266975
11:55 <+bridge_> <alw5> yes mbut its a fun map
11:55 <+bridge_> <gorp_tw> still you should be able to "spec" tunes
11:55 <+bridge_> <gorp_tw> no reason not to
11:55 <+bridge_> <gorp_tw> why should i have to get into the next part and maybe fail cus i didnt understand how the tune worked lol
11:55 <+bridge_> <gorp_tw> especially if its weird dummy stuff
11:55 <+bridge_> <alw5> on what map tho
11:55 <+bridge_> <gorp_tw> i really do not need an example here
11:55 <+bridge_> <alw5> this has never happened to me
11:55 <+bridge_> <gorp_tw> many dummy maps exist with tune
11:55 <+bridge_> <alw5> has it happened to u?
11:56 <+bridge_> <gorp_tw> it just doesnt matter, its qol
11:56 <+bridge_> <alw5> maybe i dont play enough dummy maps
11:56 <+bridge_> <gorp_tw> you fail once you mostly figure it out
11:56 <+bridge_> <gorp_tw> this is a qol feature
11:56 <+bridge_> <alw5> yea i understand
11:56 <+bridge_> <gorp_tw> and again, you open the map in the editor and you fully understand how the map works
11:56 <+bridge_> <alw5> but i also dont want this feature forced on me
11:56 <+bridge_> <gorp_tw> so this is purely convenience
11:56 <+bridge_> <gorp_tw> that's why i said it should be default off
11:56 <+bridge_> <manikoo> normal maps show you where is tune and what it changes
11:56 <+bridge_> <gorp_tw> but i think deduplicated numbering should be default
11:57 <+bridge_> <gorp_tw> because everything else gets numbers
11:57 <+bridge_> <alw5> true like turn off entities
11:57 <+bridge_> <gorp_tw> we pick on the poor tunezones for no reason bro
11:57 <+bridge_> <gorp_tw> its just weird to decide where to show a number if we flood-fill it
11:57 <+bridge_> <gorp_tw> if we do the corner that's often going to be not easily visible or actually covered up fully by some solid cus the mapper is stupid
11:58 <+bridge_> <gorp_tw> and having to check for a place that is "visible" sounds like integration hell and a terrible aspect of a feature to me
11:58 <+bridge_> <alw5> i mean there are some oldschools that spam buttons where ur playing
11:58 <+bridge_> <alw5> and it fills ur screen and makes it unplayable in entities
11:58 <+bridge_> <alw5> which is why i dont want the same with tunes
11:58 <+bridge_> <gorp_tw> it would be one number per region by default man idk why this feels like unplayable to u
11:59 <+bridge_> <gorp_tw> or even a color
11:59 <+bridge_> <manikoo> on some maps you just have to do it, look at one way freeze for example
11:59 <+bridge_> <alw5> well buttons arent displayed the same in entities
11:59 <+bridge_> <gorp_tw> im not talking about buttons
11:59 <+bridge_> <gorp_tw> stoppp
11:59 <+bridge_> <alw5> if connected buttons only showed 1 number it would be nice
12:00 <+bridge_> <gorp_tw> THAT IS WHAT I AM SAYING are u ragebaiting rn?
12:00 <+bridge_> <alw5> yes im saying its not consistant with buttons and other things
12:00 <+bridge_> <manikoo> no ragebait at all
12:00 <+bridge_> <gorp_tw> im only talking about tune and im suggesting yes you ahve one number per region
12:00 <+bridge_> <gorp_tw> it could ofc be added to switch layer but that is outside the scope of this PR
12:00 <+bridge_> <gorp_tw> but you have to decide where to stick the number and it seems basically impossible to reliably pick  a good spot to me
12:01 <+bridge_> <manikoo> make demo and #town-hall thread
12:02 <+bridge_> <gorp_tw> if the number was tiny and showed behind tees idk if it would really be that bad to show on all tiles
12:02 <+bridge_> <gorp_tw> if it really is that bad then all of it can be non-default
12:02 <+bridge_> <gorp_tw> maybe default debug menu behavior is to show it though
12:04 <+bridge_> <alw5> also what does showing color/number add
12:04 <+bridge_> <gorp_tw> telling you what the tune is
12:05 <+bridge_> <alw5> but you still need to look at the map/dbg_tuning ?
12:05 <+bridge_> <gorp_tw> you still have to learn what the tune is when you're in it, either experience/check map/dbg_tuning
12:05 <+bridge_> <gorp_tw> when you continue to see it you know what it does
12:06 <+bridge_> <gorp_tw> i think showing all the tune messages is worse, there's no way you're gonna fit some of my maps on your screen
12:07 <+bridge_> <alw5> what if we made it so if you spec and have dbg_tunings enabled it displays the tune of the tile at the centre of ur screen
12:07 <+bridge_> <gorp_tw> yea i thought about this
12:07 <+bridge_> <gorp_tw> might be good to show the list on spec as well
12:07 <+bridge_> <alw5> i guess but are tunes actually really connected  that much?
12:07 <+bridge_> <alw5> (except oco)
12:07 <+bridge_> <gorp_tw> wdym connected?
12:08 <+bridge_> <gorp_tw> in regions? almost always
12:08 <+bridge_> <alw5> different tunes
12:08 <+bridge_> <alw5> maybe i dont play enough corneum maps
12:08 <+bridge_> <gorp_tw> idk what corneum has to do with anything xd
12:08 <+bridge_> <alw5> he makes wacky maps
12:08 <+bridge_> <gorp_tw> you can use an arbitrary number of tunes per tile
12:08 <+bridge_> <alw5> yea
12:09 <+bridge_> <gorp_tw> but i still dunno what u mean by connected
12:09 <+bridge_> <alw5> so what does it actually help then it just tells you that u entered a different tunezone?
12:10 <+bridge_> <gorp_tw> when you spec/see it you know it's different
12:10 <+bridge_> <gorp_tw> if it doesn't match another color/number you've already worked out
12:10 <+bridge_> <gorp_tw> same as the editor honestly
12:10 <+bridge_> <gorp_tw> when im editing i know what the numbers all mean while im editing it
12:10 <+bridge_> <alw5> yea i see
12:10 <+bridge_> <gorp_tw> jump and you go high
12:10 <+bridge_> <gorp_tw> wow that's number 1
12:10 <+bridge_> <gorp_tw> i see number 1 again, im  going to jump and go high again
12:12 <+bridge_> <alw5> so u dont need to check editor anymore i c
12:12 <+bridge_> <alw5> i feel like this is an issue with bad maps tho
12:12 <+bridge_> <alw5> if a map cannot notify u about a tunezone that can make u fail without having to enter is a bad map
12:13 <+bridge_> <gorp_tw> or (and maybe ive said this already) it's a qol feature no matter if the map is good or not
12:13 <+bridge_> <gorp_tw> it makes a bad map bearable and a good map great
12:14 <+bridge_> <gorp_tw> at least i dont have to check the editor if i feel like a map has intentionally bad tunes
12:14 <+bridge_> <alw5> yea
12:15 <+bridge_> <gorp_tw> we could have icons for groups of tune settings
12:15 <+bridge_> <gorp_tw> anything that affects hammer, hook, nade, etc
12:15 <+bridge_> <gorp_tw> and show it in a cluster
12:15 <+bridge_> <gorp_tw> seems messy to me though
12:18 <+bridge_> <gorp_tw> I think this layout would be the nicest looking to me
12:18 <+bridge_> <gorp_tw> 
12:18 <+bridge_> <gorp_tw> ⁨```
12:18 <+bridge_> <gorp_tw> 1-1-1
12:18 <+bridge_> <gorp_tw> -----
12:18 <+bridge_> <gorp_tw> 1-1-1```⁩
12:18 <+bridge_> <gorp_tw> Renders on every odd-indexed, odd-row tune that is connected in the same region
12:18 <+bridge_> <alw5> wasnt there a townhall post to add connected textures?
12:19 <+bridge_> <gorp_tw> 2x2 regions would have a number only in the top-left, centered inthe tile
12:19 <+bridge_> <gorp_tw> if that is a better visualization
12:19 <+bridge_> <gorp_tw> 2x2 regions would have a number only in the top-left, centered in the tile
12:22 <+bridge_> <alw5> how would it look in a part like this
12:22 <+bridge_> <alw5> https://cdn.discordapp.com/attachments/293493549758939136/1467480163636740106/DDNet_RAQpa12w9I.png?ex=698088e7&is=697f3767&hm=80cf858eb41ba97edc700dc112a2f651da9d1237aee55b154395a39fcf8c8430&
12:22 <+bridge_> <gorp_tw> one sec i gotta open a paint thing
12:22 <+bridge_> <alw5> i cant  really think if a good way to visualise it without making it hard to see/covering screen
12:25 <+bridge_> <gorp_tw> i started drawing boxes where there would be numbers
12:25 <+bridge_> <gorp_tw> https://cdn.discordapp.com/attachments/293493549758939136/1467480989029761227/image.png?ex=698089ac&is=697f382c&hm=ce7db4809c0ce99b7b640649c5f287fb35cfefa91e5b717f30f66454ba5a712c&
12:25 <+bridge_> <gorp_tw> if it clashes with a tele number, it should probably not be drawn
12:26 <+bridge_> <alw5> i feel like its too cluttered tho
12:26 <+bridge_> <gorp_tw> just the simplest way i could think of
12:26 <+bridge_> <gorp_tw> i think it would look fine
12:26 <+bridge_> <gorp_tw> entity spam is already ass with tele/switch
12:32 <+bridge_> <manikoo> entities mode is not made for comfortable gameplay imo
12:32 <+bridge_> <manikoo> use design if you need good looking game
12:55 <+bridge_> <alw5> how do features get merged?
12:55 <+bridge_> <alw5> do all maintainers need to agree or what
12:56 <+bridge_> <alw5> looking at https://github.com/ddnet/ddnet/pull/11482
12:56 <+bridge_> <alw5> it seems like assa is fine with it and roby is also but heinrich isnt a fan of it
12:56 <+bridge_> <alw5> if one vetos does it become instant decline?
12:59 <+bridge_> <alw5> or is there some hierarchy
13:00 <+bridge_> <aegisub> there's backlog about this here, the disagreement was not about wanting or not wanting this change, it was about wanting a concrete reason for it that's not just "other games do it" and "it could improve performance"
13:00 <+bridge_> <aegisub> i.e. actual benchmarks showing a performance difference
13:03 <+bridge_> <alw5> so why close it
13:05 <+bridge_> <alw5> @kebscs can you get benchmarks for it so heinrich can re open and merge it?
13:07 <+bridge_> <kebscs> cba
13:08 <+bridge_> <alw5> welp wont get merged then and people will always ask in this server on how to fix stuttering when in discord vc
13:08 <+bridge_> <kebscs> higher priority doesnt fix the stutter
13:08 <+bridge_> <kebscs> bcs it was still below discord
13:09 <+bridge_> <alw5> oh so the only way is to lower discord ?
13:09 <+bridge_> <kebscs> you could put ddnet above or same as discord
13:09 <+bridge_> <kebscs> but they didnt want it
13:10 <+bridge_> <alw5> the only higher priority is realtime right?
13:10 <+bridge_> <kebscs> i think its number 0 to 15
13:11 <+bridge_> <alw5> ic
13:12 <+bridge_> <aegisub> (for good reasons)
13:12 <+bridge_> <alw5> well henrich didnt want it because there was no actual benchmark that it actually improves anythhing
13:12 <+bridge_> <alw5> i know it improves with discord
13:13 <+bridge_> <kebscs> if blindly beleive win32 docs that are often wrong, why dont beleive it when it comes to performance and require benchmarks
13:17 <+bridge_> <aegisub> who's saying anyone blindly believes win32 docs
13:18 <+bridge_> <aegisub> you can choose not to believe them, in which case a reasonable policy is "by default do not change anything; require concrete evidence for every change"
13:19 <+bridge_> <robyt3> If you claim a change improves performance, you'll need to be prepared to be asked for benchmarks to back it up
13:19 <+bridge_> <aegisub> but if the docs say something should be avoided that's a good sign you should at least investigate more if you really want to do it
13:19 <+bridge_> <aegisub> you don't have to blindly trust them for that
13:20 <+bridge_> <kebscs> it cant be higher priority than discord bcs docs say its dangerous
13:20 <+bridge_> <aegisub> and even ignoring those docs, it's not outlandish to believe that a thread priority arms race will not solve anything
13:20 <+bridge_> <aegisub> just like you don't want discord to choke out ddnet you don't want ddnet to choke out discord voice calls
13:20 <+bridge_> <kebscs> but if it comes to bein higher than average we cant trust docs
13:20 <+bridge_> <aegisub> or obs if you're streaming
13:20 <+bridge_> <aegisub> or obs if you're streaming or recording
13:20 <+bridge_> <aegisub> etc
13:21 <+bridge_> <aegisub> I'm not saying any of the proposed solutions is automatically wrong, just that there are good reasons for wanting more information before making any change
13:23 <+bridge_> <kebscs> i know
13:23 <+bridge_> <kebscs> but this is some specific thing that doesnt magically increase fps
13:23 <+bridge_> <kebscs> i would need to overload pc with other apps
13:23 <+bridge_> <aegisub> then test that
13:24 <+bridge_> <aegisub> set up an environment that's as reproducible as possible and demonstrate how your change improves performance in this case
13:25 <+bridge_> <aegisub> this is only inconsistent if you treat making a change and not making a change as the same thing
13:25 <+bridge_> <aegisub> this is only inconsistent if you treat making a change and not making a change as equivalent
13:25 <+bridge_> <aegisub> but they're not
13:26 <+bridge_> <kebscs> to me, if its clear that its an improvement with no downside its a good change
13:26 <+bridge_> <kebscs> i dont care that much to setup an env and reproducible tests
13:26 <+bridge_> <aegisub> > if its clear that its an improvement
13:28 <+bridge_> <aegisub> and that's fine
13:28 <+bridge_> <kebscs> A typical strategy is to use THREAD_PRIORITY_ABOVE_NORMAL or THREAD_PRIORITY_HIGHEST for the process's input thread, to ensure that the application is responsive to the user.
13:28 <+bridge_> <aegisub> just, then you also have to understand that maintainers don't want to spend their time doing that either and hence will not merge your change
13:33 <+bridge_> <robyt3> This seems to be reported several times on the internet for other games and they all suggest changing Discord's priority without mentioning any negative effects from doing so, so to me it's clearly an issue with Discord that should be fixed on their side. I'd consider setting the priority of the Discord process ourselves until someone gets through to Discord's higher tier support.
13:33 <+bridge_> <totar> Ill merge thing in tclient if you want, AAA games doing it is good enough for me
13:33 <+bridge_> <totar> Ill merge this in tclient if you want, AAA games doing it is good enough for me
13:33 <+bridge_> <kebscs> sure, i can pr if you want
13:34 <+bridge_> <totar> Yeah, just mark any lines you change in ddnet files with // TClient so I can fix merge conflicts later
13:37 <+bridge_> <alw5> i doubt discord would ever fix this
13:37 <+bridge_> <aegisub> .
13:38 <+bridge_> <robyt3> So it's really an issue in the Windows scheduler that everyone tries to work around? :pepeW:
13:39 <+bridge_> <robyt3> I also found opposite reports of games using high priority and this making Discord calls choppy
13:39 <+bridge_> <kebscs> but making the priority higher to fix discord issue was rejected
13:39 <+bridge_> <kebscs> so it was just about upping the priority by 1
13:39 <+bridge_> <kebscs> (out of 30)
13:39 <+bridge_> <kebscs> (out of 31)
13:39 <+bridge_> <aegisub> yeah, exactly
13:39 <+bridge_> <aegisub> this change could very well have negative consequences
13:40 <+bridge_> <aegisub> *which is why more information is needed*
13:40 <+bridge_> <robyt3> I'm not opposed to that change if it's backed up by benchmarks
13:40 <+bridge_> <kebscs> its very spicific, i dont want to make bennchmarks for smth like that
13:40 <+bridge_> <robyt3> This thing reminds me of how we are still not marked as "compatible with Windows 10/11" because it caused a performance regression last time
13:41 <+bridge_> <kebscs> 1 priority could be not noticeable
13:41 <+bridge_> <robyt3> +1 is definitely noticeable to the scheduler?
13:41 <+bridge_> <totar> Marked by who?
13:42 <+bridge_> <robyt3> In one of the Windows manifest files, see #7263 #7508
13:42 <+bridge_> <DDNet> https://github.com/ddnet/ddnet/pull/7263
13:42 <+bridge_> <DDNet> https://github.com/ddnet/ddnet/pull/7508
13:42 <+bridge_> <totar> oh
13:43 <+bridge_> <alw5> https://discord.com/channels/252358080522747904/757720336274948198/1175913806703108246
13:43 <+bridge_> <robyt3> This means the system tries to run the game in whatever compatibility mode it sees best fitting for Windows Vista/7
13:44 <+bridge_> <totar> do other games use this?
13:45 <+bridge_> <robyt3> I don't know, but it would be the result of just following what the documentation says
13:45 <+bridge_> <robyt3> https://learn.microsoft.com/en-us/windows/win32/sysinfo/targeting-your-application-at-windows-8-1
13:46 <+bridge_> <totar> Its possible the user has some cursed gpu driver  setting that gets disabled because its incompatible with win7 programs or something like that
13:46 <+bridge_> <totar> or like windows resolution scaling or something
13:47 <+bridge_> <robyt3> I also suspect it's some driver thing
13:47 <+bridge_> <learath2> Do other games set their own priority higher?
13:47 <+bridge_> <totar> there were examples in the pr or issue iirc
13:49 <+bridge_> <robyt3> https://github.com/ddnet/ddnet/issues/11473#issuecomment-3683298846
13:53 <+bridge_> <learath2> Hm, I guess a game wanting higher priority than usual sounds sane at least. The discord issue however could probably also be fixed by just moving it to an isolated thread. The priority change fixing it just sounds like an issue with accidental coupling between the two applications due to the bridge
16:08 <+bridge_> <remakepower> Wait a minute
16:09 <+bridge_> <remakepower> The demo could record net message???
16:13 <+bridge_> <remakepower> :thonk:
16:15 <+bridge_> <manikoo> demo records everything
16:15 <+bridge_> <robyt3> Demos can record snapshots and messages. For example chat and broadcasts are messages
16:16 <+bridge_> <remakepower> oops
16:20 <+bridge_> <remakepower> ah
16:20 <+bridge_> <remakepower> I see
16:36 <+bridge_> <aegisub> the c++ core guidelines disagree 🤓 <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#enum5-dont-use-all_caps-for-enumerators>
16:37 <+bridge_> <aegisub> but yes it's consistent with the rest of the codebase
17:00 <+bridge_> <chillerdragon> @aegisub: oh nice guidelines maybe we should follow some of them
17:00 <+bridge_> <chillerdragon> For the enum casing they saw a problem I actually ran into
17:00 <+bridge_> <aegisub> I don't agree with all of them, but most of them are good
17:01 <+bridge_> <chillerdragon> When linking against ncurses I conflict with some color constants in DDNet
17:49 <+bridge_> <robyt3> ⁨```
17:49 <+bridge_> <robyt3> src/base/math.h:14:22: warning: prefer 'std::numbers::pi_v<float>' to this literal, differs by '8.74e-08' [modernize-use-std-numbers]
17:49 <+bridge_> <robyt3>    10 | 
17:49 <+bridge_> <robyt3>    11 | template<typename T>
17:49 <+bridge_> <robyt3>    12 | concept Numeric = std::integral<T> || std::floating_point<T>;
17:49 <+bridge_> <robyt3>    13 | 
17:49 <+bridge_> <robyt3>    14 | constexpr float pi = 3.1415926535897932384626433f;
17:49 <+bridge_> <robyt3>       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
17:49 <+bridge_> <robyt3>       |                      std::numbers::pi_v<float>
17:49 <+bridge_> <robyt3> ```⁩
17:49 <+bridge_> <robyt3> 
17:49 <+bridge_> <robyt3> I'm afraid I can't let you do that, clang-tidy. :justatest:
18:10 <+bridge_> <melon> :pepe_cry:
18:49 <+bridge_> <remakepower> when we could add something like this?
18:49 <+bridge_> <remakepower> https://cdn.discordapp.com/attachments/293493549758939136/1467577490003202260/image.png?ex=6980e38b&is=697f920b&hm=7a1e60b31d1f817916383c03e15b144c0fd949939f0f75fdd3846a4619223f11&
18:54 <+bridge_> <louis> why not ctrl c in f1
18:55 <+bridge_> <robyt3> See #9830
18:55 <+bridge_> <DDNet> https://github.com/ddnet/ddnet/issues/9830
18:56 <+bridge_> <louis> oh actually clickable names would be great
18:58 <+bridge_> <remakepower> Ah
18:58 <+bridge_> <remakepower> also #9919
18:58 <+bridge_> <DDNet> https://github.com/ddnet/ddnet/issues/9919
18:58 <+bridge_> <remakepower> :3
19:00 <+bridge_> <12944qwerty> I was thinking about having it colored if it was only a "send message" tune and possibly a third color if it does both message and physics. 
19:00 <+bridge_> <12944qwerty> But I'm not sure how to really separate them by regions or get the tunings, especially in shaders.
19:00 <+bridge_> <12944qwerty> 
19:00 <+bridge_> <12944qwerty> Is it possible to get a tunes commands in console?
19:02 <+bridge_> <robyt3> You can already see active tunes with ⁨`dbg_tuning 1`⁩ and ⁨`dbg_tuning 2`⁩, see #6985
19:02 <+bridge_> <DDNet> https://github.com/ddnet/ddnet/pull/6985
20:38 <+bridge_> <melon> Man I miss Ryo and jupstis rust talk
20:38 <+bridge_> <melon> :cammo:
20:58 <+bridge_> <learath2> I hope Jupsti forgives us some day
21:05 <+bridge_> <manikoo> 😭
21:15 <+bridge_> <manikoo> chiller you know i remember that you made some tee without hammer support for one of your clients
21:15 <+bridge_> <manikoo> wouldn't it be nice to just don't take hammer from player if you cannot use it
21:15 <+bridge_> <manikoo> wouldn't it be nice to just take hammer from player if you cannot use it
21:16 <+bridge_> <manikoo> sounds bad because hammer is basic weapon as pistol
21:16 <+bridge_> <manikoo> but idk
21:47 <+bridge_> <chillerdragon> @manikoo: every 0.6 client supports no hammer and that’s exactly what I proposed
21:47 <+bridge_> <chillerdragon> 0.7 too
21:48 <+bridge_> <manikoo> see!
21:49 <+bridge_> <manikoo> great idea
21:52 <+bridge_> <chillerdragon> Forgive what exactly?
21:53 <+bridge_> <learath2> Idk any specifics but if he forsook us we must have done something wrong
21:54 <+bridge_> <chillerdragon> Hm
22:19 <+bridge_> <chairn> what did we do though ?
22:20 <+bridge_> <chairn> ah nvm 🙂
22:21 <+bridge_> <gorp> see the hammer shield issue