00:02 < bridge> As a vim user I find ctrl-a as select all very disrespectful 00:03 < bridge> yeah but no 00:03 < bridge> everywhere uses ctrl-a as select all 00:03 < bridge> ```cpp 00:03 < bridge> std::span SdlModes; 00:03 < bridge> { 00:03 < bridge> int SdlModesRawCount = 0; 00:03 < bridge> SDL_DisplayMode **ppSdlModesRaw = SDL_GetFullscreenDisplayModes(ScreenId, &SdlModesRawCount); 00:03 < bridge> if(ppSdlModesRaw) 00:03 < bridge> { 00:03 < bridge> dbg_msg("gfx", "unable to get display modes: %s", SDL_GetError()); 00:03 < bridge> return; 00:03 < bridge> } 00:03 < bridge> SdlModes = {ppSdlModesRaw, SdlModesRawCount}; 00:03 < bridge> } 00:03 < bridge> ``` 00:03 < bridge> am i cooking 00:03 < bridge> probably not 00:04 < bridge> i hate dealing with arrays as a size and a ptr 00:04 < bridge> i should suck it up tho 00:24 < bridge> why are fullscreen modes resizeable? 00:26 < bridge> streched resolution 00:26 < bridge> que? 00:26 < bridge> stretched resolution 00:26 < bridge> fullscreen modes shouldnt be resizeable 00:27 < bridge> fullscreen modes shouldnt make the window resizeable 00:27 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1348437031382159360/Spielermodell-CSGO-min.png?ex=67cf7559&is=67ce23d9&hm=8950d85f7a4be7e90785f62738b5dd504b29dff685ba87c48f9d53cdc4887df9& 00:27 < bridge> are you asking this? 00:27 < bridge> https://wiki.libsdl.org/SDL3/SDL_SetWindowResizable 00:27 < bridge> this is set to true 00:27 < bridge> on fullscreen modes 00:28 < bridge> im trying to parse the spaghetti setvideomode 00:28 < bridge> ```cpp 00:28 < bridge> case 0: // Windowed or Windowed Borderless 00:28 < bridge> SDL_SetWindowFullscreen(m_pWindow, false); 00:28 < bridge> SDL_SetWindowBordered(m_pWindow, !IsBorderless); 00:28 < bridge> SDL_SetWindowResizable(m_pWindow, true); 00:28 < bridge> break; 00:28 < bridge> ``` 00:28 < bridge> it looks like to me 00:28 < bridge> that windowed borderless does nothing 00:28 < bridge> idk 00:28 < bridge> apart from decorations 00:29 < bridge> which i guess is the definiton of the 2 words slapped together 00:29 < bridge> ctrl-a del try to match the pinned msg 00:29 < bridge> probably not 00:29 < bridge> yeah jupeys message is inacurate 00:29 < bridge> Don't we have headless mode 00:30 < bridge> has to be 00:30 < bridge> for the client? 00:30 < bridge> Ye 00:30 < bridge> how does that work 00:30 < bridge> the whole graphics backend shouldnt be initalized 00:30 < bridge> otherwise there would be m_pWindow checks everywhere 00:31 < bridge> (or sdl_isinited for sdl2) 00:31 < bridge> the video modes are completley broken as they are now (by the looks of the code) 00:32 < bridge> im gona check on master 00:32 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1348438287408435210/Screenshot_20250310_073206.jpg?ex=67cf7684&is=67ce2504&hm=05a82d0d5b0903fab9c73d1df8810befba95d4aeb39c15d719709e6569b4822b& 00:32 < bridge> looks like it yeah 00:32 < bridge> the graphics shouldnt be inited 00:32 < bridge> or compiled at all 00:32 < bridge> so its fine 00:33 < bridge> ok 00:33 < bridge> Just thought to mention it 00:33 < bridge> 👍 00:34 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1348438756004204555/image.png?ex=67cf76f4&is=67ce2574&hm=2b55de84d84227ea81091c3610e2bbd6fb9dcf38f5af0eb98d7cdb0aa37f299e& 00:34 < bridge> its so broken 00:34 < bridge> xd 00:34 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1348438915773763614/image.png?ex=67cf771a&is=67ce259a&hm=b371f6a2e45dd8ba62d5777bd8907c98ae5edadc48322da8cb35eac6b2e66be2& 00:39 < bridge> why on earth does resizewindow handle fullscreen stuff 00:40 < bridge> why should it not? 00:41 < bridge> @totar how does fast input work so i can make an issue about it 00:41 < bridge> lmao 00:41 < bridge> because it is really hard to figure out what the hell is going on 00:41 < bridge> repredicts entire world 1 tick earlier when new input is detected? 00:43 < bridge> it predicts the entire world 1 tick ahead all the time. It basically treats your game as if your inputs have 20ms of input delay and applies 20ms of antiping. 00:44 < bridge> but it also triggers a re-prediction every time you change keys 00:44 < bridge> it's definitely not strictly better in all cases 00:45 < bridge> ```cpp 00:45 < bridge> bool IsDesktopFullscreen = FullscreenMode == 2; 00:45 < bridge> #ifndef CONF_FAMILY_WINDOWS 00:45 < bridge> // special mode for windows only 00:45 < bridge> IsDesktopFullscreen |= FullscreenMode == 3; 00:45 < bridge> #endif 00:45 < bridge> ``` 00:45 < bridge> 3 is windowed fullscreen 00:45 < bridge> why is that windows exclusive 00:46 < bridge> alright ty, will open 00:46 < bridge> https://www.youtube.com/watch?v=0FUFewGHLLg 00:46 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1348441852914827307/image.png?ex=67cf79d6&is=67ce2856&hm=b2f1b26695e57ad7c34f702ea750aec818a73d7f2cdd1e77a20815572e857419& 00:46 < bridge> me rn 00:47 < bridge> Wait we are not running prediction code for antiping? 00:47 < bridge> we are? 00:47 < bridge> I always thought we are. 00:47 < bridge> we are. 00:48 < bridge> Then I'm not sure what fast input is then 00:49 < bridge> I thought you just described standard worldwide CSP 00:49 < bridge> also cant it only repredict on changed input? why is doing PredGameTick 1 tick ahead necessary? 00:49 < bridge> guys someone should totally do this because funny 00:49 < bridge> `nc 82.130.23.104 4567` 00:49 < bridge> and send something when you connect 00:49 < bridge> I'm listening 00:50 < bridge> Although most CSP repredicts every ticks, not just on input change tho 00:50 < bridge> if you don't predict 1 extra tick ahead all the time then your prediction on changed input will do nothing because the game does not consider the input that you're pressing until the next tick happens 00:51 < bridge> it's a technique for hiding the input latency of a fixed tick rate game by extrapolating your position at the cost of errors when the input changes 00:51 < bridge> So probably not the same thing. I'm out then 00:51 < bridge> if the game runs at infinite tps then you would not need fast input 00:52 < bridge> the delay comes from the fact that the game only processes your inputs every 20ms 00:52 < bridge> on a tick 00:52 < bridge> so when you press left, you must wait until the next tick happens and then the game will start showing you your movement 00:53 < bridge> i see 00:53 < bridge> Do you have that in tater already 00:53 < bridge> yeah 00:53 < bridge> 00:53 < bridge> it's also in dd-pg 00:53 < bridge> Do people love it 00:53 < bridge> im looking it up here its taken from tater 00:53 < bridge> im looking it up here its taken from tater i guess 00:53 < bridge> gores players definitely love it, I hear mixed things from ddrace players 00:53 < bridge> some use it 00:54 < bridge> so why cant it predict 1 tick ahead only when new input is detected, but 1 tick ahead all the time 00:54 < bridge> so why cant it predict 1 tick ahead only when new input is detected, but 1 tick ahead all the time? 00:54 < bridge> will it skip a tick? 00:54 < bridge> you have to predict a constant number of ticks 00:54 < bridge> I mean it kinda make sense but I feel like it's just moving a problem to the past. But maybe the tps is not that small so it doesn't show artifacta that much 00:54 < bridge> I mean it kinda make sense but I feel like it's just moving a problem to the past. But maybe the tps is not that small so it doesn't show artifacts that much 00:55 < bridge> If you are willing to be fancy you could somehow adjust it to accommodate to display latency too 00:55 < bridge> That would just overscope to the roof tho 00:55 < bridge> the amount of atrifacts depends on how fast your movement is in 1 tick after pressing an input, so jumping will show it more 00:55 < bridge> Ye 00:55 < bridge> but regular movement from left/right or hooking is very hard to tell usually 00:55 < bridge> ofc with tunes you can change that 00:56 < bridge> but not many maps do that 00:56 < bridge> Tunes? 00:56 < bridge> I thought it was client side only 00:56 < bridge> tunes 00:56 < bridge> tunes change the game physics 00:56 < bridge> oh 00:56 < bridge> oh you mean switching left and right 00:57 < bridge> I was like obviously it won't show up if you just move to one side :justatest: 00:57 < bridge> I mean changing the acceleration values 00:57 < bridge> so pressing left makes you move very fast instantly 00:58 < bridge> Ye so it's basically just RetroArch's run-ahead 00:58 < bridge> idk what that is 00:59 < bridge> oh 00:59 < bridge> it might be the same thing 00:59 < bridge> basically the same thing it just save states every frame and just run a few frames with the current input 00:59 < bridge> every frame 01:00 < bridge> it's conceptually similar to rollback or antiping 01:00 < bridge> but locally 01:00 < bridge> i broke it 01:00 < bridge> You just closed the connection 01:00 < bridge> I think 01:00 < bridge> shame 01:00 < bridge> or maybe I did? 01:00 < bridge> I wouldn't say I like extrapolation in general but I'm not really a player 01:00 < bridge> did u get some rainbow tetx 01:01 < bridge> I did not :( 01:01 < bridge> darn 01:01 < bridge> let me open it up again 01:01 < bridge> Did I miss something 01:01 < bridge> we were chatting 01:01 < bridge> *over TCP* 01:01 < bridge> very fancy 01:01 < bridge> advanced protocol 01:01 < bridge> we are doing that rn 01:02 < bridge> I should probably sleep 01:02 < bridge> It's 8am 01:02 < bridge> :justatest: 01:06 < bridge> I feel like extrapolation in general is like lying to your brain, you didn't see anything earlier photonically but you made your brain think it is, by show it discrepancies and make it solve tiny puzzles. It is amazing but also kind heart breaking :kek: 01:07 < bridge> I feel like extrapolation in general is like lying to your brain, you didn't see anything earlier photonically but you made your brain think it is, by showing it discrepancies and make it solve tiny puzzles. It is amazing but also kind heart breaking :kek: 01:07 < bridge> I feel like extrapolation in general is like lying to your brain, you didn't see anything earlier photonically but you made your brain think it is, by showing it discrepancies and make it solve tiny puzzles. It is amazing but also kinda heart breaking :kek: 01:08 < bridge> @robyt3 it appears fullscreen mode (steal your monitor or not) is gone 01:08 < bridge> in sdl3 01:08 < bridge> Exclusive Fullscreen? 01:08 < bridge> yeah 01:08 < bridge> Do they have a use for *nix? 01:09 < bridge> no 01:09 < bridge> i mean apart from if you want to resize ur monitor 01:09 < bridge> which you shouldnt want to do 01:09 < bridge> but its a thing you could do 01:09 < bridge> On windows 11 I think drivers somehow can just take over the screen now if it is borderless 01:09 < bridge> By default a window in fullscreen state uses borderless fullscreen desktop mode, but a specific exclusive display mode can be set using SDL_SetWindowFullscreenMode(). 01:09 < bridge> so leave it up to sdl to figure it out now i guess 01:09 < bridge> 01:10 < bridge> @sollybunny you get anything? 01:10 < bridge> you used to explicitly state if you wanted exclusive 01:10 < bridge> i did not 01:10 < bridge> Cuz we made that ime workaround before and borderless still behaves the same with exclusive where driver would not let DWM draw anything on top of it 01:10 < bridge> what do i do with case 2 then 01:10 < bridge> of gfx_fullscreen 01:10 < bridge> just make it fullscreen remove it from ui? 01:10 < bridge> Just do borderless probably 01:11 < bridge> 1 and 2 used to differentiate between exclusive or not 01:11 < bridge> Let someone more sensitive test input latency maybe? 01:11 < bridge> but now theres no differentiation in sdl 01:11 < bridge> Just let both be "regular" fullscreen whatever that is I think 01:11 < bridge> yeah 01:13 < bridge> I think exclusive fullscreen is just a legacy thing and newer windows prefers to just let drivers (or something else) handles it now? 01:13 < bridge> poor windows 7 01:14 < bridge> and xp 01:14 < bridge> only ones affected by this 01:14 < bridge> probably 01:14 < bridge> sucks to be them:nouis: 01:14 < bridge> Lol 01:14 < bridge> I mean people really stand by xp and win7 probably aren't running through steam and probably won't update anyway 01:15 < bridge> I think it is driver cuz Nvidia optimus allows DWM to run on top of borderless fullscreen but a single Nvidia card would not 01:16 < bridge> steam gives a personal gift - [steamcommunity.com/gifts/id=1131341079](https://u.to/nD4XIg) 01:16 < bridge> What's up with all the bots 01:16 < bridge> Is someone clicking on these every time they spam this 01:16 < bridge> are people that gullible 01:16 < bridge> can you not setup automod to block steam gift keywords? 01:17 < bridge> Idk 01:17 < bridge> discord has built in automod with regex 01:17 < bridge> just have to set it up 01:17 < bridge> maybe mods cant and have to be admin here 01:18 < bridge> Prob 01:18 < bridge> `Set fullscreen mode: 0=no fullscreen, 1=pure fullscreen, 2=desktop fullscreen, 3=windowed fullscreen` 01:18 < bridge> mods can only timeout 01:18 < bridge> why the fuck is it numbered like this 01:18 < bridge> sob 01:18 < bridge> And I think I can even timeout myself 01:19 < bridge> @sollybunny you get anything now? 01:19 < bridge> nope 01:20 < bridge> ```cpp 01:20 < bridge> #if !defined(CONF_PLATFORM_MACOS) 01:20 < bridge> MACRO_CONFIG_INT(GfxBorderless, gfx_borderless, 0, 0, 1, CFGFLAG_SAVE | CFGFLAG_CLIENT, "Borderless window (does nothing with fullscreen)") 01:20 < bridge> #if !defined(CONF_WEBASM) 01:20 < bridge> MACRO_CONFIG_INT(GfxFullscreen, gfx_fullscreen, 1, 0, 3, CFGFLAG_SAVE | CFGFLAG_CLIENT, "Set fullscreen mode: 0=no fullscreen, 1=pure fullscreen, 2=desktop fullscreen, 3=windowed fullscreen") 01:20 < bridge> #else 01:20 < bridge> MACRO_CONFIG_INT(GfxFullscreen, gfx_fullscreen, 0, 0, 3, CFGFLAG_SAVE | CFGFLAG_CLIENT, "Set fullscreen mode: 0=no fullscreen, 1=pure fullscreen, 2=desktop fullscreen, 3=windowed fullscreen") 01:20 < bridge> #endif 01:20 < bridge> #else 01:20 < bridge> MACRO_CONFIG_INT(GfxBorderless, gfx_borderless, 1, 0, 1, CFGFLAG_SAVE | CFGFLAG_CLIENT, "Borderless window (not to be used with fullscreen)") 01:20 < bridge> MACRO_CONFIG_INT(GfxFullscreen, gfx_fullscreen, 0, 0, 3, CFGFLAG_SAVE | CFGFLAG_CLIENT, "Set fullscreen mode: 0=no fullscreen, 1=pure fullscreen, 2=desktop fullscreen, 3=windowed fullscreen") 01:20 < bridge> #endif 01:20 < bridge> ``` 01:20 < bridge> can i just breaking change this please 01:20 < bridge> I indeed can 01:20 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1348450453373063238/Screenshot_20250310_081929.jpg?ex=67cf81d9&is=67ce3059&hm=59026e45c66f9abea15a1f29877d9296df753a2338148b4caae91969caa5a5ce& 01:21 < bridge> yipee 01:35 < bridge> what is the difference between the "feature accepted" and "accepting patches" tags on the github? 01:35 < bridge> @ryozuki 01:56 < bridge> merge #9821 🙂 01:56 < bridge> https://github.com/ddnet/ddnet/pull/9821 01:57 < bridge> half of players can already do it on their keyboard anyway 01:57 < bridge> me included 02:08 < bridge> @fokkonaut `Let's not change how the game works, maybe? Also, adding so many options is too much maintenance work` 02:08 < bridge> you sound like heinrich 02:08 < bridge> it doesnt change how the game works anyway, just makes it behave like a fancy keyboard 02:09 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1348462612567818444/image.png?ex=67cf8d2c&is=67ce3bac&hm=0ae1465ad3ed5cf9ffe46137a745ad609d27d52431ebc55220c3a18c26151941& 02:09 < bridge> thanks discord very cool 02:09 < bridge> just have a fancy keyboard and create a new game profile 02:09 < bridge> the argument for adding it is that a fancy keyboard is expensive 02:10 < bridge> never had issues with the problem, and i've played on very bad keyboards, where this probably would be even worse 02:10 < bridge> it isnt an issue, or rather the benefits of this can be solved by skill issue 02:10 < bridge> it isnt an issue, or rather the benefits of this can be solved by removing skill issue 02:10 < bridge> useless feature 02:10 < bridge> imo 02:11 < bridge> not to call it bloat xd 02:11 < bridge> would you consider it cheating 02:11 < bridge> no i would just consider it not fitting 02:11 < bridge> if its not cheating i would add it to my client 02:11 < bridge> and use it 02:11 < bridge> do whatever you want 02:11 < bridge> xD 02:11 < bridge> free will 02:11 < bridge> right but i like not being banned 02:12 < bridge> and others dont like others having competative advantage 02:12 < bridge> how would that ban you? how would a server even detect that? 02:12 < bridge> because its pretty hard to spam left and right with no gap imbetween 02:12 < bridge> at 25tps 02:12 < bridge> skill issue 02:12 < bridge> yeah 02:12 < bridge> but people with fancy keyboard can do it 02:12 < bridge> it's actually 50 ticks per second, but yea clientside 02:13 < bridge> or its easier to do it on fancy keyboards 02:13 < bridge> maybe enable sv_high_bandwidth ? 02:13 < bridge> skill issue 02:13 < bridge> 25tps is quite high 02:13 < bridge> doing it at any per second is hard 02:13 < bridge> and being able to is an advantage 02:13 < bridge> I'm not convinced it's impossible with binds already 02:13 < bridge> i think your approach wouldnt even solve it 02:14 < bridge> is it impossible to make the game release a key you're holding by binding it to something else or unbinding it? 02:14 < bridge> when you spam left and right you might hold left a bit before u press right 02:14 < bridge> meaning u have a bit of no movement 02:14 < bridge> which to me, sounds better to send direction 0 then, instead of holding ??? 02:15 < bridge> imagine a gores 02:15 < bridge> or smth 02:15 < bridge> i dont understand 02:15 < bridge> maybe unbinding will work but then you have to rebind it 02:15 < bridge> ok? 02:15 < bridge> how hard has someone tried 02:16 < bridge> there isnt a +unbind 02:16 < bridge> bind a "unbind d; +left" 02:16 < bridge> you then need to rebind d when a is let go ir when a is pressed 02:16 < bridge> you then need to rebind d when d is pressed 02:16 < bridge> pls just dont bloat ddnet xd @ devs 02:17 < bridge> its pretty self contained 02:17 < bridge> Haha you say don't bloat it but when do we finally remove the backward compat that is half the code ase xf 02:17 < bridge> Haha you say don't bloat it but when do we finally remove the backward compat that is half the codebase 02:17 < bridge> xxd 02:20 < bridge> can someone on a mainline linux distro and/or windows 11 test my sdl3 branch 02:20 < bridge> specifically the video modes, (changing between display modes and resoltuions) 02:21 < bridge> 02:21 < bridge> It's 2am ;-; 02:22 < bridge> at some point in the future 02:22 < bridge> i dont have a mainline linux distro, a windows machine nor anymore the capacity to spin one up 02:22 < bridge> my changes to getting multiple displays seem to have disapeared 02:22 < bridge> idk where they went 02:26 < bridge> i found them 02:28 < bridge> Its not bloat its to defer people looking up scripts and going into rabbit hole of cheating 02:28 < bridge> Same as people looking up custom clients and ending up on cheat clients 02:28 < bridge> Even the famous "hey check out this client" is client not check out this cheat 02:29 < bridge> i've also seen telegram links with ddnethacks title 03:15 < bridge> Mostly scams 05:35 < bridge> i joined linear to test out something and like 4 people were spamming something like "GET FREE CHEATS AT t.me/" 08:30 < bridge> morning 08:30 < bridge> read the description 08:31 < bridge> "Implementation not planned, accepting PRs " it means that usual devs wont rly work on it but if somebody does a patch because they want it it will be accepted probably 08:38 < bridge> I did, but why do you need both? Why can't you use "accepting patching" in place of "feature accepted" in all cases? 08:38 < bridge> we want to move more to the discuss before making a pr idea 08:38 < bridge> because otherwise ppl make a pr thats rejected and get angy 08:39 < bridge> feature accepted it means it will probs be worked by someone here 08:39 < bridge> accepting patches is more like its not a priority 08:39 < bridge> Wdym someone here? Isn't that 95% of all prs? 08:40 < bridge> Does feature accepted mean someone claimed the work already? 08:40 < bridge> no 08:40 < bridge> But why put accepting patches if they won't be accepted 08:41 < bridge> they will if someone does it 08:42 < bridge> So isn't that the same as feature accepted 08:42 < bridge> :pepeW: 08:42 < bridge> if u want to consider those as same feel free xD i already explained my reasoning, maybe others have different opinion on this matter 08:45 < bridge> @gerdoe https://github.com/ddnet/ddnet/pull/9825#issuecomment-2709691299 08:45 < bridge> accepting patches is for patches that don't directly affect ddnet rn. 08:45 < bridge> 08:45 < bridge> E.g. if you set MAX_CLIENTS to 256 and suddenly half the game doesn't work.. a accepting-patches means ddnet is open to merge stuff to fix it 08:47 < bridge> wdym "don't directly affect ddnet rn" doesn't half the game not wroking affect ddnet? 08:47 < bridge> Well it does not benefit ddnet 08:48 < bridge> but fixing the game does benefit ddnet 08:48 < bridge> thus my example 08:48 < bridge> I guess one sets an **incentive** to make a PR for it, while the other just allows a PR 08:49 < bridge> accepting patches sounds like my patch will be accepted, feature accepted sounds like my patch will be accepted. I see no difference 08:49 < bridge> its just about managing priorities 08:49 < bridge> i dont think its hard to understand 08:50 < bridge> if it's about priorities then just say that in the description 08:51 < bridge> something like "accepting patches" and "requesting patches" would make much more sense 08:51 < bridge> average gentoo user after 2 days of non usage 08:51 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1348563911942869084/image.png?ex=67cfeb83&is=67ce9a03&hm=05a648246dc8ff7bbb53dd7aeca49ea73b97c71d77adc46a6fe2c6774c2def91& 08:52 < bridge> See it from the perspective of issues and not from the PR side: You need to manage a hell of a lot of issues, if they are prioritized you know better what to work on and what to ignore 08:52 < bridge> this also doesn't lead to confusion where you accept a "feature" which is a bug fix 08:54 < bridge> @ryozuki I don't know what to do about #9801 and slides, e.g #9795 now, I wrote some text 08:54 < bridge> https://github.com/ddnet/ddnet/issues/9801 08:54 < bridge> https://github.com/ddnet/ddnet/pull/9795 08:55 < bridge> I think the new approach will be, we only allow new tiles if you also map a full map with it 08:55 < bridge> So we can run it on a test server 08:55 < bridge> I provided a testmap, but okay I can do a "fullmap" 08:55 < bridge> (or get a mapper to do it for u) 08:56 < bridge> I'm ok with renaming if that makes it easier to understand. @ryozuki @learath2 @robyt3 08:56 < bridge> im ok with it 08:56 < bridge> it think issues labelled with "bug" are always accepted 08:57 < bridge> do we have issues where we have "bug" and "feature-accepted"? 😄 08:57 < bridge> we have bug and "patches accepted" 08:57 < bridge> we have bug and "accepting patches" 08:57 < bridge> If the game breaks with MAX_CLIENTS=256 that is probably not a bug 08:58 < bridge> thus it would only get a accepting-patches 08:58 < bridge> I know we have testservers, but we'd need a different kind with the current nightly build or something. Also should this go through the usual map workflow, e.g. posting a map here on discord? 08:58 < bridge> the reason I asked is because currently it seems that the the tags are being used identically accepted one is for "feature/enhancement" and one is for "bug/issue" 08:58 < bridge> the reason I asked is because currently it seems that the the tags are being used identically except cepted one is for "feature/enhancement" and one is for "bug/issue" 08:58 < bridge> the reason I asked is because currently it seems that the the tags are being used identically except one is for "feature/enhancement" and one is for "bug/issue" 08:58 < bridge> Yes we talked about it, but didn't really setup something yet 08:58 < bridge> https://github.com/llvm/llvm-project/releases/tag/llvmorg-20.1.0 08:58 < bridge> so it makes no sense to have 2 if they are the same thing 08:58 < bridge> :poggers2: :poggers2: :poggers2: 08:59 < bridge> Should I already start making a map? 08:59 < bridge> yeah but then again it's about priority.. a "i don't really care, but if you do it, we merge it" label is what is meant here 09:00 < bridge> That is your choice ig 09:00 < bridge> if it's about priority then they should be labeled that way and used like that instead of how it is now 09:00 < bridge> i dunno if "i don't really care, but if you do it, we merge it" fits into the label name 09:01 < bridge> no but it fits in the tag description 09:01 < bridge> currently they describe the same thing 09:04 < bridge> But about renaming that's fine to me, I just didn't get what u meant here.. 09:04 < bridge> 09:04 < bridge> We have: 09:04 < bridge> - Bugs.. Existing bugs 09:04 < bridge> - Accept feature.. For new stuff that could benefit ddnet 09:04 < bridge> - Other stuff.. Either not interesting for ddnet as game, or not code related 09:05 < bridge> ok but why do these get "accepting patches" 09:05 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1348567430041047060/image.png?ex=67cfeeca&is=67ce9d4a&hm=5a7014f417829b89d7a73ac3721e2b725f5177f1890b90b1703b22c6cfdc47f1& 09:05 < bridge> and these ones "feature accepted" 09:05 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1348567459191455744/image.png?ex=67cfeed1&is=67ce9d51&hm=53561768dc72f4043fd48eddc8ae0bc0e8356789eb79d7770f969ed3514b2a85& 09:06 < bridge> to me all these look like identical priority 09:06 < bridge> These won't affect ddnet.. the "bug" is maybe missleading I'd remove it 09:06 < bridge>