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 |