00:02 < bridge_> they are turned off anyway 👀 03:02 < ws-client> @jxsl13 one server can load one antibot module. Two servers can load one each :D is that what you meant? 03:03 < ws-client> and as jupstar pointed out you can also write code into the antibot module to load infinite amount of submodules but that code does not exist yet 03:03 < ws-client> i finished the thing seems to be working 05:28 < bridge_> @chillerdragon 05:28 < bridge_> > This process is a bit annoying. I have to uninstall half my OS to swap these. Because ffmpeg depends on sdl. 05:28 < bridge_> > Also I would like to use the one from pacman not the one from the AUR ._. 05:28 < bridge_> 05:28 < bridge_> `pacman -Rsndd sdl2-compat; pacman -Sdd sdl3` 07:29 < bridge_> Can you hot reload the antibob module? 07:29 < bridge_> ChillerDragon: 07:59 < bridge_> i meant your module is closed source and would contain the gctf patch. because it might be pointless to maintain two of those, one containing only the gctf patch, which I might get access to and one with your bob stuff. I could still manually patch the servers but yeah, would definitly be neat to use the plugin. 08:00 < bridge_> w/o the bob stuff 08:44 < bridge_> @robyt3 https://github.com/ddnet/ddnet/pull/10015#issuecomment-2788402095 08:44 < bridge_> 08:44 < bridge_> then what do 08:45 < bridge_> Remove the meta programming again I guess 08:45 < bridge_> so no enum class? 08:45 < bridge_> manually specifying the min and max is possible 08:46 < bridge_> Just cast to int? 08:46 < bridge_> oh right 08:46 < bridge_> that makes me sad tho xd 08:46 < bridge_> too bad 08:49 < bridge_> @robyt3 should i use underlying_type or just int 08:50 < bridge_> int 08:51 < bridge_> should i put the max enum value beside the definition 08:51 < bridge_> so when you add a protocl it doesnt have to be changed everywhere 08:52 < bridge_> ```cpp 08:52 < bridge_> enum class EProtocol 08:52 < bridge_> { 08:52 < bridge_> TW6_IPV6, 08:52 < bridge_> TW6_IPV4, 08:52 < bridge_> TW7_IPV6, 08:52 < bridge_> TW7_IPV4, 08:52 < bridge_> }; 08:52 < bridge_> ``` 08:52 < bridge_> ```cpp 08:52 < bridge_> static constexpr int s_ProtocolMax 08:52 < bridge_> ```? 08:52 < bridge_> ```cpp 08:52 < bridge_> enum class EProtocol 08:52 < bridge_> { 08:52 < bridge_> TW6_IPV6, 08:52 < bridge_> TW6_IPV4, 08:52 < bridge_> TW7_IPV6, 08:52 < bridge_> TW7_IPV4, 08:52 < bridge_> }; 08:52 < bridge_> ``` 08:52 < bridge_> ```cpp 08:52 < bridge_> static constexpr EProtocol s_ProtocolMax = TW7_IPV4; 08:53 < bridge_> ```? 08:56 < bridge_> Can't say I like this either. I don't know if we shouldn't just keep the NUM in (without meta-programming) 08:56 < bridge_> morning 08:56 < bridge_> heinrich doesnt like num cuz it means its a valid option 08:57 < bridge_> Not with the meta programming, but the NUM was already there 08:57 < bridge_> Post your suggestions on the PR so others can comment 08:57 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1359422056198045806/image.png?ex=67f76bf3&is=67f61a73&hm=84009e3f778ceb316c59edc130115acea0158503c96769b3c8b5108a2c8b88e4& 08:58 < bridge_> mmk 08:59 < bridge_> like rust, less macros better, so less templates better imho 08:59 < bridge_> Use the latest entry instead of num maybe. Or just don't use C++ enums anymore in general but write our own enum class :justatest: 08:59 < bridge_> i was thinking that 09:00 < bridge_> but i was scared to get sent to the shadow realm for too much meta programming 09:00 < bridge_> Use the last entry instead of num maybe. Or just don't use C++ enums anymore in general but write our own enum class :justatest: 09:00 < bridge_> @ryozuki do you use a visitor trait I can yoink? 09:00 < bridge_> @ryozuki do you use a visitor trait so I can yoink it? 09:00 < bridge_> @ryozuki do you have a visitor trait so I can yoink it? 09:00 < bridge_> no i dont use visitor pattern 09:01 < bridge_> the lack of proper pattern matching in c++ makes dealing with enums need metaprogramming i guess, cenummap in rust would just be a hashmap with the enum as key 09:01 < bridge_> Well, it probably would, but at this point I don't see a clean alternative 09:02 < bridge_> in fact, why u need CEnumMap and not just std::unordered_map 09:02 < bridge_> well i guess cuz its a array internally 09:02 < bridge_> cpp doesnt do that 09:02 < bridge_> it just looks so ugly, u need to make a iterator and a map for every enum 09:02 < bridge_> i meant ur cenummap 09:03 < bridge_> oh right 09:03 < bridge_> no unright 09:03 < bridge_> std::unordered_map (the alternative) isnt just an array 09:03 < bridge_> for what its used for the performance cost doesnt matter 09:03 < bridge_> Depends on how much we care about the performance difference 09:04 < bridge_> `std::size_t Size = static_cast(Enum::NUM)` 09:04 < bridge_> this makes it ugly 09:04 < bridge_> sadly cpp doesnt have a way to get the max element 09:04 < bridge_> ggtg 09:05 < bridge_> cant u get the lass variant and add 1? 09:05 < bridge_> last 09:05 < bridge_> @sollybunny or just at declaration of CEnumMap pass the size of the enum, which the user can do by passing the last variant + 1 09:05 < bridge_> but i guess thats uglier 09:06 < bridge_> ok enums in cpp sux 09:11 < bridge_> you can skip the division by using known constants and multiplication instead. You can also look at Padé approximants: https://en.wikipedia.org/wiki/Pad%C3%A9_approximant which are quite good but involves a true division 09:22 < bridge_> Programming against an api, User: "Why does feature X not work?" Me: "Wtf, why does this not work". Currently in a talk with the developers of API and confirmed a bug, their faces were priceless 09:43 < bridge_> classic 09:54 < bridge_> @robyt3 09:54 < bridge_> ```cpp 09:54 < bridge_> bool Ipv6 = m_aProtocolsEnabled[EProtocol::TW6_IPV6] || m_aProtocolsEnabled[EProtocol::TW7_IPV6]; 09:54 < bridge_> bool Ipv4 = m_aProtocolsEnabled[EProtocol::TW6_IPV4] || m_aProtocolsEnabled[EProtocol::TW7_IPV4]; 09:54 < bridge_> ``` 09:54 < bridge_> turns into a nightmare with static casts 09:55 < bridge_> @robyt3 09:55 < bridge_> ```cpp 09:55 < bridge_> bool Ipv6 = m_aProtocolsEnabled[EProtocol::TW6_IPV6] || m_aProtocolsEnabled[EProtocol::TW7_IPV6]; 09:55 < bridge_> bool Ipv4 = m_aProtocolsEnabled[EProtocol::TW6_IPV4] || m_aProtocolsEnabled[EProtocol::TW7_IPV4]; 09:55 < bridge_> ``` 09:55 < bridge_> even with c style its a bit wordy 10:05 < bridge_> @jupeyy_keks because you asked for a datastructure for maplayers: We could create a general Maplayer base class, and inherit buffered and unbuffered rendering from it, making the functions virtual that change. I don't know how "wanted" this change would be, as it would further devide the logic 10:05 < bridge_> Ironically enough glibc seems to not have anything that fancy. They use just range reduction and a taylor series approximation. Which kinda makes sense as close to 0 the taylor series approximation actually has less error and is more uniform 10:06 < bridge_> @jupeyy_keks because you asked for a datastructure for maplayers: We could create a general Maplayers (Rendering) base class, and inherit buffered and unbuffered rendering from it, making the functions virtual that change. I don't know how "wanted" this change would be, as it would further devide the logic 10:10 < bridge_> just noticed, that maplayers already is a virtualized class 😮 10:10 < bridge_> just noticed, that maplayers already is a virtualized class 😮 we don't have any derived classes, maybe an other dev had this already in mind 10:23 < bridge_> what about using some existing libs like something i sent last time 10:40 < bridge_> So many people working on just refactoring stuff now 10:47 < bridge_> Honestly the name "maplayers" to actually say rendering map already isn't really good. 10:47 < bridge_> I'd probably go with a very simple name "MapVisuals" or "MapRenderer". 10:47 < bridge_> 10:47 < bridge_> These map visuals contain a rendering pipeline. 10:47 < bridge_> This pipeline on highest level is: 10:47 < bridge_> - background 10:47 < bridge_> - physics 10:47 < bridge_> - foreground 10:47 < bridge_> 10:47 < bridge_> Then for background & foreground there is a list of layers (in order) to render. The type of layer is evaluated too (Quad or Tile layer). 10:47 < bridge_> Then simply render all layers like that. 10:47 < bridge_> 10:47 < bridge_> What I'd _NOT_ do is care about (map-)groups at all. 10:48 < bridge_> They are only used for the clipping and preparing the drawing canvas' projection attributes (offset, parallax). IMO this can also be done on a per layer basis. 10:48 < bridge_> 10:48 < bridge_> Now if you have a function called "RenderTileLayer" and this automatically splits into buffered and unbuffered is to me good enough over having yet another data structure to split this. (In a sense RenderTools already abstracts away the old rendering anyway for the editor rendering) 10:48 < bridge_> 10:48 < bridge_> To me it's mostly about making the flow of the rendering easier to follow. 10:49 < bridge_> You could also abstract most of these away: 10:49 < bridge_> https://github.com/ddnet/ddnet/pull/10043/files#diff-3139c99b7ed3b99518d6b597a2652b49938ec31306d96dbe8e92bba913d4da2aR1492-R1528 10:49 < bridge_> 10:49 < bridge_> The tile layer visuals simply have an attribute called overlays, in order. And these overlays by enum say which texture they want 10:51 < bridge_> Oh and I'd not make MapVisuals a client component anymore. 10:51 < bridge_> 10:51 < bridge_> You can have a client component "RenderCurrentMap". But that sounds unrelated to having a datastructure that can render maps 10:51 < bridge_> Then the background menu map would also be cleaner instead of using the client component 10:51 < bridge_> magic enums uses magic which i dont wnt to introduce 10:52 < bridge_> which is not magic 10:54 < bridge_> idk but when you code in other languages do you really check how every package u use is implemented 10:55 < bridge_> not really, but i have magic enums 10:55 < bridge_> and its compiler dependent magic 10:55 < bridge_> wdym 10:55 < bridge_> 10:55 < bridge_> i recommend you open this in vsc or something 10:56 < bridge_> oh yeah this is c++17 and over 10:57 < bridge_> @jupeyy_keks 10:57 < bridge_> > These map visuals contain a rendering pipeline. 10:57 < bridge_> > This pipeline on highest level is: 10:57 < bridge_> > background 10:57 < bridge_> > physics 10:57 < bridge_> > foreground 10:57 < bridge_> 10:57 < bridge_> I am aware of this, we have the MapLayers component twice in the gameclient, once for background and once for foreground (including entities). This is completly implicitly done in the component ordering 10:59 < bridge_> Could you help me abstract these away, you mean explicitly for the Buffered case, but we'd need to know what texture to set. I could also make the function get the overlay count and iterate over it and add the textures to set in an array or something like that 11:00 < bridge_> it's just a bit unclear to me how to do it _nicely_ 11:00 < bridge_> I'd make overlays a structure and have a vec of overlays that is iterated over 11:00 < bridge_> every overlay simply is of type centered_text, bottom_text or top_text 11:00 < bridge_> based on that you can get the texture 11:01 < bridge_> Additionally the set_texture call is similar. 11:02 < bridge_> 11:02 < bridge_> Make an enum 11:02 < bridge_> 11:02 < bridge_> Design(TextureIndex), 11:02 < bridge_> Game, 11:02 < bridge_> Front, 11:02 < bridge_> Tele, etc. 11:02 < bridge_> 11:02 < bridge_> Then you can almost completely remove that switch there 11:02 < bridge_> I mean it's not too important if you don't want to. It simply reduces the switch to where the actual difference is. 11:02 < bridge_> 11:02 < bridge_> In the end basically all tile layers, if design or physics are the same. They only differ in texture and overlays 11:03 < bridge_> I mean it's not too important if you don't want to. It simply reduces the switch to where the actual difference is. 11:03 < bridge_> 11:03 < bridge_> In the end basically all tile layers, design or physics, are the same. They only differ in texture and overlays 11:04 < bridge_> I can do that, no problem. I think it would be a lot cleaner, but wouldn't the switch logic just move into the Overlay creation? 11:04 < bridge_> Well at least it would be static 🤔 11:05 < bridge_> Yes, I guess for me it's more about, having a proper rendering structure. 11:05 < bridge_> 11:05 < bridge_> Some code is always somehow messy or needs lots of ifs etc. 11:05 < bridge_> I generally prefer it in initialization code 11:05 < bridge_> But again, if you prefer it otherwise do it as you like 11:05 < bridge_> This isn't really a strong opinion 11:06 < bridge_> I am sure there is some merit to it, but I'd do it in a followup 11:06 < bridge_> Doing this in small reviewable chunks is always a good idea, especially before introducing new features 11:13 < bridge_> Ryu(?) said that the world would be better if people stop added features and just did refactoring prs. I guess alot of people saw and acknowledged it. It also means people have a better understanding of the code which is good when old maintainers die and we need new ones 11:14 < bridge_> Yeah it is not bad. Just a curiosity, it used to be the opposite, people only were interested in doing new features 11:19 < bridge_> i'll just take that 11:19 < bridge_> i am very interested in doing new features 11:19 < bridge_> but in terms of gameplay ddnet is blocked behind being backwards compatible and waiting for tw 0.8 aswell as a way to do new tiles sustainably (have a testing phase, and that rfc thing) 11:19 < bridge_> in terms of client side things most new things take alot more effort atleast for me than refactoring, im also stuck on all the new features i want for ddnet and tclient 11:19 < bridge_> * i want to make the chat ui better for team/whispering 11:19 < bridge_> * i want to make new (0.7 style-ish) name tags and have them used everywhere instead of our very inconsistent nametags we have now 11:19 < bridge_> * i want chat bubbles for tclient 11:19 < bridge_> it uses binary search to determine number of enums xd 11:19 < bridge_> what 11:19 < bridge_> cuz you can see if an int value is in an enum 11:20 < bridge_> so you can binary search the underlying type 11:20 < bridge_> its jank as i said 11:20 < bridge_> anyway it also doesnt provide a map so the more meta programming is still needed 11:20 < bridge_> it does 11:20 < bridge_> tw 0.8 🥴 11:20 < bridge_> do it? 11:20 < bridge_> i saw a pr about that 11:20 < bridge_> constant enum map stuff 11:21 < bridge_> https://github.com/Neargye/magic_enum/pull/187 11:21 < bridge_> its an excuse ive heard for new features 11:21 < bridge_> "ddnet is just a mod" 11:22 < bridge_> well cool then :D 11:23 < bridge_> https://github.com/ddnet/ddnet/pull/8341 11:23 < bridge_> i take this as a qol feature 11:23 < bridge_> instead of replacing the freezebar 11:23 < bridge_> https://github.com/Neargye/magic_enum/issues/150 11:24 < bridge_> this one also looks good but c++20 11:24 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1359458941364474116/91581d1ad905911f.png?ex=67f78e4d&is=67f63ccd&hm=b280f0e18e9fbb7c26e5dff0c96d10de5dc56b8e36ce24b71ea61be00f1cb364& 11:24 < bridge_> it would be nice if we could stay cpp11 11:26 < bridge_> lmao 11:26 < bridge_> cpp11 is now considered old by this page 11:28 < bridge_> the reasons for me are: 11:28 < bridge_> 1. it feels cool to be able to compile in older versions 11:28 < bridge_> 2. niche compilers are often outdated, newer features are harder to convert (ranges eg) 11:28 < bridge_> 3. 3 11:28 < bridge_> if someone else pushes the min version to cpp17 or higher i wont complain 11:28 < bridge_> also llvm swallows alot of the niche compilers whole 11:28 < bridge_> (i think) 11:29 < bridge_> i cant name a third cpp compiler 11:29 < bridge_> i mean forth 11:29 < bridge_> fourth* 11:29 < bridge_> idk which one 11:29 < bridge_> clang, gcc, msvc, apple one 11:29 < bridge_> isnt apple just using clang 11:30 < bridge_> not sure, but i know they have something seperate 11:30 < bridge_> "Apple Clang*" 11:30 < bridge_> like on my macbook the default toolchain is clang 11:30 < bridge_> yes 11:30 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1359460494162919536/image.png?ex=67f78fbf&is=67f63e3f&hm=2e3e72ae1e6f4dbdba4b9b78341cdef00d6a9fc982047c648b05a508dc11070f& 11:30 < bridge_> Hm, we might be on 17 nowadays tbf 11:30 < bridge_> by niche i meant consoles and things 11:30 < bridge_> for what? 11:31 < bridge_> we used nodiscard, fallthrough and maybe_unused attributes but those are ignored by cpp11 (or should be) 11:33 < bridge_> i cant see anythign else 11:33 < bridge_> but then again i havent looked at the whole codebase 11:33 < bridge_> amnt omnicient 11:34 < bridge_> std::clamp? or do we use our own 11:34 < bridge_> I don't remember now, but. I do remember seeing gnu++17 in the compile commands on mac 11:34 < bridge_> `using std::clamp;` in math.h 11:34 < bridge_> thats such a weak thing to cause cpp11 non compliancd xd 11:35 < bridge_> but pi isnt stolen from math.h? 11:35 < bridge_> i guess its impl dependent 11:36 < bridge_> Probably more than that idk 11:36 < bridge_> seems to be more precise (if that matters for a float) than anything i cna find 11:37 < bridge_> set: `3.1415926535897932384626433f` 11:37 < bridge_> real: `3.1415927410125732421875` 11:37 < bridge_> damn that bad 11:37 < bridge_> accurate to only 6dp 11:38 < bridge_> ```cpp 11:38 < bridge_> #include 11:38 < bridge_> #include 11:38 < bridge_> 11:38 < bridge_> int main() { 11:38 < bridge_> float pi = 3.1415926535897932384626433f; 11:38 < bridge_> std::cout << std::setprecision(30) << pi << std::endl; 11:38 < bridge_> return 0; 11:38 < bridge_> } 11:38 < bridge_> ``` 11:38 < bridge_> ^ professionally vibe coded 11:40 < bridge_> currently compiling with cpp11 to see if it works 11:41 < bridge_> no because im half way through doing something xd 11:41 < bridge_> You can also do a git blame on cmakelists to see who bumped it to 17 and when/why 11:41 < bridge_> its probably because of std::clamp 11:41 < bridge_> ill do that 11:42 < bridge_> Btw if we bumped at all, that means our oldest target has a c++17 compiler now 11:44 < bridge_> 11:45 < bridge_> https://github.com/ddnet/ddnet/pull/4709 11:45 < bridge_> it wasnt for any reason it seems 11:46 < bridge_> Seems it was for #4710 11:46 < bridge_> https://github.com/ddnet/ddnet/pull/4710 11:46 < bridge_> cant clang tidy version and cpp standard be differnet? 11:47 < bridge_> Wym? 11:47 < bridge_> Those modernize flags bring in stuff like `make_unique` which is C++14 and above e.g. 11:47 < bridge_> ```cpp 11:47 < bridge_> [192/192] Linking CXX executable DDNet-Server 11:47 < bridge_> [solly@solly buildcpp11]$ 11:47 < bridge_> ``` 11:47 < bridge_> std::make_unique? i thought that was ages ago 11:48 < bridge_> huh 11:48 < bridge_> no way we are sticking with cpp11 then 11:48 < bridge_> probably ddint set flags right 11:49 < bridge_> anyway maintainers dont have the same urge to use the smallest version number standard 11:51 < bridge_> Well our metric is what the oldest debian we build on supports 11:51 < bridge_> i see 12:51 < bridge_> wait there is std::clamp :jusa 12:51 < bridge_> wait there is std::clamp :justatest: 12:53 < bridge_> why is clamp(v, lo, hi) and not (lo, v, hi), this always bothers me 12:56 < bridge_> why is it not v.clamp(lo, hi) :) 12:57 < bridge_> [nearly nothing]() in the codebase uses std::clamp, but [nearly everything]() the self made `clamp` 12:57 < bridge_> 12:57 < bridge_> @chillerdragon we have that std:: rule, clamp might be the exception. 14:14 < bridge_> which language has clamp(min, x, max)? that's insane 14:35 < bridge_> Hot reload is always cool. But as of right now I do not need it in the antibot. I spent so much time on making hot reload work how I want it to work in twbl probably not repeating that for antibot. I rather build a plugin system that has a more feature rich interface than antibot which can do hotreloading 14:36 < bridge_> @jxsl13: the idea is that it now just works. No more maintenance needed from either of us. If for some reason you want to keep updating it we will find a way 14:49 < bridge_> will you provide like access to the compiled module or something like that? 14:49 < bridge_> a plugin system with a rich interface would be really nice, the antibot ABI is barely functional for anything other than heuristic based antibots 14:50 < bridge_> or have a secondary repo for tue gctf stuff only? 14:50 < bridge_> the 14:51 < bridge_> my question is basically, how and to what do I get access. 14:52 < bridge_> If you are missing something feel free to PR it. We do a lot more than heuristics in our module 14:53 < bridge_> The ability to intercept all packets and send packets pretty much allows for anything you'd like 14:53 < bridge_> I want the gamestate in it's entirety so I can do prediction based heuristics 14:54 < bridge_> the "self made" is just a reference to std::clamp in base/math.h, we should always use std::clamp i think 14:54 < bridge_> except modify the gamestate, I would also like the ability to change anything about the gamestate from the antibot 14:55 < bridge_> I see what you want, yeah that's not the kind of thing that's easy with the current way the antibot works. I doubt we'd be open to patches that tie the antibot that deeply into the gamestate either 14:55 < bridge_> So yeah something like a plugin system would be more interesting for your usecase 15:01 < bridge_> wizardry https://github.com/facet-rs/facet 15:01 < bridge_> https://docs.rs/unsynn/0.0.26/unsynn/ 15:01 < bridge_> is it compiletime reflection? 15:01 < bridge_> I guess we need a PR to fix issues like this if we ant to inline that 15:02 < bridge_> or get rid of this maximum/minimum/clamp functions 15:03 < bridge_> > The Poke type is able to allocate (or work from a &mut MaybeUninit) any Facet type, and gradually initialize its fields — until the fully-built value is moved out of the partial. 15:03 < bridge_> This sounds turbopog 15:03 < bridge_> its a dark magic crate 15:04 < bridge_> https://docs.rs/facet/0.1.4/facet/hacking/index.html 15:04 < bridge_> > The Facet trait is the cornerstone of our reflection system. It provides a way to access type information at both compile time and runtime, enabling powerful meta-programming capabilities while maintaining Rust’s safety guarantees. 15:04 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1359514333159227603/image.png?ex=67f7c1e3&is=67f67063&hm=5efb0a4f0804d18897566200014640d99601fba57969f5d3224fdc239c473a9a& 15:04 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1359514403061497876/image.png?ex=67f7c1f4&is=67f67074&hm=8bb920e0ddd455a32addbe3aaa5f313d0c7f387341963bf0f11666009beb5773& 15:48 < bridge_> clamp is probably used with `using` because there would have been too many changes to add `std::` everywhere 15:56 < bridge_> ы 16:14 < bridge_> Is that so bad? 16:14 < bridge_> Also thoughts on using better enums (Google it) 16:15 < bridge_> Looks like it does everything we want at the cost of it's macro magic 16:28 < bridge_> looks just as much compiler dependent magic as ... 16:59 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1359543183595540631/image.png?ex=67f7dcc2&is=67f68b42&hm=24cb9262c974c06b554ea2991bd99147d5e03b823048944cead25c2179529624& 16:59 < bridge_> i havent looked at the implementation yet 17:07 < bridge_> its horrid 17:15 < bridge_> i would just blackbox it whatever 17:39 < bridge_> lol what’d syn do wrong 17:42 < bridge_> slow compile time afaik 18:07 < bridge_> We shouldn't have used an uuid for teehistorian files (and game ids). Now that I'm doing some things with them a snowflake would have been much more useful, or something else that gave a bit of ordering, even if they were k-sorted that'd be more useful 18:08 < bridge_> or something like instagram ids 18:12 < bridge_> authoritative serial type 😎 18:14 < bridge_> (btw just the index file for teehistorians is 3.3 gigs now, that's 22.6 million teehistorian files that are indexed 18:14 < bridge_> (btw just the index file for teehistorians is 3.3 gigs now, that's 22.6 million teehistorian files that are indexed) 18:14 < bridge_> curious how much of that (in bytes) is UUIDs 18:15 < bridge_> `data/2018-halloween/bra/0b56925e-d2e4-4e75-9c2e-7bb8f37c41c7.teehistorian,0b56925e-d2e4-4e75-9c2e-7bb8f37c41c7,2018-11-01T16:50:42+01:00,8362,Kobra,6f4b0bab,598947` 18:15 < bridge_> These are what the lines look like 18:18 < bridge_> 72 characters for the uuid for the 2 times it occurs there, times 22.6 million, that's 1.6 gigabytes of the file just having the uuids 😄 18:18 < bridge_> (it doesn't matter, that's the point of an index, it keeps data that is redundant, my issue with the uuids is that they are not sortable at all) 18:20 < bridge_> yeah 18:20 < bridge_> lmao 18:36 < bridge_> well, single precision float has only 6 to 7 digits precision, so 3.141592 has 7 digits and whatever is after doesn't matter 18:38 < bridge_> https://github.com/rust-lang/rust/issues/21102 this is so annoying when working with rust 18:38 < bridge_> I keep having to remember to set a breakpoint on `rust_panic` 18:41 < bridge_> https://ntietz.com/blog/til-uses-for-the-different-uuid-versions/ 18:43 < bridge_> A v7 uuid might have been interesting here I guess 18:45 < bridge_> WTFF 😭😭 https://www.youtude.net/watch?v=i50wel2lVsw 18:46 < bridge_> ban you? 18:53 < bridge_> ChillerDragon you had a teeworlds/ddnet packet decoder somewhere, where? 19:10 < bridge_> ``` 19:10 < bridge_> 2564893 ConsoleCommand { cid: 1, flag_mask: 128, cmd: "timeout", args: ["timeoutcodehere"] } 19:10 < bridge_> 2564893 Drop { cid: 1, reason: "Timeout Protection used" } 19:10 < bridge_> 2564893 ConsoleCommand { cid: 1, flag_mask: 128, cmd: "emote", args: ["angry", "999999"] } 19:10 < bridge_> ``` 19:10 < bridge_> 19:10 < bridge_> I was wondering why I was getting a crash, turns out a client that has gotten dropped can use console commands 19:10 < bridge_> @patiga do you think this is unintended or normal? Worth creating an issue for? Fixable? 😄 19:11 < bridge_> it crashes doesn’t it 19:12 < bridge_> is this a crash in the replayer, or where? 19:12 < bridge_> Not only can they use console commands but they also still get logged by teehistorian `2564895 PlayerOld { cid: 1, pos: (336, 625) }`, this one is still before the join at `2614778` 19:13 < bridge_> It crashes some custom tooling I had that assumes you can't do anything before a `Join` and after a `Drop` 19:13 < bridge_> would've considered that a sound assumption 19:13 < bridge_> is this important for some timeout stuff? 19:14 < bridge_> Timeout `Drop`s seem to be the only thing that violates that assumption 19:14 < bridge_> what’s join? join as in “entered and joined the game” or as in, connected? 19:14 < bridge_> wouldn’t make sense that way actually 19:14 < bridge_> Thankfully doesn't really matter at all for my use, I can just drop the messages that happen inbetween and I won't lose anything 19:15 < bridge_> @zwelf2 weird teehistorian stuff, please share your knowledge :owo: 19:16 < bridge_> Join as in just established a proper connection, it's logged at the end of `CServer::NewClientCallback` 19:18 < bridge_> Perhaps timeout rejoins should be logged as a `teehistorian-rejoinver6@ddnet.org`, that's what they seem to behave more like 19:19 < bridge_> Anyway, only @heinrich5991 and @zwelf2 would possibly know the intricacies of this one if anyone knows it at all 😄 19:26 < bridge_> Doesn't look great, it means including 1300 LOC in almost every file, the effect on compile time alone already seems non-negligible. It also adds a lot of stuff we don't need which only bloats compile-time/link-time or the binary, like converting enums to and from strings 19:27 < bridge_> yeah ): 19:27 < bridge_> cant that reflection cpp14 thing be added 19:27 < bridge_> to the spec 19:27 < bridge_> pretty plz mx cpp people 19:28 < bridge_> will only be in cpp38 x-x 19:28 < bridge_> i dont think u could swing it 19:29 < bridge_> ddnet’s too old to bring in utility libraries like that without great reason 19:29 < bridge_> but its like 19:29 < bridge_> argh 19:29 < bridge_> i just want to write clean code, please give me the tools 19:29 < bridge_> isnt cpp supposed to be the "heres everything, go do whatever" lang 19:30 < bridge_> not really 19:30 < bridge_>