00:34 < bridge_> nah, IMO it's better to specify the version you need 00:35 < bridge_> correct 00:35 < bridge_> the union of features is taken 00:36 < bridge_> Ah yes and that's why features should be additive not sub 00:36 < bridge_> That's why many no std features switched to std enabled by default feature 00:37 < bridge_> It's better if the feature enables std support than disables it 00:37 < bridge_> Which in the past was common 00:37 < bridge_> I go sleep 04:37 < bridge_> did TextRender::Text signature get changed recently? 04:37 < bridge_> i feel like it had auto height before and not now 04:57 < bridge_> oh it’s the silly ptr 05:00 < bridge_> how is it configured? did you look at the build instructions for Windows? at a glance this seems like a config mismatch error to me, possibly targeting an older standard version 05:00 < bridge_> which might happen if you didn’t use cmake 05:01 < bridge_> either generate for vs 2022 w/ the cmake gui or cmd line or whatever or open it as a cmake project in VS (build instructions don’t tell you to do this but it works better and lets you make multiple configurations, you have to click “continue with no code” and a cmake project is in file->open) 05:01 < bridge_> either generate for vs 2022 w/ the cmake gui or cmd line or whatever 05:01 < bridge_> or 05:01 < bridge_> open it as a cmake project in VS (build instructions don’t tell you to do this but it works better and lets you make multiple configurations, you have to click “continue with no code” and a cmake project is in file->open) 05:08 < bridge_> True 05:08 < bridge_> Tho not rly cpp 05:15 < bridge_> Maybe it would be worth using CUIRect in the HUD and whatnot instead of hardcoded offsets, would make finding space for new things much easier 05:16 < bridge_> rn with my status bar if i wanted to have it on the top i'd have to manually add the status bar height to the y of every other unrelated element that just happens to be there 05:16 < bridge_> but the ui could just split a shared rect and then the next whoever uses that 05:58 < bridge_> i didn't even look at menus_settings_assets until now. this is gonna take a while, jesus 08:34 < bridge_> Who are you btw. Never seen you before xd 08:36 < bridge_> Serde is rarely a problem cuz they are in 1.0 so all 1.0.y where y And there is no 2.0 08:36 < bridge_> good morning 08:37 < bridge_> 0.x.y is different cuz x are not back compat to semver on 0. 08:37 < bridge_> Cargo tries to resolve versions to be same, but if it fails the crate will have 2 versions 08:37 < bridge_> Only on 0 ? 08:38 < bridge_> And if libs use dif rust will tell u when u use a type on the lib from another version 08:38 < bridge_> 0.x.y x here is minor but on 0. Minors are breaking 08:38 < bridge_> Only patch is not 08:39 < bridge_> smh 08:39 < bridge_> Didn’t know that 08:39 < bridge_> https://doc.rust-lang.org/cargo/reference/semver.html 08:39 < bridge_> Looks like a cheese 08:40 < bridge_> jeez i just initialized a std::array of size 6 with 5 items 08:40 < bridge_> it should warn for that 08:41 < bridge_> "why it crash" 08:43 < bridge_> ? 08:43 < bridge_> C++? 08:44 < bridge_> his guide uses the terms “major” and “minor” assuming this relates to a “1.0.0” release or later. Initial development releases starting with “0.y.z” can treat changes in “y” as a major release, and “z” as a minor release. “0.0.z” releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible. 08:45 < bridge_> yea cpp 08:45 < bridge_> xd 09:13 < bridge_> Try do keep other changes minimal if possible or move them to a separate PR. IMO the loading indicator and text should be shown as a separate list item inside the listboxes which are currently getting loaded and not in a separate status bar, so you shouldn't need to adapt `CListBox` in any major way. I already have a loading indicator implemented, it's just waiting for stuff that can load in the background. I can make a PR in the evening if you wan 10:15 < bridge_> I used cmake and everything correctly just like in the readme, ended up reinstalling visual studio and it fixed it, was totally a problem with my msvc installation. (though weird that it compiled the server with no issues, but completely broke on the client) 10:45 < ChillerDragon> client has more tricky deps 10:45 < ChillerDragon> jopsti when add vulkan to the server? 10:51 < bridge_> Sounds good 10:51 < bridge_> More fps for server 12:45 < bridge_> Server Side Rendering for faster first frames 13:02 < ChillerDragon> gpu optimized 512 tee collision physics 13:04 < bridge_> compute shaders 13:04 < bridge_> take that bot-clients! 13:25 < bridge_> https://www.phoronix.com/news/Linux-6.6-Illicit-NVIDIA-Change 13:29 < bridge_> https://www.servethehome.com/intel-shows-8-core-528-thread-processor-with-silicon-photonics/ 14:02 < bridge_> how can i add multeasy map in my server 14:04 < ChillerDragon> download the map 14:04 < ChillerDragon> put it in your map foler 14:04 < bridge_> Download the map from another server or https://github.com/ddnet/ddnet-maps 14:04 < ChillerDragon> use ``sv_map`` 14:04 < ChillerDragon> https://github.com/ddnet/ddnet-maps/raw/master/types/novice/maps/Multeasymap.map 14:24 < bridge_> Guys, what's better, amd or intel? 14:26 < bridge_> Intel seems better 14:26 < bridge_> According to the first link i clicked 14:28 < bridge_> From my experience intel is less energy efficient with cpus 14:28 < bridge_> But does energy consumption really matter? 14:29 < bridge_> If you don’t care about your electricity bill then not really 14:30 < bridge_> in battery-powered devices, energy consumption matters a lot to yourself 14:30 < bridge_> Right 14:31 < bridge_> I care more about performance and features 14:32 < bridge_> Just watch and read some reviews 14:33 < bridge_> On the specific hardware that you want to buy 14:33 < bridge_> Alright, i guess it doesn't really matter 14:34 < bridge_> I assume you’re talking about cpus 14:35 < bridge_> If you were to talk about gpus then it’s a whole different story 14:35 < bridge_> Yeah cpus 14:35 < bridge_> Nvidia is the best for gpus i think 14:35 < bridge_> Imo nvidia is definitely just purely because of the software 14:35 < bridge_> Imo nvidia is definitely the best just purely because of the software 14:35 < bridge_> But i hate their proprietary software 14:35 < bridge_> I mean i have to as a linux user lol 14:36 < bridge_> Idk about linux 14:36 < bridge_> Im proud windows user 14:36 < bridge_> ~~me too but recently i use more linux than windows~~ 14:39 < bridge_> I think i need to choose a cpu first 14:39 < bridge_> And then the rest of the components 14:42 < bridge_> Depends on what you’re going for, but I’d recommend starting with gpu, since it’d be the most expensive thing 14:43 < bridge_> I guess on steam nvida rtx 3060 is popular 14:43 < bridge_> Mid range cpu or high end? 14:44 < bridge_> For high end I'd say, u can go with both. For mid, I'd go with amd 14:44 < bridge_> Idk yet 14:45 < bridge_> I guess mid range 14:45 < bridge_> Because i am not rich 14:45 < bridge_> Or something 14:45 < bridge_> Amd often has better perf/$ 14:46 < bridge_> Do u plan to buy inside poland or germany? 14:46 < bridge_> Poland? 14:46 < bridge_> Well EU.. u can buy from anywhere xd 14:48 < bridge_> I guess i want to have an average pc because games (software in general) probably want to work on average hardware? 14:52 < bridge_> Sure. I just wanted to know how much€ you pay for which CPU 14:53 < bridge_> And then I'll check what is better, amd or Intel. And where, shop 14:57 < bridge_> I wonder if pre built pcs are any good 14:58 < bridge_> They should technically be good in terms of components 15:05 < bridge_> @jupeyy_keks do u know where is the code to render a tee 15:05 < bridge_> oh 15:06 < bridge_> i know where to find this 15:06 < bridge_> I think we are talking about different things but that might be useful yeah 15:06 < bridge_> im finally finishing teerender 15:08 < bridge_> Nice 15:08 < bridge_> I haven't seen one at a fair price since years tbh 15:09 < bridge_> 10+ years ago aldi made ones xd 15:22 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1146434665876561920/result.png 15:22 < bridge_> honestly its hard to interpret the source code xd 15:26 < bridge_> Where did you struggle. Eyes? Xd 15:26 < bridge_> It'd be easy to read if it were Rust 15:26 < bridge_> Xdd 15:27 < bridge_> well the tee render is mixed with python 15:27 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1146436044846272512/result.png 15:27 < bridge_> body is too up right 15:27 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1146436123799867443/image.png 15:27 < bridge_> in game 15:28 < bridge_> ```rust 15:28 < bridge_> // 256, 128 15:28 < bridge_> let img = ImageReader::open("skins/brownbear.png")?.decode()?; 15:28 < bridge_> dbg!(img.width()); 15:28 < bridge_> dbg!(img.height()); 15:28 < bridge_> 15:28 < bridge_> let mut def = RgbaImage::new(96, 64); 15:28 < bridge_> dbg!(def.width()); 15:28 < bridge_> dbg!(def.height()); 15:28 < bridge_> 15:28 < bridge_> let filter = FilterType::Triangle; 15:28 < bridge_> 15:28 < bridge_> let back_feet_shadow = img.crop_imm(192, 64, 64, 32).resize(64, 30, filter); 15:28 < bridge_> blend_region(&mut def.sub_image(8, 32, 64, 30), &back_feet_shadow); 15:28 < bridge_> 15:28 < bridge_> let body_shadow = img.crop_imm(96, 0, 96, 96).resize(64, 64, filter); 15:28 < bridge_> blend_region(&mut def.sub_image(14, 0, 64, 64), &body_shadow); 15:28 < bridge_> 15:28 < bridge_> let front_feet_shadow = img.crop_imm(192, 64, 64, 32).resize(64, 30, filter); 15:28 < bridge_> blend_region(&mut def.sub_image(24, 32, 64, 30), &front_feet_shadow); 15:29 < bridge_> 15:29 < bridge_> let back_feet = img.crop_imm(192, 32, 64, 32).resize(64, 30, filter); 15:29 < bridge_> blend_region(&mut def.sub_image(8, 32, 64, 30), &back_feet); 15:29 < bridge_> 15:29 < bridge_> let body = img.crop_imm(0, 0, 96, 96).resize(64, 64, filter); 15:29 < bridge_> blend_region(&mut def.sub_image(14, 0, 64, 64), &body); 15:29 < bridge_> 15:29 < bridge_> let front_feet = img.crop_imm(192, 32, 64, 32).resize(64, 30, filter); 15:29 < bridge_> blend_region(&mut def.sub_image(24, 32, 64, 30), &front_feet); 15:29 < bridge_> 15:29 < bridge_> let left_eye = img.crop_imm(64, 96, 32, 32).resize(26, 26, filter); 15:29 < bridge_> honestly i just glossed over the code 15:29 < bridge_> its too much effort to figure the legit 15:29 < bridge_> way 15:29 < bridge_> xd 15:29 < bridge_> Yeah, price can be unfair but the components should work together nicely, right? 15:30 < bridge_> Like someone chose these components 15:30 < bridge_> Cheater 15:30 < bridge_> @jupeyy_keks tell me exact coords of tee rendering and ill make u a free software service API for everyone to render skins with given colors 15:30 < bridge_> and also a fast rust cli tool 15:30 < bridge_> blazing fast 15:36 < bridge_> Well, trust me if i say they won't work together better than if u look into the compatibility list of your motherboard manual 15:36 < bridge_> Prebuilt pcs tend to use cheapest hardware 15:37 < bridge_> I posted a type script once that works 15:37 < bridge_> mine also "works" 15:37 < bridge_> Maybe u can find it xd 15:38 < bridge_> Else see patigas txt 15:38 < bridge_> where is it 15:38 < bridge_> Dunno ask him 15:38 < bridge_> @patiga u got a tee skin rendering txt? 15:39 < bridge_> request for tee.md in libtw2/doc 15:39 < bridge_> or anywhere else 15:39 < bridge_> I have a question: Will a server with more than 128 maxplayers be masterban? 15:39 < bridge_> no 15:40 < bridge_> u will be banned if u say ur server has 128 players but they arent real 15:40 < bridge_> connect 15:40 < bridge_> connecteD* 15:40 < bridge_> but there is nothing wrong with 128 player slots 15:40 < bridge_> fokko does that 15:41 < bridge_> generally, it'd be nice to send correct info 15:41 < bridge_> there are no hard rules, but it'd be nice if your server actually supported 128 players then 15:44 < bridge_> Thanks, i found a way to make it. 15:45 < bridge_> Also, i think it can be useful for a PvE mode 15:45 < bridge_> ddnet is pve 15:45 < bridge_> its pvm 15:45 < bridge_> player vs map 15:45 < bridge_> xd 15:46 < bridge_> 😬 15:46 < bridge_> wow. 15:46 < bridge_> how to convert hsla to rgba 15:46 < bridge_> i hate colors 15:46 < bridge_> Me too xd 15:47 < bridge_> ok enough work today on teerender 15:47 < bridge_> i dont wanna deal with colors xd 15:47 < bridge_> Xddd 15:47 < bridge_> Imagine that the monsters on the map are all the same Tee as the players. The number of monsters and number of players add up to much greater than 64. 15:48 < bridge_> That's interesting. 15:48 < bridge_> We have it in color.h 15:48 < bridge_> source is here btw https://github.com/edg-l/teerender 15:48 < bridge_> Or you can look at wikipedia 15:48 < ChillerDragon> lerato our davinci 15:48 < bridge_> im not even sure my function to convert a color code to hsl works 15:48 < bridge_> xd 15:48 < bridge_> nice commit message 15:48 < ChillerDragon> xd 15:48 < bridge_> ```rust 15:48 < bridge_> #[allow(clippy::cast_precision_loss)] 15:49 < bridge_> fn color_code_base(col: u32, alpha: bool) -> HSLAColor { 15:49 < bridge_> let a = if alpha { 15:49 < bridge_> ((col >> 24) & 0xFF) as f32 / 255.0f32 15:49 < bridge_> } else { 15:49 < bridge_> 1.0f32 15:49 < bridge_> }; 15:49 < bridge_> let x = ((col >> 16) & 0xFF) as f32 / 255.0f32; 15:49 < bridge_> let y = ((col >> 8) & 0xFF) as f32 / 255.0f32; 15:49 < bridge_> let z = (col & 0xFF) as f32 / 255.0f32; 15:49 < bridge_> 15:49 < bridge_> HSLAColor { x, y, z, a } 15:49 < bridge_> } 15:49 < bridge_> ``` 15:50 < bridge_> xd 15:51 < bridge_> That looks fine to me 15:53 < bridge_> .0f32 is cursed 15:53 < bridge_> not as cursed as . being f32 and .f being f16 tho 15:53 < bridge_> omg these codes 15:54 < bridge_> are these java 15:54 < bridge_> no 15:54 < bridge_> these rust 15:54 < bridge_> f32 suffix is unnecessary there 15:54 < bridge_> c++ 15:54 < bridge_> these are rust 15:54 < bridge_> There are rust 15:54 < bridge_> i don't think c++ has 'let' 15:54 < bridge_> They are rust 15:54 < bridge_> #define let auto 15:56 < bridge_> Then I don't think C++ returns values by this way. 15:57 < bridge_> python? 15:57 < bridge_> rust. 15:57 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1146443665066184835/tee_notes.txt 15:58 < bridge_> what's this? 15:58 < bridge_> epic 15:58 < bridge_> @heinrich5991 15:58 < bridge_> the values required to render a tee properly 15:58 < bridge_> why are eyes positions not fractions? 15:58 < ChillerDragon> @Ewan "#define let auto" lmao epic 15:58 < bridge_> rust bro 15:59 < bridge_> first is the offset of the tees, the point around which they rotate. afterwards its the movement of the eyes which is calculated with the view angle 15:59 < bridge_> *of the eyes 16:00 < bridge_> ya it’s a feature 16:00 < bridge_> Ah ok ;) 16:01 < bridge_> i know we dont pin much but can someone pin this 16:01 < bridge_> I'll create a libtw2 pull request 16:01 < bridge_> I've seen someone define emojis to "int", "float" before 16:02 < bridge_> https://wiki.ddnet.org/wiki/Development#About_Tee_Skin_Rendering 16:02 < bridge_> i added it here 16:02 < bridge_> too 16:03 < bridge_> wow 16:07 < bridge_> whats wowy 16:07 < bridge_> i didn't know the wiki has it before 16:12 < bridge_> it didnt have the txt from patiga, i added it just now 16:15 < bridge_> oh 16:20 < bridge_> can I have that under the libtw2 license (Apache2/MIT)? 16:20 < bridge_> sure 👍 16:20 < bridge_> thanks ❤️ 16:21 < bridge_> are you adding it rn? else I'd do a pull request 16:22 < bridge_> you can do a PR 16:22 < bridge_> actually 16:22 < bridge_> I was about to do it 16:22 < bridge_> what do you prefer? @patiga 16:23 < bridge_> you do it, I think its fastest and its your repo :) 16:23 < bridge_> (-> so you know how you want it formatted etc) 16:26 < bridge_> Wait, what wrong with ddnet.org? 16:26 < bridge_> hm? 16:26 < bridge_> oh 16:26 < bridge_> loaded now 16:33 < bridge_> https://github.com/ddnet/ddnet/pull/6727#discussion_r1309811240 16:33 < bridge_> i get it for little routines where the string goes out of scope quick but to always have 256 bytes allocated when it could be 4? idk man 16:33 < bridge_> i get it for little routines where the string goes out of scope quick but to always have 256 bytes allocated when it could be 5? idk man 16:37 < bridge_> @patiga eye_blink isn't real? TIL 16:38 < bridge_> all lies! 16:39 < bridge_> the github app is so unintuitive 16:43 < bridge_> @patiga is blink only vertically scaled or both ways? 16:43 < bridge_> only vertically 16:43 < bridge_> the rest both ways? 16:44 < bridge_> hm yes 16:50 < bridge_> during a blink, the eyes are probably 45% vertically, 120% horizontally (normal eyes value) 16:51 < bridge_> ^ yes 16:53 < bridge_> this fine? @patiga https://github.com/heinrich5991/libtw2/commit/044597a89faa5afaaa01e6cb2fa100d94c806738 16:53 < bridge_> including using you as the author 16:55 < bridge_> looks good! 16:56 < bridge_> ok, pushed 17:10 < bridge_> Nice 17:12 < bridge_> Do we want to add a flag to io_read_all to differentiate between files of 0 bytes and files >2GiB 17:12 < bridge_> epic 17:16 < bridge_> Or just always return -1 for sz or w/e 17:17 < bridge_> files with >2GiB should probably not be loaded into memory as a whole. if you still want to fx that function, make it return `uint64_t` I guess 17:17 < bridge_> Or just always return -1 for sz or w/e if over 2GB 17:17 < bridge_> I'm fine with w/e for these large files 17:19 < bridge_> Seems stupid to remove safer code just because it’s not done elsewhere 17:19 < bridge_> then put it into `io_read_all` 17:19 < bridge_> maybe io_length or w/e 17:19 < bridge_> You'd probably have to change all of the io offset functions if you want to support largers files since we use `fseek` 17:20 < bridge_> I wouldn't call code that loads arbitrary amounts of data into RAM safe, but it's not worse than the current code 17:20 < bridge_> Why `uint64_t` over `size_t`? 17:21 < bridge_> `size_t` is the wrong type, it differs between 32 bit and 64 bit systmes 17:21 < bridge_> 32 bit systems can have files larger than 4 GiB 17:21 < bridge_> But they can't load them into memory 17:21 < bridge_> Which is what the function does 17:21 < bridge_> But I get your point for the other functions 17:22 < bridge_> streams? 17:22 < bridge_> loading a 4 GiB file into memory is also a stupid idea on 64 bit 17:22 < bridge_> depends 17:22 < bridge_> i like loading a sqlite dbb into memory 17:22 < bridge_> xd 17:23 < bridge_> give me an example in the context of ddnet 17:23 < bridge_> give me an example in the context of ddnet 17:23 < bridge_> ok but u didnt mention ddnet 17:23 < bridge_> u just said 64bit 17:23 < bridge_> i dont know any rn 17:25 < bridge_> @heinrich5991 btw, if a file is in a tmpfs and u read it, is it 2 times in memory? not ddnet context 17:25 < bridge_> i guess a tmpfs is more good at avoiding writes 17:25 < bridge_> check discord name 😛 we're accidentally talking about ddnet development 😄 17:25 < bridge_> xd 17:26 < bridge_> twice in memory. you can mmap it so it might only be there once 17:44 < bridge_> in the context of ddnet 32 bit is also stupid 😬 17:47 < bridge_> it's fine to play ddnet on old computers, although I'm not sure there are still 32 bit computers around 🤔 17:47 < bridge_> it's bad, bcs it blocks progress for the silent majority 17:49 < bridge_> IMO it's rather bad to stop supporting old hardware for software that doesn't need new hardware 17:49 < bridge_> contributes to waste 17:49 < bridge_> old hardware usually uses more energy for the same effective result 17:50 < bridge_> also software would be less bloated without old hardware 17:50 < bridge_> I'd bet it's better to use old hardware with more energy requiremenets than produce new hardware 17:50 < bridge_> => less work to do 17:50 < bridge_> i wouldn't count on that 17:50 < bridge_> old cars from europe are now driven in africa 17:51 < bridge_> random article: https://www.networkworld.com/article/2229029/computer-factories-eat-way-more-energy-than-running-the-devices-they-build.html 17:51 < bridge_> 70% sounds like using an old computer is always better than buying a new one 17:52 < bridge_> in terms of energy requirements 17:52 < bridge_> (not even talking about resource usage, where the waste goes) 17:53 < bridge_> well this clearly does not include the result (less performance) 17:54 < bridge_> more software bloat 17:54 < bridge_> more maintaince 17:54 < bridge_> are you still talking about energy usage? or is this a different topic? 17:54 < bridge_> yes i am 17:55 < bridge_> I'd guess it's mostly the "modern software" that's more wasteful, not backcompat 17:56 < bridge_> old software runs much faster (more energy efficient?) on new hardware AFAICT 17:57 < bridge_> and what does that have to do with the age of the software? 17:57 < bridge_> new hardware is usually faster 17:57 < bridge_> that python sucks is crystal clear 17:57 < bridge_> 17:57 < bridge_> but vulkan is clearly more energy efficient than OpenGL 17:57 < bridge_> so targeting vulkan makes sense 17:58 < bridge_> got a citation on that btw? 17:58 < bridge_> the vulkan being more energy efficient? 17:58 < bridge_> it's designed to use less CPU 17:58 < bridge_> benchmarks back that up 17:58 < bridge_> can you link one that shows that it uses less power? 17:59 < bridge_> https://www.youtube.com/watch?v=rvCD9FaTKCA 17:59 < bridge_> 17:59 < bridge_> is a video from ARM good enough for you? 18:00 < bridge_> sounds good 18:00 < bridge_> what's opengl es vs opengl? 18:00 < bridge_> do you think it performs similarly? 18:00 < bridge_> yes 18:00 < bridge_> ok 18:01 < bridge_> it's a subset of OpenGL 4.3 (OpenGL ES 3.2) 18:13 < bridge_> opengl es is what used to run on mobiles iirc 18:13 < bridge_> since mobiles are arm too 18:15 < bridge_> `cargo clippy --workspace -- -D warnings -D clippy::nursery -A clippy::collection_is_never_read -A clippy::string_lit_as_bytes -A clippy::option_if_let_else -A clippy::use_self` i cooked this up for smth at work 18:15 < bridge_> easy pr 18:16 < bridge_> ohh 18:17 < bridge_> i found a false positive 18:17 < bridge_> i guess clippy cant detect if a destructor is non const and it suggest to make a function const 18:20 < bridge_> clippy's words are no longer god's words? ^^ 18:21 < bridge_> it should be able to, maybe make a bug report 18:21 < bridge_> it is, most of the time xd 18:21 < bridge_> unless compiler says no 18:22 < bridge_> :justatest: 18:22 < bridge_> i put deny cuz i know ppl at work arent madmans like me 18:22 < bridge_> also the stirng_list_as_bytes comes from a macro 18:22 < bridge_> string* 18:22 < bridge_> i put allow* cuz i know ppl at work arent madmans like me 18:23 < bridge_> (and no we dont run nursery anywhere, its just a thing i like to do) 18:23 < bridge_> i actually found out a lot of possible const fns 18:23 < bridge_> report a bug ^^ 18:23 < bridge_> this is public API in library, got to be careful there 18:23 < bridge_> oh true 18:24 < bridge_> well its unlikely to change 18:25 < bridge_> the consts are mostly "new" style functions 18:27 < bridge_> @heinrich5991 whatu think about https://rust-lang.github.io/rust-clippy/master/index.html#/equatable_if_let 18:35 < bridge_> meh 18:35 < bridge_> not worth changing code over 18:48 < bridge_> odd i cant make a min example 18:48 < bridge_> for clippy 19:56 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1146503778565095494/F4uKl0RXYAEX_Ac.jpg 19:58 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1146504112771449023/F4vnZFlXgAIDUqa.jpg 20:01 < bridge_> the funny thing is, the third happens quite often 20:01 < bridge_> 20:01 < bridge_> and mostly that comment then doesn't help xD 20:02 < bridge_> you are 6th xd 20:03 < bridge_> i knewe u would say that 20:03 < bridge_> xd 20:27 < bridge_> royowo the tab girl uwu 20:28 < bridge_> I identify as the 1st 20:29 < bridge_> Jospsiti is the question answerer 20:34 < bridge_> chillerdragon: about your pr for login censorship with the streamer mode. 20:34 < bridge_>