00:29 <+bridge> [ddnet] An atomic really sounds like the least impacting of all the available options 00:30 <+bridge> [ddnet] The other options I can think of are far worse like locking 00:31 <+bridge> [ddnet] https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html it compiles down to the same instructions even, just a source complexity 00:31 <+bridge> [ddnet] at least on x86 or if we used relaxed memory order 00:32 <+bridge> [ddnet] Don't think relaxed would be what we want here 00:33 <+bridge> [ddnet] it's basically the current behavior, just without the UB 00:33 <+bridge> [ddnet] for console_log_level, it'd probably be okay, at least I can't think of any weird stuff 00:33 <+bridge> [ddnet] Ah yep 00:36 <+bridge> [ddnet] is there any risk of conflict? I don't think people change config that often, otherwise, just declare it volatile? 00:36 <+bridge> [ddnet] volatile is wrong there 00:36 <+bridge> [ddnet] volatile is not a thread synchronization primitive 00:37 <+bridge> [ddnet] oh this discussion again haha 00:37 <+bridge> [ddnet] @Learath2 i remember ur rant 00:37 <+bridge> [ddnet] Volatile is definitely wrong here :D 00:37 <+bridge> [ddnet] It won't even emit a fence 00:37 <+bridge> [ddnet] relaxed won't emit a fence either 00:37 <+bridge> [ddnet] https://wiki.sei.cmu.edu/confluence/display/c/CON02-C.+Do+not+use+volatile+as+a+synchronization+primitive 00:38 <+bridge> [ddnet] Hence I said I don't think relaxed is the best idea here 00:38 <+bridge> [ddnet] But it will definitely fix the UB 00:40 <+bridge> [ddnet] i do believe volatile is enough for this use case 00:40 <+bridge> [ddnet] it forces to reload the value from memory 00:40 <+bridge> [ddnet] let hardware cohenrecy do its job 00:40 <+bridge> [ddnet] let hardware coherency/ do its job 00:40 <+bridge> [ddnet] let hardware coherency do its job 00:41 <+bridge> [ddnet] bad bad bad 00:41 <+bridge> [ddnet] It doesn't actually fix the UB as far as the standard is concerned 00:42 <+bridge> [ddnet] Volatile doesnt provide a synchronization point, so the two threads will be accessing memory out of sync 00:42 <+bridge> [ddnet] config variable change once every 36 of the month, not a big deal 00:43 <+bridge> [ddnet] @Chairn you get the same behavior with relaxed atomics, except it's without the UB 00:46 <+bridge> [ddnet] Why would you want to invoke nasal demons when you can avoid them? 00:47 <+bridge> [ddnet] Even compiler people can't agree on what the hell volatile can guarantee, I doubt the standards people are sure either. Relaxed atomics on the other hand have very well defined semantics 00:47 <+bridge> [ddnet] https://www.youtube.com/watch?v=KJW_DLaVXIY 00:48 <+bridge> [ddnet] if you have one hour of free tile 00:48 <+bridge> [ddnet] if you have one hour of free time 01:08 <+bridge> [ddnet] anyone think it would be fixable to patch "Please balance teams!" for more than just race modes? 01:08 <+bridge> [ddnet] heinrich suggested MACRO_CONFIG_INT for it 01:08 <+bridge> [ddnet] no MACRO_CONFIG_INT pls 01:08 <+bridge> [ddnet] wait what should we use 01:08 <+bridge> [ddnet] I suggested making it a flag the server can send 01:08 <+bridge> [ddnet] i guess i assumed you meant sv_ 01:08 <+bridge> [ddnet] but maybe you mean just in snap 01:09 <+bridge> [ddnet] just in snap, I meant 01:09 <+bridge> [ddnet] ye makes sense 01:09 <+bridge> [ddnet] i guess so 01:09 <+bridge> [ddnet] what netobj 01:17 <+bridge> [ddnet] Hey what do you guys think of this pr? I think deen wants some more opinions before merging 01:17 <+bridge> [ddnet] 01:17 <+bridge> [ddnet] we have some game info object 01:19 <+bridge> [ddnet] wow so nice but margins in a more square ratio look kinda small 01:19 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/967202934922297374/unknown.png 01:19 <+bridge> [ddnet] like with feet and above 01:19 <+bridge> [ddnet] OT: maybe some of u can help 01:19 <+bridge> [ddnet] saved a game and cant remember save name... 01:19 <+bridge> [ddnet] where i can find it? 01:20 <+bridge> [ddnet] #questions and it's in ddnet-saves.txt 01:20 <+bridge> [ddnet] Yeah that could be bigger 01:20 <+bridge> [ddnet] ty 01:20 <+bridge> [ddnet] hard to work with existing space already. i suggest making them a lot smaller 01:21 <+bridge> [ddnet] and adding a label "Default eyes" 01:21 <+bridge> [ddnet] unclear maybe at first what it does 01:21 <+bridge> [ddnet] Hm I'm actually a little intrigued whether a better answer exists to this kind of synchronization problem where writes are much less frequent than reads 01:21 <+bridge> [ddnet] I mean on x86, it works perfectly fine with AcqRel semantics of atomics 01:23 <+bridge> [ddnet] @Learath2 https://github.com/ddnet/ddnet/pull/5013#pullrequestreview-950687001 asked some questions if you're interested 01:33 <+bridge> [ddnet] I can answer some tomorrow, I really need to sleep asap but I have atomics on my mind 01:34 <+bridge> [ddnet] best package to include some code in your latex 01:35 <+bridge> [ddnet] ngl it was so weird to come here and see "emit a fence" without context 01:35 <+bridge> [ddnet] i was like wtf is that 01:36 <+bridge> [ddnet] this a fence 01:36 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/967207270666612756/unknown.png 01:38 <+bridge> [ddnet] now imagine your computer throwing this at your face because you didn't synchronize your thread 01:38 <+bridge> [ddnet] now imagine your computer throwing this at your face because you didn't synchronize your threads 05:18 <+bridge> [ddnet] ubuntu 22 released 07:26 <+bridge> [ddnet] I agree with lynn smaller and a label would also be good. 07:26 <+bridge> [ddnet] 07:26 <+bridge> [ddnet] But I find this version also good https://user-images.githubusercontent.com/22122579/163871026-3845e192-547d-498c-a8cd-5752dadc8ea6.png 07:26 <+bridge> [ddnet] You could also solve the lable problam possibly by adding to each button a tooltip, like "Set Angry eyes as default eyes", you would have to test how that comes out. 07:27 <+bridge> [ddnet] I agree with lynn smaller and a label would also be good. 07:27 <+bridge> [ddnet] 07:27 <+bridge> [ddnet] But I find this version also good https://user-images.githubusercontent.com/22122579/163871026-3845e192-547d-498c-a8cd-5752dadc8ea6.png 07:27 <+bridge> [ddnet] You could also solve the label problem possibly by adding to each button a tooltip, like "Set Angry eyes as default eyes", you would have to test how that comes out. 07:27 <+bridge> [ddnet] Thats how it normally looks, it only shows below in the sqaureish aspect ratios 07:28 <+bridge> [ddnet] I think the tooltip is a good idea, adding a label might be hard when its squeezed in between 07:32 <+bridge> [ddnet] The icon size is the same in all the images the aspect ratio is all that changes 09:13 <+bridge> [ddnet] maybe put skin prefix to the search filters as popup or smth 09:15 <+bridge> [ddnet] how about have the last selected emote of the emote wheel 09:15 <+bridge> [ddnet] and alawys try that on any server 09:15 <+bridge> [ddnet] thats probably what the user wants anyway 09:22 <+bridge> [ddnet] TIL in C++, static variables get destructed after main finishes!? 09:23 <+bridge> [ddnet] that seems insane in the context of multi-threading to me 09:23 <+bridge> [ddnet] Rly? 09:23 <+bridge> [ddnet] other threads might still use those global variables 09:24 <+bridge> [ddnet] I'm the only one who thinks that eye thing shouldnt be added? I like eyes to have a meaning 09:25 <+bridge> [ddnet] @heinrich5991 does rust, or llvm do the same? 09:26 <+bridge> [ddnet] Also is this for just main or for any entry point (embedded?) 09:26 <+bridge> [ddnet] I only know of main, no further details 09:26 <+bridge> [ddnet] no, rust does the (IMO sane) other thing 09:27 <+bridge> [ddnet] why do you want to kill the main thread without joining the other threads tho 09:29 <+bridge> [ddnet] ddnet does that, for example 09:29 <+bridge> [ddnet] other threads might be stuck 09:29 <+bridge> [ddnet] I guess you have to call _Exit in that case 09:30 <+bridge> [ddnet] ah no, `quick_exit` 09:30 <+bridge> [ddnet] ah no, _Exit, nvm 09:31 <+bridge> [ddnet] what threads do we keep open 09:31 <+bridge> [ddnet] when signaling or smth? 09:31 <+bridge> [ddnet] I don't quite see when else C++ would destruct the statics 09:32 <+bridge> [ddnet] guess there is always a way xd 09:32 <+bridge> [ddnet] I guess the sql thread and the curl thread could possibly live past main, if I recall correctly 09:32 <+bridge> [ddnet] ok 09:32 <+bridge> [ddnet] we should fix that regardless 09:32 <+bridge> [ddnet] why? 09:33 <+bridge> [ddnet] i dont think its nice style to leave stuff open u opened 09:33 <+bridge> [ddnet] the OS closes it 09:33 <+bridge> [ddnet] faster than you can do. you only slow things down by closing it yourself 09:33 <+bridge> [ddnet] u also dont need to deallocate memory 09:33 <+bridge> [ddnet] the os does that 09:33 <+bridge> [ddnet] weren't you the person obsessed with performance? ^^ 09:33 <+bridge> [ddnet] yea, but at program exit, it's literally doing no useful work ^^ 09:33 <+bridge> [ddnet] correctness is still the most important thing 09:33 <+bridge> [ddnet] it is correct to not free memory at program exit 09:34 <+bridge> [ddnet] and never freeing memory is also correct, probably, it's just not useful because you might run out of it 09:34 <+bridge> [ddnet] It's still probably a trivial amount of time lost if we join all threads before dying 09:34 <+bridge> [ddnet] oh, then why do u use c++ 09:34 <+bridge> [ddnet] :monkalaugh: 09:34 <+bridge> [ddnet] joke joke 09:34 <+bridge> [ddnet] @Learath2 only if we have some way to guarantee that they're done 09:35 <+bridge> [ddnet] the score threads in particular have a timeout for joining precisely because they do not terminate 09:35 <+bridge> [ddnet] xd 09:35 <+bridge> [ddnet] 09:35 <+bridge> [ddnet] a language that prevents logic errros would fix all errors xd 09:35 <+bridge> [ddnet] but its true that closing stuff at exit doesnt pose a perfomance impact during the most critical parts of the program 09:35 <+bridge> [ddnet] e.g when playing 09:35 <+bridge> [ddnet] yes, if it comes for free, it's fine. or if it's useful for other stuff 09:36 <+bridge> [ddnet] anyway, i'd also argument that using static is bad 09:36 <+bridge> [ddnet] but we don't have to go to great lengths to do that. "useful for other stuff" might e.g. be "better readable valgrind output" 09:36 <+bridge> [ddnet] yee 09:36 <+bridge> [ddnet] in rare cases u might need them e.g. signaling states 09:36 <+bridge> [ddnet] but else u can always solve it in a better way 09:36 <+bridge> [ddnet] my PR introduces a new static 09:36 <+bridge> [ddnet] what's the better way? 09:36 <+bridge> [ddnet] the global logging instance 09:37 <+bridge> [ddnet] allocate it on main start 09:37 <+bridge> [ddnet] wtf they updated github 09:37 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/967328243688538143/unknown.png 09:37 <+bridge> [ddnet] and where do I put it? @Not Keks 09:37 <+bridge> [ddnet] On timeout, it'll be done. I don't see much harm to the main thread waiting for the sql thread to timeout, especially when we have no idea of the consequences of two servers running with the exact same settings at the same time 09:37 <+bridge> [ddnet] does matter use a shared pointer or smth like that 09:37 <+bridge> [ddnet] doesnt 09:37 <+bridge> [ddnet] do you expect to pass it to every function so it can log? 09:37 <+bridge> [ddnet] we should use unique_ptr and shared_ptr everywhere 09:37 <+bridge> [ddnet] What if the dangling sql thread causes some database issue? 09:37 <+bridge> [ddnet] isnt that c++11 09:38 <+bridge> [ddnet] @Learath2 I think we have a timeout for waiting for sql threads. if you're sure that it isn't needed, remove it 09:38 <+bridge> [ddnet] i'd not call it from a global context if u mean that yes 09:38 <+bridge> [ddnet] How about a shared_ptr at the very start of the thread? 09:38 <+bridge> [ddnet] Client()->LOG 09:38 <+bridge> [ddnet] 09:38 <+bridge> [ddnet] or Server()->Log 09:38 <+bridge> [ddnet] 09:38 <+bridge> [ddnet] or for specific components Log() as a function inside the class 09:38 <+bridge> [ddnet] @Not Keks sounds impractical *and* performance sensitive 09:39 <+bridge> [ddnet] You can keep the shared_ptr in TLS 09:39 <+bridge> [ddnet] i doubt that tbh 09:39 <+bridge> [ddnet] I do @Learath2 09:39 <+bridge> [ddnet] passing a parameter to each function does have performance implications 09:39 <+bridge> [ddnet] Client()->Log, Server()->Log, less so 09:39 <+bridge> [ddnet] maybe logs can live in Client() and Server() from the engine? 09:39 <+bridge> [ddnet] but they're still impractical because not everything knows about Client(), Server() 09:40 <+bridge> [ddnet] they would' need to explicitly get the pointer then 09:40 <+bridge> [ddnet] logging is a global concern in all languages I know of 09:40 <+bridge> [ddnet] can you show me a project that doesn't have a global logger, so I can see that it is at least a little bit practical? 09:40 <+bridge> [ddnet] but then also use the language logging xD 09:40 <+bridge> [ddnet] not a custom one 09:40 <+bridge> [ddnet] what about a thread holding the logger and using channels :monkalaugh: 09:41 <+bridge> [ddnet] @Not Keks but the "language logging" is also just a static variable 09:41 <+bridge> [ddnet] or another case for a global variable: 09:41 <+bridge> [ddnet] in rust, if a file is opened, the stdlib dynamically determines if the kernel has a bug 09:41 <+bridge> [ddnet] if it doesn't, it'll never do the duplicate system call again 09:41 <+bridge> [ddnet] that's a good use for a global variable 09:41 <+bridge> [ddnet] ah c++ doesnt support channels in the std 09:42 <+bridge> [ddnet] how would you solve that in a better way? 09:42 <+bridge> [ddnet] > dynamically determines if the kernel has a bug 09:42 <+bridge> [ddnet] how does it do that? 09:42 <+bridge> [ddnet] and what would that bug be 09:42 <+bridge> [ddnet] it checks whether the returned file descriptor has the CLOEXEC flag set after opening it with O_CLOEXEC 09:42 <+bridge> [ddnet] there's old kernels that don't know the flag, and apparently some less old kernels where this flag didn't work 09:43 <+bridge> [ddnet] ah ok 09:43 <+bridge> [ddnet] but that looks like just holding a bool, doesnt logging have side effects or whathever it is called 09:44 <+bridge> [ddnet] @heinrich5991 can't we have the actual instance on heap and only keep the shared_ptr in the static/thread_local? 09:44 <+bridge> [ddnet] but the theory was that "all global variables are bad" @Ryozuki 09:44 <+bridge> [ddnet] and I'm arguing that "absolutely not!" 09:44 <+bridge> [ddnet] ah ok 09:45 <+bridge> [ddnet] the badness comes in the design already, why is the std lib function not part of a class 09:45 <+bridge> [ddnet] are u suggesting java? 09:45 <+bridge> [ddnet] why would it? less performance 09:45 <+bridge> [ddnet] xd 09:45 <+bridge> [ddnet] depends, the OS has to be redesigned for that too 09:45 <+bridge> [ddnet] why would you need to do this check over and over again, just because some part of the code needs to construct the file opening object again 09:46 <+bridge> [ddnet] global variables have a performance benefit 09:47 <+bridge> [ddnet] @Learath2 not sure what you mean. currently, we keep a raw pointer in the global variable/thread local variable 09:47 <+bridge> [ddnet] they need to check if the variable was allocated in certain scenarious 09:47 <+bridge> [ddnet] e.g. if u use static inside a function 09:47 <+bridge> [ddnet] if we stay with "static" 09:47 <+bridge> [ddnet] And where does the logger instance itself get allocated? 09:47 <+bridge> [ddnet] yes. let's say "you can use global variables for a performance benefit" @Not Keks 09:47 <+ChillerDragon> oh no major log rewrite... i can smell conflicts in my 100 ddnet forks :c 09:47 <+bridge> [ddnet] @Learath2 the global loggers on the heap, getting leaked 09:48 <+bridge> [ddnet] @ChillerDragon I tried to keep the diff minimal. all existing logging code should continue to work, only the logging initialization is different 09:48 <+ChillerDragon> pog 09:48 <+bridge> [ddnet] continue to work (even better!) 09:48 <+bridge> [ddnet] btw is dbg_msg active in release builds? i always wanted to leave some more detail logging with dbg_msg but always feared it might pollute release 09:48 <+bridge> [ddnet] because now you can see output from other threads in f1 and rcon 09:49 <+bridge> [ddnet] we could make LOG_TRACE only active in debug builds @Ryozuki (if we add a macro for it) 09:49 <+bridge> [ddnet] I may have missed the issue here (just woke up), I thought your logger got destructed before the threads were done, if you aren't concerned about the leak, then I don't see any issue here 09:49 <+bridge> [ddnet] ye that would be cool 09:50 <+bridge> [ddnet] it would be even more cool to also enable scoped logs via env vars 09:50 <+bridge> [ddnet] no issue. it was just an unrelated post I saw on reddit @Learath2 ^^ 09:50 <+bridge> [ddnet] so if i want to debug some client specific thing i can get detailed logs on that 09:50 <+bridge> [ddnet] like any decent app 09:50 <+bridge> [ddnet] check my PR and comment on the design questions I have @Ryozuki 09:50 <+bridge> [ddnet] https://github.com/ddnet/ddnet/pull/5013 09:51 <+bridge> [ddnet] ill check 09:52 <+bridge> [ddnet] @heinrich5991 how does rust go about destructing it's statics? Just using the compilers knowledge of usage? 09:52 <+bridge> [ddnet] it doesn't destruct statics 09:52 <+bridge> [ddnet] Borrow checker blackmagic 09:53 <+bridge> [ddnet] statics live for 'static :BASED: 09:53 <+bridge> [ddnet] that's how I learned about the issue in C++, because someone complained about missing destruction in /r/rust 09:54 <+bridge> [ddnet] That sounds more concerning to me. How would you do cleanup in a static then? 09:54 <+bridge> [ddnet] "log_log_impl" "log_log_color" honestly i prefer more the classes style instead of c style 09:54 <+bridge> [ddnet] also it would be cool if u used doxygen style docs 09:54 <+bridge> [ddnet] commet in the PR pls 09:54 <+bridge> [ddnet] so i dont need to parse this in the future :( 09:55 <+bridge> [ddnet] anyway, independent of good or bad 09:55 <+bridge> [ddnet] before we put _Exit now everywhere, keep in mind that other OS rely on global cleanup, e.g. Android 09:55 <+bridge> [ddnet] 09:55 <+bridge> [ddnet] It would else just leak there 09:55 <+bridge> [ddnet] 09:55 <+bridge> [ddnet] anyway, independent of good or bad 09:55 <+bridge> [ddnet] before we put _Exit now everywhere, keep in mind that other OS rely on global cleanup, e.g. Android 09:55 <+bridge> [ddnet] 09:55 <+bridge> [ddnet] It would else just not deallocate there 09:55 <+bridge> [ddnet] can you elaborate @Not Keks? 09:55 <+bridge> [ddnet] i edited 09:55 <+bridge> [ddnet] i meant not deallocate 09:56 <+bridge> [ddnet] I still don't quite get it. if your app leaks memory, it affects the whole system even after the app is closed? 09:56 <+bridge> [ddnet] e.g. the java interface calls the .so file 09:56 <+bridge> [ddnet] lets say 09:56 <+bridge> [ddnet] libDDNet.so 09:56 <+bridge> [ddnet] 09:56 <+bridge> [ddnet] and we use some static variables that require specific intialization objects 09:56 <+bridge> [ddnet] 09:56 <+bridge> [ddnet] if its not deallocated 09:56 <+bridge> [ddnet] 09:56 <+bridge> [ddnet] it also isnt allocated 09:56 <+bridge> [ddnet] and that creates unwanted behavior for our android port 09:57 <+bridge> [ddnet] you mean that if a dynamic library is loaded and then not used anymore at some point, the memory is still leaked? 09:57 <+bridge> [ddnet] not leaked, but its still as is 09:57 <+bridge> [ddnet] the global variables are untouched 09:58 <+bridge> [ddnet] and they wont get to initlaize again 09:58 <+bridge> [ddnet] by explicitly writing code for it. I guess I don't see a use case rn so I can't really say how to handle it 09:58 <+bridge> [ddnet] yea, makes sense if the dynamic library isn't unloaded 09:59 <+bridge> [ddnet] yes but as said, since we rely on the intiialization sometimes we have to unload it explicitly 09:59 <+bridge> [ddnet] else opening the client agian in android will not work 10:00 <+bridge> [ddnet] the problem there is code that's not written in mind with something that's executed twice, if I understand it correctly? @Not Keks 10:00 <+bridge> [ddnet] i see you use a lot of shared_ptr in the cpp files, but then some functions return `ILogger *l` as is, is it common practice? 10:00 <+bridge> [ddnet] yes 10:00 <+bridge> [ddnet] I see 10:03 <+bridge> [ddnet] @Ryozuki where do I see example doxygen docs? 10:03 <+bridge> [ddnet] here 10:03 <+bridge> [ddnet] or u mean rendered? 10:03 <+bridge> [ddnet] no 10:05 <+bridge> [ddnet] doxygen has supports for groups 10:05 <+bridge> [ddnet] so free functions can be grouped 10:05 <+bridge> [ddnet] its nice for new ppl 10:07 <+bridge> [ddnet] I think I did that because I sometimes need them as `std::unique_ptr`, sometimes as `std::shared_ptr` and sometimes as raw pointer 10:07 <+bridge> [ddnet] > std::unique_ptr is the C++11 way to express exclusive ownership, but one of its most attractive features is that it easily and efficiently converts to a std::shared_ptr. 10:07 <+bridge> [ddnet] > 10:07 <+bridge> [ddnet] > This is a key part of why std::unique_ptr is so well suited as a factory function return type. 10:08 <+bridge> [ddnet] ah, interesting 10:08 <+bridge> [ddnet] TIL 10:08 <+bridge> [ddnet] https://stackoverflow.com/questions/37884728/does-c11-unique-ptr-and-shared-ptr-able-to-convert-to-each-others-type 10:08 <+bridge> [ddnet] comment on the PR with that please, so it doesn't get lost 10:09 <+bridge> [ddnet] ok 10:09 <+bridge> [ddnet] > Once you’ve turned lifetime management of a resource over to a `std::shared_ptr`, there’s no changing your mind. Even if the reference count is one, you can’t reclaim ownership of the resource in order to, say, have a `std::unique_ptr` manage it. 10:09 <+bridge> [ddnet] weird, with a reference count of 1, it should be safe to turn back 10:09 <+bridge> [ddnet] hmm 10:10 <+bridge> [ddnet] ah, I guess it's because multiple threads might have a reference to the same `std::shared_ptr` 10:10 <+bridge> [ddnet] makes sense, nvm me 10:10 <+bridge> [ddnet] (with rust, you can still turn it back though! 😛 ) 10:11 <+bridge> [ddnet] :o 10:11 <+bridge> [ddnet] what do u think about doxygen? 10:12 <+bridge> [ddnet] btw we have docs generated every day (or week i dont remember): https://codedoc.ddnet.tw/ 10:12 <+bridge> [ddnet] i also started this some time ago https://wiki.ddnet.tw/wiki/Development 10:12 <+bridge> [ddnet] if any time u want to add something 10:12 <+bridge> [ddnet] I like docs that say something 10:13 <+bridge> [ddnet] well the doxygen is just porting the system.h docs 10:13 <+bridge> [ddnet] yes 10:13 <+bridge> [ddnet] so idk what that has to do here 10:13 <+bridge> [ddnet] :PES2_Pray: 10:14 <+bridge> [ddnet] I don't like redundant docs that are just restating the function name or the parameter names. I've seen such docs added in the past in projects that tried to increase some documentation metric 10:14 <+bridge> [ddnet] you asked me what I think about adding doxygen 10:14 <+bridge> [ddnet] ah well 10:14 <+bridge> [ddnet] i meant about system.h 10:14 <+bridge> [ddnet] but ye 10:14 <+bridge> [ddnet] I think those redundant docs are worse than no docs 10:14 <+bridge> [ddnet] ah 10:14 <+bridge> [ddnet] we already had this discussion 10:14 <+bridge> [ddnet] u can have it ur way 10:14 <+bridge> [ddnet] xDDDD 10:14 <+bridge> [ddnet] ❤️ 10:15 <+bridge> [ddnet] if we agree then 10:15 <+bridge> [ddnet] try to use doxygen style docs on ur pr when u can 10:15 <+bridge> [ddnet] yea, the huge diff isn't optimal, but I don't see a better way to do it 10:16 <+bridge> [ddnet] i dislike that diff is always taken into account, this removes interest in large refactors that might be optimal 10:16 <+bridge> [ddnet] why does the vcs get in the way of dev interests 10:17 <+bridge> [ddnet] I don't like huge diffs because it makes it harder for mods and vanilla patch porting 10:17 <+bridge> [ddnet] so I'd say it's not related to the vcs 10:17 <+bridge> [ddnet] i dont think many mods change system.h 10:17 <+bridge> [ddnet] so it shouldnt be hard to merge 10:17 <+bridge> [ddnet] one could arguee that this is the main reason ddnet (and teeworlds) is so mod unfriendly in fact 10:17 <+bridge> [ddnet] bcs nobody changes it bad design 10:17 <+bridge> [ddnet] true 10:18 <+bridge> [ddnet] I don't think mod friendly design is being held back by that ^^ 10:18 <+bridge> [ddnet] the gamecontroller is essentially useless, u cant make a mod just adding one 10:18 <+bridge> [ddnet] which was the main intended way 10:18 <+bridge> [ddnet] people explicitly refactored that, IIRC 10:18 <+bridge> [ddnet] ask chillerdragon whether that contains merge conflicts for him 10:19 <+bridge> [ddnet] tbh idc if it does 10:19 <+bridge> [ddnet] xD 10:19 <+bridge> [ddnet] even if it sounds rude 10:19 <+bridge> [ddnet] true, the 2 users that use chillerbot 10:19 <+bridge> [ddnet] but you just claimed that it doesn't 10:19 <+bridge> [ddnet] so you admit that statement might have been bullshit? ^^ 10:20 <+bridge> [ddnet] i didnt claim it doesnt 10:20 <+bridge> [ddnet] > i dont think many mods change system.h 10:20 <+bridge> [ddnet] > so it shouldnt be hard to merge 10:20 <+bridge> [ddnet] i said many mods dont change this 10:20 <+ChillerDragon> i guess spamming system.h with comments should be fine. Its def conflicts but not too dramatic. But would be nice if we can also get it in teeworlds :D 10:20 <+bridge> [ddnet] what mods do you think about here @Ryozuki? 10:20 <+bridge> [ddnet] name some examples so I can check 10:20 <+bridge> [ddnet] simple mods that change gameplay only 10:20 <+bridge> [ddnet] e.g im porting xpanic to modern ddnet 10:20 <+bridge> [ddnet] that mod didnt touch system.h ever iirc 10:20 <+bridge> [ddnet] got a link? 10:21 <+bridge> [ddnet] i only have a link to the original xpanic 10:21 <+bridge> [ddnet] i still havent uploaded mine 10:21 <+bridge> [ddnet] fine 10:21 <+ChillerDragon> i would also claim that as a mod it is good style to not touch system.h 10:21 <+bridge> [ddnet] have a link to the original? 10:21 <+bridge> [ddnet] https://github.com/kaitlynia/xpanic 10:21 <+bridge> [ddnet] well this one is updated 10:21 <+bridge> [ddnet] idk the original 10:21 <+bridge> [ddnet] https://github.com/teeworldsmods/teeworlds-xpanic 10:21 <+bridge> [ddnet] its good style to use boost and not use system.h 10:21 <+bridge> [ddnet] maybe its this one 10:21 <+bridge> [ddnet] ye lets use boost 10:22 <+bridge> [ddnet] do they enforce shared_ptr and unique_ptr? 10:22 <+bridge> [ddnet] no, please don't. exploding build times 10:22 <+bridge> [ddnet] xd 10:22 <+bridge> [ddnet] xddd 10:22 <+bridge> [ddnet] e.g. factorio ripped it out due to that reason 10:22 <+bridge> [ddnet] is it just ddnet or do most codebases not adopt shared_ptr unique_ptr etc 10:22 <+bridge> [ddnet] depends 10:23 <+bridge> [ddnet] it's not that simple to adopt it, I think. you could try to do it 10:23 <+bridge> [ddnet] there are some nonobvious relationships, I think 10:23 <+bridge> [ddnet] @heinrich5991 10:23 <+bridge> [ddnet] another mod for u to check 10:24 <+bridge> [ddnet] maybe this one modified system.h but its cuz it was rly old and lacked utf8 support 10:24 <+bridge> [ddnet] but i dont see any reason why most gameplay related mods modify system.h 10:24 <+bridge> [ddnet] chiller likes to do weird stuff 10:24 <+bridge> [ddnet] because there's OS abstractions that you need, probably 10:25 <+ChillerDragon> idk i think in most cases i tried to push those changes upstream like str_startswith_nocase and shit 10:25 <+bridge> [ddnet] or stuff that's buggy. I mean we only recently fixed `str_copy` to not produce invalid UTF-8 10:25 <+ChillerDragon> but for my curses client for example i had to wrap dbg_msg() into some macros 10:25 <+bridge> [ddnet] u can wrap c apis around unique_ptr 10:25 <+bridge> [ddnet] ```cpp 10:25 <+bridge> [ddnet] struct SDLWindowDestroyer 10:25 <+bridge> [ddnet] { 10:25 <+bridge> [ddnet] void operator()(SDL_Window* w) const 10:25 <+bridge> [ddnet] { 10:25 <+bridge> [ddnet] SDL_DestroyWindow(w); 10:25 <+bridge> [ddnet] } 10:25 <+bridge> [ddnet] }; 10:25 <+bridge> [ddnet] 10:25 <+bridge> [ddnet] std::unique_ptr window_; 10:25 <+bridge> [ddnet] ``` 10:26 <+bridge> [ddnet] I encourage you to grep for `operator()` in our source 😉 10:27 <+bridge> [ddnet] ye i see 10:57 <+bridge> [ddnet] This would be one of the biggest steps to mod friendliness, if we could concentrate our changes into a gamecontroller it'd be amazing 10:59 <+bridge> [ddnet] I actually had quite a few attempts at this, I kept getting stuck when doing entities and tiles iirc 11:00 <+bridge> [ddnet] It needs something like getting the collision code to depend on the controller somehow, I just never quite figured it out 13:03 <+bridge> [ddnet] https://youtu.be/kPRA0W1kECg 13:03 <+ChillerDragon> > 15:28:24* +bridge | [ddnet] is protobuf used in games? 13:03 <+ChillerDragon> irc reply be like :D 13:03 <+ChillerDragon> @Ryozuki they seem to use it https://github.com/cxong/cdogs-sdl/wiki/Developer-Getting-Started:-Linux 13:29 <+bridge> [ddnet] https://openbenchmarking.org/embed.php?i=2204214-PTS-NVIDIASM12&sha=7f11011ebcfd&p=2 13:29 <+bridge> [ddnet] 13:29 <+bridge> [ddnet] lol mesa drivers best 13:29 <+bridge> [ddnet] too bad phoronix didnt include rx 6900 xt 13:29 <+bridge> [ddnet] would be cool to see amd on top 13:29 <+bridge> [ddnet] 13:29 <+bridge> [ddnet] but funny how good drivers can overcome hardware limits 14:47 <+ChillerDragon> Any rustian knows why my channel is not recieving data? :) 14:48 <+ChillerDragon> This code is run https://github.com/chidraqul/chidraqul5/blob/bd4bb4d506459b343e8c1689ba9877b9317e0dd0/src/client.rs#L153 14:48 <+ChillerDragon> this not :c https://github.com/chidraqul/chidraqul5/blob/bd4bb4d506459b343e8c1689ba9877b9317e0dd0/src/client.rs#L198 15:11 <+ChillerDragon> @heinrich5991 could you ellaborate on that? How does one implement a logger backend? https://github.com/chillerbot/chillerbot-ux/issues/94#issuecomment-1107453760 15:15 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/967413364395474985/gigasort.mp4 15:21 <+ChillerDragon> ^ rust thing is fixed 15:51 <+bridge> [ddnet]