03:52 < bridge> <gorp_tw> good evening developer
03:53 < bridge> <gorp_tw> @blazulite :justatest:
03:56 < bridge> <blazulite> 😈
03:57 < bridge> <gorp_tw> she WILL redesign every visible pixel that is remotely related to ddnet
03:57 < bridge> <gorp_tw> no texture or font unturned
03:57 < bridge> <blazulite> if I ever had the permission😔
03:58 < bridge> <gorp_tw> I think your designs are helpful
04:27 < bridge> <gorp_tw> i want multiple custom color algorithms sdjgfsdgshg raaaaa
04:27 < bridge> <gorp_tw> like if something is greyscale dont touch it :(
08:06 < bridge> <gorp_tw> pro
10:26 < bridge> <blazulite> Ty for the inspo btw
10:26 < bridge> <blazulite> (The bg artwork is a placeholder)
10:26 < bridge> <blazulite> https://cdn.discordapp.com/attachments/293493549758939136/1372490274550583337/image.png?ex=6826f6ad&is=6825a52d&hm=45835d2f607b822b5b3a27ecf4f40cbdfca2e0ba193aa97092dd1a6f26c23d09&
10:35 < bridge> <pioooooo> is rust used anywhere in the codebase other than stopping me cross compiling from m1 to arm64 windows
10:36 < bridge> <pioooooo> https://cdn.discordapp.com/attachments/252358080522747904/1348432057042206922/C60DF6305554C32B4DCAF4EEEB89DF2E.gif
10:38 < bridge> <ryozuki> u can cross compile with rust
10:48 < bridge> <pioooooo> im just bad
11:36 < bridge> <Assa> time to improve all our 4x4 matrix multiplications
11:51 < bridge> <Assa> is it possible to do an inverse corner rect in ddnet?
11:52 < bridge> <Assa> like only an inside corner
11:52 < bridge> <Assa> (I am talking about UI to be clear)
12:37 < bridge> <robyt3> No. There used to be constants for inner corners but they never worked correctly and were removed.
13:12 < bridge> <Assa> @jupeyy_keks any opinions?
13:13 < bridge> <Assa> https://cdn.discordapp.com/attachments/293493549758939136/1372532210292494420/screenshot_2025-05-15_13-12-12.png?ex=68271dbb&is=6825cc3b&hm=8f09060815efa0f0bce73ee624e4a6925a169b2b821106ecda8f8336141819b5&
13:13 < bridge> <Assa> Still only a mock ^.^
13:39 < bridge> <kebscs> Black eye looks weird
13:46 < bridge> <Assa> I guess the outline is too strong on this ^^
14:11 < bridge> <Jupstar ✪> more decent, but as i teased in the issue, i don't yet see the reason to colorize at all.
14:11 < bridge> <Jupstar ✪> 
14:11 < bridge> <Jupstar ✪> badly matching colors always make the app look cheap.
14:11 < bridge> <Jupstar ✪> 
14:11 < bridge> <Jupstar ✪> but tbh ask some graphics designer or artist. they can easily judge if it looks bad or not color wise and/or if the colors are cleanly enough separated from the overall editor ui
14:12 < bridge> <Jupstar ✪> more decent, but as i teased in the issue, i don't yet see the reason to colorize at all.
14:12 < bridge> <Jupstar ✪> 
14:12 < bridge> <Jupstar ✪> badly matching colors always make the app look cheap.
14:12 < bridge> <Jupstar ✪> 
14:12 < bridge> <Jupstar ✪> but tbh ask some graphics designer or artist. they can easily judge if it looks bad or non-matching color wise and/or if the colors are cleanly enough separated from the overall editor ui
14:13 < bridge> <Jupstar ✪> The color you show rarely matches the color you see ingame (since it's multiplied with a texture and that texture is often not pure white)
14:36 < bridge> <Assa> Huh this map might be a selection bias since it colors a white tileset a lot 🤔 I see your point. I ignored white here, because of this reason
14:36 < bridge> <soulyvevo> is the color linked to layer color?
14:37 < bridge> <soulyvevo> might not really be helpful if you use precolored tilesets
14:38 < bridge> <louis> ye i think being able to set color is probably better for ppl who want to beorganized
14:39 < bridge> <louis> also u could try making the color a gradient from the right side instead of coloring the entire box
14:40 < bridge> <learath2> I do not know how uuseful this is, an assigned color might be more interesting for people to organize layers, though storing it would require a way to extend the map format
14:42 < bridge> <Assa> for me this improves readability a lot, since I can identify a layer directly by color, scrolling through 60 groups and then looking for the green one is easier, than scrolling through 60 groups and looking for the word "leaves"
14:42 < bridge> <Assa> for me this improves readability a lot, since I can identify a layer directly by color, scrolling through 60 groups and then looking for the green one is easier, than scrolling through 60 groups and looking for the word "leafes"
14:42 < bridge> <Jupstar ✪> add a search bar ^^
14:42 < bridge> <Jupstar ✪> or better grouping
14:43 < bridge> <soulyvevo> i think it would look more appealing if we had the colors assigned automatically based on layer id
14:44 < bridge> <soulyvevo> or maybe even based on group name
14:44 < bridge> <Assa> layer ID changes if you move it around
14:44 < bridge> <Assa> so the color would change with it
14:44 < bridge> <soulyvevo> then maybe group names would be better
14:44 < bridge> <soulyvevo> like converting the group name to some random color
14:44 < bridge> <soulyvevo> or rather a hue
14:45 < bridge> <soulyvevo> and brightness and seturation could be the same for all so that we dont end up with some eye burning colors
14:49 < bridge> <Assa> what do you mean by grouping? Introducing meta groups would also change the map format. I have a lot of groups, that want to be one, but can't because if clip regions or pos x/pos y values, like this properties would be better for tilelayers instead of groups
15:06 < bridge> <soulyvevo> so umm i quickly edited the colors in gimp and i think this is something i could work with
15:06 < bridge> <soulyvevo> https://cdn.discordapp.com/attachments/293493549758939136/1372560742603161672/editor_groups.png?ex=6827384d&is=6825e6cd&hm=8a5d7aa6f1eb5a12d3e5226d8a13c72aba422c69fb2c2bc464387de6ec379084&
15:06 < bridge> <soulyvevo> honestly could be even less saturated
15:11 < bridge> <oxyzo.> The depressing editor update
15:12 < bridge> <soulyvevo> :feelsbadman:
15:31 < bridge> <kebscs> not bad if these are preset colors
15:31 < bridge> <kebscs> imo colors based on layer color isnt great
15:44 < bridge> <qxdfoxy> fixed saturation
16:36 < bridge> <Solly (bun bun)> what should i do for NAN and INFINITY constants
16:37 < bridge> <Solly (bun bun)> i used -INFINITY in nameplates but NAN wouldve sufficed
16:49 < bridge> <kebscs> bump #9793
16:49 < bridge> <DDNet> https://github.com/ddnet/ddnet/pull/9793
16:52 < bridge> <learath2> Very pastel, very demure
16:54 < bridge> <Solly (bun bun)> lmao
16:57 < bridge> <learath2> I still feel it would be more useful to let people color their layers how they like as metadata
17:02 < bridge> <louis> i agree
17:02 < bridge> <louis> give a set of 8 or so colors that u can apply with a simple button
17:57 < bridge> <gorp_tw> gonna slap you for saying demure
17:57 < bridge> <gorp_tw> get off tumblr
18:00 < bridge> <gorp_tw> holy fuck people are trolling here
18:01 < bridge> <gorp_tw> @kebscs If you let louis convince you that tune should be additive you're taking the kids
18:02 < bridge> <kebscs> ?
18:04 < bridge> <gorp_tw> tune must be stateful, it makes no sense to compare pickups to tune as louis has because there's very clear indicators in the UI/on your tee for ity
18:04 < bridge> <gorp_tw> tune must be stateful, it makes no sense to compare pickups to tune as louis has because there's very clear indicators in the UI/on your tee for it
18:05 < bridge> <gorp_tw> with tune there's no fucking way to tell, not even in entities xD
18:05 < bridge> <gorp_tw> so yeah it should 100% replace your entire tunelock, dont listen to him please
18:05 < bridge> <gorp_tw> if you're going to have people opening the editor to find out what insane algebraic equation results in their current tune then go for it
18:06 < bridge> <gorp_tw> also testing becomes a nightmare
18:06 < bridge> <gorp_tw> 1 tunelock off = guaranteed no tune skips
18:06 < bridge> <kebscs> yea true
18:06 < bridge> <gorp_tw> ALSO there should be text entities for tune
18:07 < bridge> <gorp_tw> why they've been missing for years idk
18:07 < bridge> <kebscs> idk why theyre so fixated on it being additive
18:07 < bridge> <kebscs> i dont see any benefits from it
18:07 < bridge> <gorp_tw> I understand at the least that players wont know which tune is which
18:07 < bridge> <gorp_tw> but we have tune_zone_enter, and once the player knows which number does what, it's pretty easy at that point to continue to play
18:08 < bridge> <gorp_tw> idk, you have the correct opinion though, stay winning
18:08 < bridge> <gorp_tw> how would normal tune interact with locktune? both apply or its like current implementation where the tune you're standing in takes priority?
18:09 < bridge> <gorp_tw> how would normal tunezones interact with locktune? both apply or its like current implementation where the tune you're standing in takes priority?
18:09 < bridge> <kebscs> i think lock took priorioty
18:09 < bridge> <kebscs> i think lock took priority
18:09 < bridge> <gorp_tw> that might be confusing to players, but you are describing it as "lock" tune
18:09 < bridge> <gorp_tw> ive mentioned this in the past as simply "player tune"
18:10 < bridge> <gorp_tw> so i guess your naming makes sense
18:10 < bridge> <gorp_tw> regardless, i think applying both or making the tunezone take priority, but obviously with the latter, the mapping capabilities are more limited now
18:11 < bridge> <gorp_tw> applying both would let you do fun stuff, and let ppl do the "stacking" stuff in a limited way
18:12 < bridge> <kebscs> cant apply both
18:13 < bridge> <gorp_tw> on a personal note, ive wanted per-player tune for years, it's made me stop mapping at many points because what i need to do for the maps im making simply isnt possible, so if this is merged im really happy :3
18:30 < bridge> <learath2> I'm trying my best not to get old man status
18:34 < bridge> <Jupstar ✪> Learath is so old, is is basically already reborn and 12
18:35 < bridge> <meloƞ> Can't blame him, I'd take reincarnation any time
18:57 < bridge> <milkeeycat> Btw, what does move semantics change, does it not copy the whole struct from one place in memory to another?
19:14 < bridge> <learath2> I guess what I meant was copy elision, not move semantics, but you kinda need to implement both for pass by values to not need to create copies when not needed
19:43 < bridge> <louis> it should 0% replace your tunelock
19:43 < bridge> <louis> tune override should be additive too
19:43 < bridge> <louis> it makes it easier for modders
19:46 < bridge> <louis> a + b + c isn't an insane algebraic equation but maybe im the only one who passed elementary
19:46 < bridge> <louis> > Your mapping approach would only make sense if the goal was to find all powerups in random order. But since all maps are just about getting from start to finish, you could give a player some values and later give it again with more values
19:46 < bridge> <louis> not all maps are linear
19:47 < bridge> <louis> > That’s literally the point of a tune lock, to allow different players to have different tunes in the same place. If it’s ignored, there’s no way to apply tunes to just one player unless you keep splitting players into separate sections.
19:47 < bridge> <louis> 
19:47 < bridge> <louis> I think it's bad mapping practice and bad gameplay to have a public tile give different powerups to two players in the same location
19:47 < bridge> <louis> this makes keeping track of ur tunes even worse tbf. "Did u grab lock before? If so then u cant go here. please check"
19:47 < bridge> <kebscs> ok then i can change it
19:47 < bridge> <kebscs> if so
19:47 < bridge> <kebscs> but additive is bs
19:48 < bridge> <louis> nah
19:48 < bridge> <louis> ill argue later
19:48 < bridge> <kebscs> i dont want argue
19:48 < bridge> <kebscs> just decide on 1
19:48 < bridge> <kebscs> ure just blocking a pr
19:48 < bridge> <kebscs> just decide on 1 and i implement
19:48 < bridge> <louis> i wouldve blocked a lot of prs in the past if i was able to
19:48 < bridge> <louis> or at least try to make my case for a different implementation
19:48 < bridge> <louis> i think this is smth u need to gather mapper opinion abt
19:48 < bridge> <louis> + modder opinion
19:48 < bridge> <gorp_tw> i wouldnt even mind if i could understand your position but it still doesnt make sense to me
19:49 < bridge> <gorp_tw> i guess yeah
19:49 < bridge> <louis> weapons arent exclusive on pickup so neither should tunes IMO
19:49 < bridge> <gorp_tw> how is it not more confusing this way
19:49 < bridge> <louis> they belong to the same class of powerup
19:49 < bridge> <louis> idk how u can argue against that
19:50 < bridge> <gorp_tw> Isn't this for replacement and not against?
19:50 < bridge> <gorp_tw> if Player A gets tunelock X and Player B gets tunelock Y, and both go through tunelock Z, they have diverged
19:51 < bridge> <gorp_tw> the mental load for both mappers and players is less if we allow text entities for tune and just have it replace your lock
19:53 < ws-client> <ChillerDragon> vanilla master down again?
19:54 < ws-client> <ChillerDragon> #nofilter
19:54 < ws-client> <ChillerDragon> https://zillyhuhn.com/cs/.1747331629.png
19:54 < bridge> <robyt3> #6134
19:54 < bridge> <DDNet> https://github.com/ddnet/ddnet/issues/6134
19:54 < ws-client> <ChillerDragon> last zcatch server alve
19:57 < bridge> <gorp_tw> ya i didnt know if there was an issue already
19:58 < bridge> <gorp_tw> I would be happy even if it was ctrl+shift+d only
20:04 < bridge> <louis> u can see tunings in debug
20:04 < bridge> <inv41idu53rn4m3> Can't we just like... have both? Have both additive and full replacement tunes
20:05 < bridge> <inv41idu53rn4m3> because the idea of stackable pick-ups seems super fun for nonlinear maps
20:06 < bridge> <learath2> Additive tunes is a large prediction issue that'll require a lot of thinking
20:07 < bridge> <inv41idu53rn4m3> are the borders of tune zones predicted properly?
20:09 < bridge> <learath2> Not yet, but there was a proposal to fix it iirc
20:11 < bridge> <inv41idu53rn4m3> I was just thinking that if prediction is only based on current tune then it should work just fine even if current tune is calculated in a more complicated way
20:12 < bridge> <gorp_tw> I really don't think it makes much of a difference... it's just a headache for no reason
20:13 < bridge> <gorp_tw> and this is coming from someone who extensively uses tune
20:13 < bridge> <gorp_tw> maybe more than any other person
20:13 < bridge> <gorp_tw> there's ofc stuff you cant do without additive, but most cases you want are covered by replacement
20:14 < bridge> <gorp_tw> and if you need to reset someone's tunelock to a previous state, you can use CP logic for that
20:15 < bridge> <kebscs> would need to rewrite how tunes work for this
20:15 < bridge> <kebscs> client just knows about tunes on map and predicts based on that
20:15 < bridge> <kebscs> if everyone would have additive compeletly random values you would need huge snaps for evey player to predict correctly
20:16 < bridge> <inv41idu53rn4m3> oh right
20:17 < bridge> <inv41idu53rn4m3> then again, if we didn't send snapshots that contain *everything* all the time...
20:17 < bridge> <inv41idu53rn4m3> but that's an even bigger change
20:18 < bridge> <learath2> Yes, major rework that is very likely to accidentally break stuff
20:19 < bridge> <kebscs> then why they fight for additive tunes that arent going to happen?
20:21 < bridge> <learath2> Because it is actually more useful to them. I can see additives being far easier to use for mappers
20:22 < bridge> <kebscs> but more confusing to players
20:22 < bridge> <learath2> I doubt that. Either is very confusing to players anyway
20:22 < bridge> <learath2> Randomly a tune zone gets applied to you and won't change when you get into other tune zones
20:24 < bridge> <kebscs> yea thats the point
20:25 < bridge> <kebscs> imo this should be used to apply the lock to players once and thats it
20:25 < bridge> <kebscs> like dummy map with 0 grav dummy for half the map
20:27 < bridge> <inv41idu53rn4m3> I think this is down to just good mapping
20:27 < bridge> <inv41idu53rn4m3> though I guess it'd be easier if we could hide quads when the player has a certain tune locked, so we could make pick-ups look like actual pick-ups
20:30 < bridge> <kebscs> no visual indicator means they shouldnt be used as powerups is what i mean
20:31 < bridge> <ryozuki> https://blog.rust-lang.org/2025/05/15/Rust-1.87.0/
20:35 < bridge> <Ewan> kebs HATES safe architecture intrinsics
20:36 < bridge> <Ewan> recently i’ve been wanting pop_if and such for queue/stack based types
20:37 < bridge> <Ewan> u can take a reference to it first but if you’re intending to pop conditionally you can’t do it in any sort of FnOnce method after because it creates mutable borrowship issued
20:37 < bridge> <Ewan> u can take a reference to it first but if you’re intending to pop conditionally you can’t do it in any sort of FnOnce method after because it creates mutable borrowship issues
20:37 < bridge> <Ewan> gotta assign it first
20:39 < bridge> <louis> its only 8 ints per person (if 256 tunes are used)
20:39 < bridge> <louis> true but all tune sneed visuals imo
20:39 < bridge> <Ewan> sneed
20:39 < bridge> <louis> i think additive + separate tiles that lock and unlock would work for both
20:40 < bridge> <louis> well idk. then it gets rly rly complicated since its complicated on top of complicated
20:40 < bridge> <louis> you're right in that most maps only need a dummy tune at the start etc. but i can see additive being nice for modders and some maps for non ddr modes
20:41 < bridge> <louis> its only 8 ints per person