Minetest logo

IRC log for #minetest-dev, 2022-05-31

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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
03:42 amicdict joined #minetest-dev
03:43 amicdict left #minetest-dev
03:43 amicdict joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
05:31 behalebabo joined #minetest-dev
05:31 calcul0n joined #minetest-dev
05:54 AliasAlreadyTake joined #minetest-dev
06:56 troller joined #minetest-dev
07:09 sfan5 we have sequence numbers you know
07:18 troller joined #minetest-dev
08:31 appguru joined #minetest-dev
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 <luatic> 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 <luatic> 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 <luatic> Same for issues like #12372
08:38 ShadowBot https://github.com/minetest/minetest/issues/12372 -- Rotatable entity selectionboxes
08:38 MTDiscord <luatic> Bonus: Creating new issues/PRs puts them at the top of the list :)
08:39 celeron55 a mundane analogy is cleaning your desk
08:57 Fixer joined #minetest-dev
09:12 MTDiscord <ROllerozxa> 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:20 YuGiOhJCJ joined #minetest-dev
09:26 MTDiscord <ROllerozxa> 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
10:07 troller joined #minetest-dev
10:18 troller joined #minetest-dev
10:22 HuguesRoss joined #minetest-dev
11:34 behalebabo joined #minetest-dev
12:20 proller joined #minetest-dev
12:40 MTDiscord <Warr1024> 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 <Warr1024> 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 <Warr1024> 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
14:52 proller joined #minetest-dev
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 <luatic> 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 <luatic> 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?
20:21 fluxionary joined #minetest-dev
20:50 proller joined #minetest-dev
20:52 troller joined #minetest-dev
21:42 proller joined #minetest-dev
22:22 kaeza joined #minetest-dev
22:33 panwolfram joined #minetest-dev
23:06 Baytuch joined #minetest-dev
23:57 Alias joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext