Time Nick Message 01:44 Pexin not gonna lie, i'll miss #7630 ..maybe someone *whisper whisper* will resurrect it before 6.0 01:44 ShadowBot https://github.com/minetest/minetest/issues/7630 -- Digging and placing: Send nodes instead of mapblocks to undo prediction by HybridDog 01:45 Pexin since i kinda suspect it may be necessary to add seq numbers or timestamps to the packets 07:09 sfan5 we have sequence numbers you know 08:36 celeron55 it's important to close issues and PRs to focus attention to important things 08:37 celeron55 it's a false reasoning that if you don't close anything, then everything will get done 08:37 celeron55 instead nothing will get done 08:37 MTDiscord agreed 08:38 celeron55 if you close enough of them, then two things happen: 1) the remaining amount feels more manageable, so things get done, and 2) it temporarily focuses attention to the ones being closed, bringing up some of them if they actually were important 08:38 MTDiscord PRs can be revived when the author picks them up again after a while, as I did with #12388 08:38 ShadowBot https://github.com/minetest/minetest/issues/12388 -- Extend bone override capabilities by appgurueu 08:38 MTDiscord Same for issues like #12372 08:38 ShadowBot https://github.com/minetest/minetest/issues/12372 -- Rotatable entity selectionboxes 08:38 MTDiscord Bonus: Creating new issues/PRs puts them at the top of the list :) 08:39 celeron55 a mundane analogy is cleaning your desk 09:12 MTDiscord what's the difference between the DEBUG and NDEBUG constants? 09:16 rubenwardy they're opposites in terms of value 09:16 rubenwardy NDEBUG is defined by the spec, DEBUG is nonstandard 09:17 rubenwardy so you should use NDEBUG 09:26 MTDiscord oh alright, yeah I see there's only two uses of DEBUG inside of defaultsettings.cpp while NDEBUG is used everywhere else, I guess that makes sense then 09:27 rubenwardy those should definitely be replaced 10:04 Zughy[m] luatic: also, the tag "Adoption needed" is perfect to filter the ones that were approved by core devs but that somehow were closed because reasons 12:40 MTDiscord Bug composting doesn't necessarily drag a project down, so long as devs know which end of the priority queue they're working from, and triagers know how deep into the pile to attempt to sort and the point beyond which it stops mattering. 12:41 MTDiscord Bugs beneath that threshold never actually get fixed, but they serve a political purpose in making bug reporters believe that their bug has successfully been reported and thus not make a big stink about them. 12:43 MTDiscord I have actually stirred the pile of decomposing issues in my own projects and have something interesting shake out. But it's fine to close them too ... just make sure that users reporting issues know to search ALL issues for an existing report, not just open ones... 13:06 erle depends on the project i guess. mozilla keeps bugs open and sometimes they get fixed after 17 years or so 13:06 rubenwardy Krock, sfan5: is #12185 still good for you? 13:06 ShadowBot https://github.com/minetest/minetest/issues/12185 -- Add register dialog to separate login/register by rubenwardy 13:06 rubenwardy erle: bugs should be kept open if they're still confirmed 13:07 rubenwardy if they can't be reproduced 13:07 rubenwardy if they can't be reproduced, then they should be closed 13:07 erle i agree. i mean, i don't even report stuff i can't reliably reproduce. 14:45 Pexin >not just open ones 14:46 Pexin I find that extremely counterintuitive 14:48 Pexin ..but in retrospect, I suppose I do tend to do that anyway 15:03 erle Pexin for example, i encountered some kind of bug that occured rarely where a mapblock was not updated on the client until the client interacted with it 15:11 MTDiscord erle: could this be related to #7630? 15:11 ShadowBot https://github.com/minetest/minetest/issues/7630 -- Digging and placing: Send nodes instead of mapblocks to undo prediction by HybridDog 15:15 erle unclear to me. 15:17 erle what it looks like on the client is that when a structure is being placed under some cirumstances either a single node or the entirety of it did not get to the client 15:17 erle it might be two different bugs actually 15:18 erle you could goad the server into correcting this by digging something or placing something where the structure should be 15:19 erle i was never able to reproduce this reliably, so i never filed an issue 15:21 erle luatic if on a public server you ever see a tree with a single node of wood clearly missing, try placing something where the hole is. 15:21 erle most of the time it will be just a hole 15:21 erle sometimes your client gets told that nope, not possible, there was tree all along 17:18 erle Zughy[m] where is the code for your mainmenu redesign? 17:19 erle or is it just mockups? 17:20 rubenwardy mockups 17:20 rubenwardy those are mock ups, there are people working on the code 17:20 rubenwardy design before code though 17:20 rubenwardy Minetest's current mainmenu is due to code before design 17:25 erle i have done web frontend work in the past and IMO the best designs are mockups that are made in code itself, i.e. potemkin villages without much functionality 17:25 erle i was asking for the code to see what is feasible given the state of the UI code 17:31 MTDiscord erle: @wsor seems to be in charge of the code 17:36 rubenwardy If you make it in code, you focus too much on the code rather than the design 17:36 erle i follow the philosophy that honest design works with the materials, not in spite of them. unless, of course, i am given an awful API. hehe. 17:38 erle my favourite industrial design example for this is having a metal hull for a microwave vs one with laminated wooden veneer. one of the designs does not stand the test of time, because the material is not up to the task. 17:39 erle also needing to code often makes clear what is a stupid idea 17:41 Zughy[m] that's not how it works but okay 17:41 erle e.g. “if this box is checked these other boxes should also be checked automatically” is requested often in UI, but such state management invites complexity. in all cases where i have seen such a proposal, rethinking the UI elements entirely and coming up with something different was the better solution – not because it was easier to code, but because it was easier to understand, i.e. it had less hidden state. 17:42 erle anyway. wsor can i take a look at the existing main menu code overhaul repo, if it indeed exists?