00:56 <+bridge_> <gorp_tw> wow i need to read tile PRs more, i didnt know bullets activate targets
00:56 <+bridge_> <gorp_tw> that's actually huge
00:57 <+bridge_> <gorp_tw> basically you can do solo maps without requiring dummy
00:57 <+bridge_> <gorp_tw> for stuff like Machine
02:21 <+bridge_> <12944qwerty> bumppppp
02:21 <+bridge_> <12944qwerty> please help
02:21 <+bridge_> <12944qwerty> ~~Might have to do with the fact that i'm pretty sure it's not building correctly?
02:21 <+bridge_> <12944qwerty> No errors, but any changes I make aren't shown. Strings edits for example~~
02:21 <+bridge_> <12944qwerty> ~~this happens even when I rm -rf the build directory too~~
02:21 <+bridge_> <12944qwerty> ~~btw, even though the vulkan error happened before, it used to update whatever I was changing about a week ago~~
02:21 <+bridge_> <12944qwerty> ~~correction, seems like it doesn't build for src/game/map/render_map.cpp specifically~~
07:36 <+bridge_> <gorp_tw> huh fokko did his own tunelock? xx-x
07:36 <+bridge_> <gorp_tw> huh fokko did his own tunelock? x-x
07:37 <+bridge_> <gorp_tw> seems his is additive or was
07:37 <+bridge_> <gorp_tw> i really wish tunelock was handled separate, so tunezones can still apply
08:49 <+bridge_> <alw5> #1922
08:49 <+bridge_> <DDNet> https://github.com/ddnet/ddnet/pull/1922
09:29 <+bridge_> <gorp> always: is this what makes hammer stronger the tick you're unfrozen?
09:30 <+bridge_> <gorp> basically, the buffered hammer
09:31 <+bridge_> <blaiszephyr> It's what made it possible to hold hammer while in freeze
09:31 <+bridge_> <blaiszephyr> Also called the heinohammer :froggo_sip:
09:44 <+bridge_> <gorp> ye I understood that
09:44 <+bridge_> <gorp> but i always wondered what makes the buffered hammer stronger, maybe it always was from when freeze was first added, not after this
10:02 <+bridge_> <alw5> what
10:03 <+bridge_> <alw5> like when you exit freeze
10:03 <+bridge_> <alw5> ur hammer is stronger?
10:10 <+bridge_> <totar> no
10:10 <+bridge_> <totar> hammering while frozen used to be a tick perfect timing
10:10 <+bridge_> <totar> you had to press shoot on the same tick you got unfrozen
10:10 <+bridge_> <totar> this made it easy
10:11 <+bridge_> <totar> the issue imo isn't really that it was tick perfect, but rather that it's impossible to react in 20ms
10:25 <+bridge_> <manikoo> skill issue
10:36 <+bridge_> <fushi_gg> I tried but haven't seen a way on how to extract the alpha for the slider anywhere else in the code so not sure if what I did is the way to go about it
10:47 <+bridge_> <Assa> uhm I'd also need to look it up, do you know if you can convert it into ColorRGBA?
10:50 <+bridge_> <fushi_gg> I have put it in my PR if you mind reviewing https://github.com/ddnet/ddnet/pull/11771/changes/91c0a1cf567d33ecf55c6425f7996c9cd4a3365d
10:57 <+bridge_> <learath2> You seem to be holding colors wrong, you don't want to pass an int around like that, pass the tipcolor as `const ColorRGBA &` instead
10:58 <+bridge_> <robyt3> You are already using a color picker to select the color including alpha, so a second scrollbar for the alpha is unnecessary
10:59 <+bridge_> <fushi_gg> but since on the menu all the other color options do not this would be better not to confuse people?
11:00 <+bridge_> <robyt3> I don't see any that do this. Colors that have alpha only use one color picker
11:01 <+bridge_> <fushi_gg> yes I am saying the other hook line color customizations do not support alpha
11:01 <+bridge_> <learath2> (The components of a color are public members, so you can just get the alpha with `Color.a`)
11:01 <+bridge_> <fushi_gg> so users would have 3 color pickers not supporting alpha but one that has alpha
11:01 <+bridge_> <robyt3> That's fine, but we don't need separate color pickers and scrollbars for the same value
11:03 <+bridge_> <fushi_gg> I get that but like I said isn't this a little confusing for the user? if someone would want to turn hide the line tip there wouldn't be a straightforward way of doing so
11:04 <+bridge_> <robyt3> They can open the color picker and change alpha to zero. Just like for other colors settings like the UI color. It's more confusing and unnecessarily complex to have two UI elements that control the same value.
11:05 <+bridge_> <fushi_gg> will remove it
11:06 <+bridge_> <robyt3> Also, did you check the default value? Looks like you are enabling alpha for an existing setting, but the default is not adjusted, so is it transparent now? I think this should also handle user configs where the value was set without alpha.
11:07 <+bridge_> <fushi_gg> I did not
11:07 <+bridge_> <learath2> It's a new setting, it's just a commit that isn't squashed down
11:08 <+bridge_> <robyt3> But it also gets removed again? I usually look at the final diff
11:08 <+bridge_> <learath2> At one point he implemented it with 2 configs, alpha and color
11:08 <+bridge_> <fushi_gg> yes but I was told not to do 2 configs
11:08 <+bridge_> <learath2> Then the last commit merged them, making it appear as if the color was an existing setting
11:09 <+bridge_> <learath2> Yeah, it's better to have 1, just be careful that your default has an alpha now
11:09 <+bridge_> <learath2> Yeah, it's better to have 1, just be careful that your default needs an alpha now
11:09 <+bridge_> <fushi_gg> I did not, but it does have 100 alpha
11:11 <+bridge_> <fushi_gg> I did not, will fix
11:11 <+bridge_> <robyt3> You can replace
11:11 <+bridge_> <robyt3> ```cpp
11:11 <+bridge_> <robyt3> g_Config.m_ClConfigVersion = 1;
11:11 <+bridge_> <robyt3> ```
11:11 <+bridge_> <robyt3> with something like
11:11 <+bridge_> <robyt3> ```cpp
11:11 <+bridge_> <robyt3> if(g_Config.m_ClConfigVersion < 2)
11:11 <+bridge_> <robyt3> {
11:11 <+bridge_> <robyt3>     // Repack color because alpha component was added
11:11 <+bridge_> <robyt3>     g_Config.m_ClHookCollColorTipColl = ColorRGBA(g_Config.m_ClHookCollColorTipColl, false).Pack(true);
11:11 <+bridge_> <robyt3> }
11:11 <+bridge_> <robyt3> g_Config.m_ClConfigVersion = 2;
11:11 <+bridge_> <robyt3> ```
11:11 <+bridge_> <robyt3> to properly migrate users' configs.
11:11 <+bridge_> <fushi_gg> g_Config.m_ClHookCollColorTipColl this is a new setting
11:12 <+bridge_> <robyt3> hmm :thonk:  apparently GitHub just gave me an imcomplete diff. Should be bug 3 or 4 of the new PR experience :pepeW:
11:13 <+bridge_> <fushi_gg> I will look up how to stash them now sorry
11:20 <+bridge_> <learath2> squash*, but it's not urgent anyway, you can do it at the very end
11:21 <+bridge_> <Assa> @fushi_gg `color_cast<ColorRGBA>(ColorHSLA(g_Config.m_ClChatBackgroundColor, true))`
11:21 <+bridge_> <Assa> and if you have a ColorRGBA you can easily extract alpha, probably you can also work with HSLA directly
11:22 <+bridge_> <learath2> I wonder if we should make the color variables a little easier to work with
11:22 <+bridge_> <learath2> The config still giving you an unsigned is a little annoying
11:23 <+bridge_> <robyt3> Do all colors even round-trip between `unsigned` and `ColorHSLA`?
11:25 <+bridge_> <learath2> You mean exactly? Nope
11:25 <+bridge_> <learath2> Actually wait, HSLA yes
11:25 <+bridge_> <robyt3> If we only unpack the unsigned probably yeah
11:25 <+bridge_> <robyt3> But not if we color cast
11:26 <+bridge_> <robyt3> I thought about making the default colors `ColorRGBA`. You'd just have to some color functions actually `constexpr`.
11:26 <+bridge_> <learath2> If you go to RGBA I can't guarantee it any longer. Or more accurately I never designed for it so I assume they don't
11:26 <+bridge_> <robyt3> I thought about making the default colors `ColorRGBA`. You'd just have to make some color functions actually `constexpr`.
11:27 <+bridge_> <learath2> Should be very doable with C++17/20 we are allowed to use now
11:28 <+bridge_> <learath2> Making the defaults `ColorHSLA` would probably be even easier
11:29 <+bridge_> <learath2> There is also rounding there, so there is a chance I may have gotten it wrong, but the values I checked were fine
11:30 <+bridge_> <fushi_gg> I should probably also rename ClHookCollColorTipColl to ClHookCollColorTip right?
11:30 <+bridge_> <heinrich5991> 32 bit space can be checked exhaustively
11:31 <+bridge_> <heinrich5991> maybe do that @learath2
11:32 <+bridge_> <learath2> True, I can try later
11:33 <+bridge_> <Assa> who decided this variable naming anyway: `cl_hook_coll_color_tee_coll`
11:33 <+bridge_> <heinrich5991> probably whoever added the configs ^^
11:33 <+bridge_> <heinrich5991> there's no central authority
11:33 <+bridge_> <Assa> I'd prefer ClHookCollTipColor
11:34 <+bridge_> <Assa> hook-collision-line-tip-color
11:53 <+bridge_> <fushi_gg> uhh I think I messed up the stashing down of the commits 🥀
11:56 <+bridge_> <learath2> :050_Sadge:
11:56 <+bridge_> <fushi_gg> https://github.com/fushi-gg/ddnet/commit/d97d16eb12f5a1b9f44fb610b0de2fb583322e4e
11:57 <+bridge_> <fushi_gg> or do the old commits show up regardless? I am a total git noob
12:03 <+bridge_> <robyt3> What did you do? You need to do something like this to squash all commits into one, on top of the current master branch:
12:03 <+bridge_> <robyt3> 
12:03 <+bridge_> <robyt3> 1. `git rebase -i master`
12:04 <+bridge_> <robyt3> 2. A text editor opens. Change all *except* the first `pick` to `squash` in the opened file. Then close the editor/tab.
12:04 <+bridge_> <robyt3> 3. A text editor opens. Change the commit message in the opened file. Then close the editor/tab.
12:04 <+bridge_> <robyt3> 4. `git push -f`
12:34 <+bridge_> <fushi_gg> I didn't git push -f, thank you got it now
13:35 <+bridge_> <fokkonaut> ikr but ddnet doesn't care in most cases, hence why many devs leave over time.
13:35 <+bridge_> <fokkonaut> i talked to corneum who really wanted this feature, about implementation details too. but it was not fully completed i guess, feel free to revive it
13:38 <+bridge_> <fokkonaut> ikr but ddnet doesn't care in most cases, hence why many devs leave over time.
13:38 <+bridge_> <fokkonaut> i talked to corneum who really wanted this feature, about implementation details too. but it was not fully completed i guess, feel free to revive it
13:38 <+bridge_> <fokkonaut> (missing snapshot handling for prediction and clientbased prediction was missing)
13:42 <+bridge_> <fokkonaut> @learath2 do you know when the next release is planned?
13:42 <+bridge_> <fokkonaut> could you maybe review my prs in the meantime?
16:12 <+bridge_> <louis> agreed w the additive tunelock
16:27 <+ChillerDragon> @avolicious i had zye do my solo part now i am banned xd sos i didnt know that was illegal
16:31 <+bridge_> <avolicious> Thanks for your feedback, I need to make the text bigger
16:31 <+bridge_> <avolicious> https://cdn.discordapp.com/attachments/293493549758939136/1472616408671322327/image.png?ex=69933867&is=6991e6e7&hm=a0872da1be77f5a3ace728d92833d01f3332f33f27b4c6c88c3bd629e5c56cc6&
16:32 <+bridge_> <avolicious> Seems that people cant read it as its too small
16:35 <+ChillerDragon> no thats fine
16:35 <+ChillerDragon> i remember this text :D
16:36 <+ChillerDragon> but i did not share my code
16:36 <+ChillerDragon> i only shared my timeout code because /swap didnt work
16:36 <+ChillerDragon> @avolicious it was non obvious to me that this is illegal its common on ddnet servers to /swap all the time w random ppl
16:37 <+bridge_> <avolicious> okay
16:37 <+bridge_> <avolicious> Now you know for next time
16:37 <+ChillerDragon> i indeed to know
16:37 <+ChillerDragon> do*
16:37 <+ChillerDragon> aaa xd
16:37 <+ChillerDragon> does the ban auto expire?
16:38 <+bridge_> <avolicious> Yes
16:38 <+ChillerDragon> ah nice how long?
16:38 <+bridge_> <avolicious> idk
16:38 <+ChillerDragon> approximately?
16:38 <+bridge_> <avolicious> 7 days? i dont know
16:38 <+ChillerDragon> oof thats long
16:39 <+ChillerDragon> but oke ill wait 
16:39 <+ChillerDragon> but is zye banned too now? @avolicious
16:39 <+ChillerDragon> i am pretty sure he didnt know either
16:39 <+ChillerDragon> i made him do it
17:39 <+bridge_> <leslievaughan_> discord.gg/2Jqsg96mZz
17:47 <+bridge_> <gorp> Yes it is
17:48 <+bridge_> <gorp> huh, do you have a summary of this convo somewhere? im curious what you worked out for pros/cons
17:55 <+bridge_> <gorp> first of all, I definitely agree with the sentiment that it should follow existing tune restrictions (applies a complete override, with no additive effects) but to me half the feature was that you can have tunes that apply to both locked and unlocked in some area, either globally with tune or in certain areas with tunezone. if it stays truly "locked" (ie. can't be manipulated with tunezone after getting tunelock) then it makes it more capable for puzzl
18:00 <+bridge_> <gorp> in technical terms I imagined it would be a separate net type, so prediction is easy (client knows tunelock state separately, apply tunelock then apply tunezone to get predicted player state)
18:01 <+bridge_> <gorp> If not, the server could send a combined list of tunings that technically doesn't exist for the map but is a composite of both lock and zones, but that might not work since I think they're referred to by ID?
19:00 <+bridge_> <vappy19> Even the admin doesnt know the rules 🤣🤣
19:07 <+bridge_> <avolicious> I am not in daily business
19:07 <+bridge_> <avolicious> out long time ago
19:07 <+bridge_> <avolicious> just running the servers
19:07 <+bridge_> <avolicious> 🙂
19:10 <+bridge_> <fushi_gg> they have an entire rulebook for all the bannable offenses which include the above mentioned and ban times are case by case depending on the players previous offenses
20:24 <+bridge_> <gorp_tw> i saw a map was declined in kog and they gave a fucking pdf
20:24 <+bridge_> <gorp_tw> i think ddnet should try to be more like kog
20:24 <+bridge_> <totar> link?
20:24 <+bridge_> <gorp_tw> hold on
20:25 <+bridge_> <gorp_tw> https://cdn.discordapp.com/attachments/293493549758939136/1472675321550733364/document-1.pdf?ex=69936f45&is=69921dc5&hm=4d387dfd45d1e5765f6852f9b55b1032282dbbc1f9a11579e3a6a15e051fa3bc&
20:26 <+bridge_> <gorp_tw> and it's only like 14 pages 😭
20:26 <+bridge_> <gorp_tw> like whty
20:26 <+bridge_> <gorp_tw> like why
20:27 <+bridge_> <totar> bruh
20:27 <+bridge_> <gorp_tw> something something ddnet bajillion times bigger than kog and should put in same or more effort
20:28 <+bridge_> <gorp_tw> but im just a fucking dog with a blue name and chopped as fuck rcon so i cant do shiet about that
20:28 <+bridge_> <gorp_tw> other than whine loudly in all available channels
22:13 <+bridge_> <louis> Yeah we should require testers draft in overleaf so its harder for everyone involved
22:13 <+bridge_> <louis> coming to u next april 1
22:34 <+bridge_> <gorp_tw> :poggers2:
22:34 <+bridge_> <gorp_tw> i dont have much shade left to throw at testers
22:34 <+bridge_> <gorp_tw> less of a big deal than a lot of other stuff
22:34 <+bridge_> <gorp_tw> they just caught a stray by random example
23:43 <+bridge_> <totar> wtf
23:43 <+bridge_> <pioooooo> I guess kog has more "active top-tier skilled players" than DDNet and is narrow gameplay-wise
23:43 <+bridge_> <totar> crazy pr
23:47 <+bridge_> <gorp_tw> wait what that's so cool
23:47 <+bridge_> <louis> goatbyt3