Time Nick Message 15:21 Krock !tell Desour [#13633] I might just have found a way to make ProxySoundManager superfluous by inheritance (that also replaces the need for std::variant and std::visit): https://pastebin.com/JaQFxE0X - what do you think about this idea? 15:21 ShadowBot Krock: OK. 15:21 Krock <3 ShadowBot 15:21 ShadowBot ♥ Krock. 17:38 Desour Krock: idk what's the point about inheritance here. you could just pass the openalsoundmgr as param to the run( 17:39 Desour to the run() functions of the msgvisitor things 17:39 Desour also, you'd not get rid of the proxysoundmgr, as that is needed to provide a isoundmgr interface 17:49 Krock Desour: the point is to reduce redundancy. Of course it could be added to the function call, but it would be very repetitive for all 10-ish messages 17:50 Desour btw. Krock idk what you have against the visitor pattern stuff. it's not *that* complicated, and it's not the first time we're using the visitor pattern, see e.g. ClientEvent 17:50 Krock I had the feeling that it's implemented way more complicated than it should be, thus I came up with this idea - which might be worse than your implementation 17:51 Desour if you're using inheritance, you'd have std::move(msg)->run(this); I don't see redundancy there 17:51 Krock I mean the run() function declaration. repeated function arguments which would not be necessary 17:52 Desour the thing that's making it long is that you have to do some thing for each message type, aka for each function in isoundmgr. idk how that could be shrinked 17:53 Desour ah, so the benefit would be to have shorter to read function signatures? x) 17:54 Krock well yes, but more importantly, this way you have the data fields and the function call in the same place - and it can all be placed in the source file instead of the header 17:55 Krock it's only a question of organization, which is why I hoped for inputs from your side. I'll review the PR soon regardless 18:02 Desour ah, so you'd have the msg structs only in the cpp file, and their run function next to them. might be neat, idk if it's worth it though 18:04 MTDiscord Afaik we haven't entered feature freeze yet ...here's still hoping for mglua in 5.8 18:11 rubenwardy looks like it's still maked as WIP 18:15 Desour Krock: with inheritance it would look like this: https://github.com/Desour/minetest/commit/4a4c8584fe8b9aa22330ea0eacef3e81530efaa6 18:16 Desour (only a draft) 18:18 Desour the 13 complete struct definitions in a row look a bit spaghetti to me 18:27 Krock what does && mean after the function signature? 18:29 Krock also thanks for the draft. There's not much else that could be done in this case. In either case it will look messy 18:30 rubenwardy I suggest adding a comment to every place that you use &&, not just the parent type 18:30 rubenwardy to avoid having this question every time 18:31 Krock I suppose it's related to std::move 18:32 Desour && and const after function refer to the implicit this param 18:32 Desour and & 18:33 Desour it's like fun(const Self &&/&self, other params...) 18:34 Krock but why would you need that? it's already a member function 18:35 Desour it makes that you can only call the function with an rvalue this. e.g. `Type().fun()` is ok, `Type a; a.fun();` is not ok, `Type a; std::move(a).fun();` is ok 18:37 Krock alright. thanks for the explanation 18:37 Desour np :) 18:38 Krock rubenwardy: #12208 needs a rebase 18:38 ShadowBot https://github.com/minetest/minetest/issues/12208 -- Add support for translating content titles and descriptions by rubenwardy 18:46 rubenwardy done 18:46 Krock thank you 18:59 Krock rubenwardy: how can multiline mod descriptions be translated? 19:00 rubenwardy you can include multiline text in .conf with """ and then use @n in the .tr 19:00 rubenwardy @n is \n 19:00 Krock ah I see. moment. testing that. 19:02 Krock works 19:53 Desour merging #13633 in 15 19:53 ShadowBot https://github.com/minetest/minetest/issues/13633 -- [NOSQUASH] Move soundmanager into its own thread by Desour