| Time |
Nick |
Message |
| 02:20 |
|
fluxionary joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:48 |
MTDiscord |
<MisterE> its still not relaying messages |
| 05:24 |
|
calcul0n joined #minetest-dev |
| 07:05 |
|
definitelya joined #minetest-dev |
| 07:07 |
definitelya |
Hi, something is messed up with world creation. It creates the world under a different game every time (even resetting mod.conf didn't help). |
| 07:07 |
definitelya |
s/mod.conf/minetest.conf |
| 08:10 |
|
appguru joined #minetest-dev |
| 08:22 |
|
Warr10240 joined #minetest-dev |
| 08:44 |
|
definitelya left #minetest-dev |
| 09:04 |
|
Warr1024 joined #minetest-dev |
| 09:25 |
|
clavi joined #minetest-dev |
| 09:25 |
|
clavi joined #minetest-dev |
| 10:04 |
|
Noisytoot joined #minetest-dev |
| 10:17 |
|
Noisytoot joined #minetest-dev |
| 10:38 |
|
Fixer joined #minetest-dev |
| 10:47 |
|
appguru joined #minetest-dev |
| 11:12 |
MTDiscord |
<GoodClover> Once Bountysource is fixed, £5 bounty on #11640. |
| 11:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/11640 -- Manual media management |
| 11:16 |
|
appguru joined #minetest-dev |
| 11:38 |
|
Noisytoot joined #minetest-dev |
| 12:10 |
|
Noisytoot joined #minetest-dev |
| 12:17 |
MTDiscord |
<ROllerozxa> passive aggressive reminder that I would like a wiki account: https://forum.minetest.net/viewtopic.php?p=412951#p412951 |
| 12:25 |
Krock |
Calinou: ^ |
| 12:35 |
|
Noisytoot joined #minetest-dev |
| 12:42 |
|
Noisytoot joined #minetest-dev |
| 12:57 |
|
Noisytoot joined #minetest-dev |
| 13:12 |
|
calcul0n joined #minetest-dev |
| 13:16 |
sfan5 |
@rollerozxa what definitelya reported is caused by your commit https://github.com/minetest/minetest/commit/2133fc84c4e604e9365e99ac8dd597c8fb499b92 |
| 13:16 |
sfan5 |
please fix |
| 13:16 |
sfan5 |
or actually Krock added the change I guess |
| 13:17 |
Krock |
checking logs.... |
| 13:17 |
ROllerozxa |
what the |
| 13:18 |
Krock |
hmmm |
| 13:18 |
ROllerozxa |
oh, my PR to fix texture pack sorting |
| 13:20 |
MTDiscord |
<luatic> the mainmenu codebase is an absolute mess |
| 13:27 |
ROllerozxa |
it was just supposed to be a trivial PR to flip the ordering of texture packs, changing mods/games/texturepacks to sort by title rather than name should have been left for another PR :S |
| 13:43 |
MTDiscord |
<MisterE> sfan5, what would you think about embedding this lua-scriptable, embeddable real-time music generation library in minetest? https://github.com/pac-dev/protoplug |
| 13:46 |
MTDiscord |
<MisterE> or, embedding alda: https://alda.io/ |
| 13:53 |
sfan5 |
where would it run? on the client? |
| 13:54 |
Krock |
currently fixing the mainmenu thing |
| 13:54 |
Krock |
please no touchy |
| 14:11 |
MTDiscord |
<MisterE> yes. It would probably use the mod channels api to send musical scripts to the client |
| 14:11 |
MTDiscord |
<MisterE> alda would be ideal for that, since there are no constructs that can do anything other than play music in alda |
| 14:12 |
MTDiscord |
<MisterE> sfan5 |
| 14:34 |
|
Desour joined #minetest-dev |
| 14:41 |
Desour |
alda requires java (according to <https://alda.io/install/>), which would be quite a big new dependency |
| 14:49 |
Desour |
(for tracker music, we should rather use something like libopenmpt, I guess) |
| 14:52 |
ROllerozxa |
libopenmpt support would be awesome |
| 14:54 |
Desour |
btw. regarding sounds: in singleplayer, if you press esc, the whole game pauses (i.e. object animations). should sounds be paused, too? |
| 14:56 |
Krock |
yes |
| 14:57 |
Krock |
looped sounds never end. that's a bit annoying when pausing the game |
| 15:04 |
Krock |
#12758 ROllerozxa |
| 15:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/12758 -- Mainmenu: Properly sort mods and games by SmallJoker |
| 15:05 |
Desour |
I see, thx Krock! |
| 15:16 |
|
appguru joined #minetest-dev |
| 16:33 |
|
Dacmot joined #minetest-dev |
| 17:11 |
Krock |
will merge #12708 and #12729 in 15 minutes |
| 17:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/12708 -- [no squash] Serialize: LuaJIT workaround & restore forwards compat by appgurueu |
| 17:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/12729 -- Fix potential use-after-free with item metadata by TurkeyMcMac |
| 17:13 |
|
Taoki joined #minetest-dev |
| 17:13 |
Krock |
#11431 too |
| 17:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/11431 -- Add paramtype2s for 4 horizontal rotations and 64 colors by Wuzzy2 |
| 17:18 |
sfan5 |
I looked at that yesterday without making any comments and found a few places in the docs that could be improved |
| 17:18 |
sfan5 |
also the manual comparisons with param_type_2 == this || param_type_2 == that || param_type_2 == those don't scale |
| 17:18 |
sfan5 |
but don't wait for that |
| 17:19 |
Krock |
feel free to leave a comment there |
| 17:19 |
Krock |
I'll wait. It's a feature after all |
| 17:23 |
|
appguru joined #minetest-dev |
| 17:24 |
appguru |
Krock: Could you review https://github.com/minetest/minetest/pull/12353? The code is pretty simple, and you have already invested the time to understand the issue, the fix & the implications of the fix. |
| 17:26 |
Krock |
appguru: gravity should be a member of LocalPalyer |
| 17:26 |
Krock |
merging the two former PRs I mentioned..... |
| 17:28 |
Desour |
small reminder: there's a meeting planned today at <https://dev.minetest.net/Meetings> |
| 17:28 |
Krock |
done. |
| 17:30 |
Krock |
meeting in 30 minutes |
| 17:40 |
appguru |
LocalPlayer or Player? Player holds speed, and gravity being downwards acceleration, I somehow think it belongs there. |
| 17:42 |
Krock |
if it's needed in Player, then yes. if it's only used in LocalPlayer, then I'd yet refrain from that |
| 17:42 |
Krock |
to keep it as close to the place where it's used |
| 17:55 |
appguru |
Alright Krock, fixed; gravity is a local player property now |
| 17:57 |
Krock |
appguru: duplicate m_downwards_acceleration in player.h |
| 17:58 |
appguru |
ah darn it glossed over that |
| 17:59 |
appguru |
thanks, fixed now |
| 18:00 |
Krock |
ping Zughy[m] rubenwardy v-rob --- meeting time. it's a rather short one this time around |
| 18:05 |
Krock |
I just saw that a 5.6.1 is long overdue |
| 18:05 |
Krock |
> #12697 - can this be fixed by Minetest/Irrlicht at all? |
| 18:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/12697 -- Can't look/play (Incorrect XScreen mouse position) |
| 18:05 |
Krock |
if not, it's pointless to keep in the milestone |
| 18:08 |
Krock |
nvm. we just need a volunteer who's affected by the bug so that it can be fixed reliably |
| 18:12 |
Krock |
> #7712 |
| 18:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/7712 -- Add an item pick up callback (2) by Desour |
| 18:12 |
Krock |
Desour: core.item_pickup relies on entity.itemstring, hence there's no further use-cases for this function other than __builtin:item unless that dependency is documented |
| 18:13 |
Desour |
__builtin:item is a engine-internal for dropped items |
| 18:13 |
Desour |
I still don't see how "picking up" other objects makes sense |
| 18:14 |
Krock |
me neither, hence I wonder why core.item_pickup is needed when it's already largely the same as on_punch |
| 18:15 |
Krock |
granted, there's automatic on_pickup callbacks run |
| 18:15 |
Desour |
core.item_pickup could be changed to do nothing if it's called with some other object... |
| 18:15 |
Desour |
oh, you mean it's useless because one can call on_punch instead |
| 18:16 |
Krock |
exactly |
| 18:17 |
Krock |
another thing that bothers me is that registered_on_item_pickups passes the object, unlike any other function. if it's only used for __builtin:item, then why not pass the itemstack as parameter and handle the return value to update the stack? |
| 18:17 |
Desour |
hm, would that just be obj:get_luaentity():on_punch(hitter, ...) ? I'm fine with removing that function then |
| 18:17 |
Krock |
or if it's supposed to be generic: pass an ObjectRef, but not LuaEntitySAO (which is inconsistent to the other API) |
| 18:18 |
Desour |
ok, will change that to objref |
| 18:19 |
Desour |
+ itemstack |
| 18:19 |
Krock |
also don't get me wrong. ItemDefinition:on_pickup seems promising, and I like this addition a lot |
| 18:19 |
Zughy[m] |
I'll do my best, but I have to constantly update the IRC log to actually see something |
| 18:19 |
Krock |
Zughy[m]: is the matrix bridge still broken? |
| 18:19 |
Zughy[m] |
yes |
| 18:20 |
Krock |
that's unfortunate. hopefully someone will have a look at that soon. it's somewhat not convenient like that |
| 18:21 |
Desour |
oh, Krock I forgot something. core.item_pickup is actually useful if you overwrite it |
| 18:21 |
Desour |
to do a global (=for all items) callback before the itemdef's callback is called |
| 18:21 |
Desour |
=> maximum versatility |
| 18:22 |
Krock |
that makes sense I guess |
| 18:22 |
Desour |
but that's also achievable then by overwriting on_punch |
| 18:22 |
Desour |
I think I had just misunderstood you then, sorry ^^ |
| 18:23 |
Krock |
no problem. I might've not expressed myself that well |
| 18:26 |
Krock |
I think you could also omit the "inventory" parameter if you work with ItemStack return values |
| 18:26 |
Krock |
i.e. let __builtin:item's on_punch handle the return value and add to the inventory accordingly |
| 18:27 |
Desour |
the inventory thing is actually some more benefit of the item_pickup. you don't need a fake player |
| 18:27 |
Krock |
that would also be consistent with other callbacks, such as on_rightclick and on_place |
| 18:27 |
Desour |
edit: oh nevermind, the hitter is in ... |
| 18:28 |
Krock |
on_pickup = function(itemstack, picker), and we're back to the common format |
| 18:29 |
Desour |
returning an item in the callback makes sense, I guess |
| 18:30 |
Desour |
is function(itemstack,picker,...) also ok? it's still shares the common format in its first part |
| 18:32 |
Desour |
imagine a stinging nettle that damages you if you pick it up from the wrong angle |
| 18:32 |
Desour |
or some sensible item that breaks if you attack it with a weapon |
| 18:34 |
Krock |
sure |
| 18:34 |
Desour |
*fragile, not sensible |
| 18:36 |
sfan5 |
@appguru can 12353 be renamed to be more descriptive |
| 18:36 |
sfan5 |
something like "Fix acceleration to use the correct formula" |
| 18:37 |
|
appguru joined #minetest-dev |
| 18:37 |
MTDiscord |
<luatic> sure |
| 18:38 |
Krock |
> #11885 |
| 18:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/11885 -- Add unittests for item movement code by savilli |
| 18:38 |
Krock |
could someone please have a look at this and review? |
| 18:39 |
Krock |
I'd like to bring in the callback execution order fix at least before xmas if possible |
| 18:39 |
sfan5 |
I believe I have a review request on that already |
| 18:39 |
Krock |
yes, but after three rebases and some fixes it would be great to have a look at it again |
| 18:40 |
Desour |
appguru: suggestion for title: "Use Heun's method for position calculation instead of explicit euler" |
| 18:40 |
appguru |
Desour: Any mention of Euler vs. Runge-Kutta/"Heun" is too technical IMO |
| 18:40 |
Krock |
"Use more accurate acceleration calculation" would do the job just fine. I don't think many people know what these terms mean |
| 18:42 |
Desour |
Or "Use 2nd order instead of 1st order approximation" |
| 18:42 |
appguru |
well, it's not just more accurate - the formula is theoretically 100% correct now, although practically float imprecisions will OFC still lead to a negligible error |
| 18:42 |
Krock |
there's nothing more on the meeting page. I assume it's the time for regular dev discussions now |
| 18:54 |
|
YuGiOhJCJ joined #minetest-dev |
| 19:07 |
sfan5 |
I hope we can get 5.6.1 done soon |
| 19:12 |
sfan5 |
I guess I could prepare a backports branch in the next few days |
| 19:12 |
MTDiscord |
<MisterE> Hey, something seems to have changed with 5.7 dev, where minetest.get_mod_storage now required the mod name to be passed to it. Is this intentional? It will break most mods out there. If it is intentional, shouldn't it accept no argument if called from within the mod for to which the storage belongs? |
| 19:13 |
MTDiscord |
<MisterE> minetest.get_mod_storage() <- as such, now crashes |
| 19:13 |
MTDiscord |
<MisterE> with "bad argument #1 to 'get_mod_storage' (string expected, got no value)" |
| 19:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/1 -- GlowStone code by anonymousAwesome |
| 19:13 |
MTDiscord |
<MisterE> stop it shadowbot :{ |
| 19:14 |
MTDiscord |
<MisterE> it doesnt crash when I pass the mod name |
| 19:15 |
sfan5 |
as always: open an issue |
| 19:17 |
Krock |
https://github.com/minetest/minetest/commit/d631f21024b |
| 19:17 |
Krock |
^ responsible change |
| 19:19 |
Krock |
interesting. the unit test for that is still pending because it's mixed into a different PR |
| 19:19 |
sfan5 |
well no, the change is not responsible |
| 19:19 |
sfan5 |
@MisterE is running a broken build |
| 19:19 |
sfan5 |
builtin is older than the binary |
| 19:19 |
MTDiscord |
<MisterE> oh thank you |
| 19:19 |
MTDiscord |
<MisterE> that was it |
| 19:27 |
Zughy[m] |
can we see some of these <del>closed</del> discussed? ? https://github.com/minetest/minetest/pulls?q=is%3Apr+is%3Aopen+label%3A%22Roadmap%3A+Needs+approval%22 |
| 19:35 |
Desour |
^ regarding the "closed": you do know that nobody is helped by just rejecting changes, and that minetest won't get more contributions if there's a super toxic, dismissive and pedantic atmosphere, right? |
| 19:35 |
|
proller joined #minetest-dev |
| 19:38 |
Zughy[m] |
what you call "toxic" I call it "respectful". Is anyone paid in here? No. Do we want to go back to the huge bottleneck with people complaining and nothing really happening? No. There is a roadmap, if people don't want to follow it, they assume the risk to have their PRs rejected. Also because they're explicitly warned when opening a PR |
| 19:40 |
Zughy[m] |
also because according to comments, something like #12517 is not going very far |
| 19:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/12517 -- Let cmake support automatic search of irrlichtmt installed in msys environment by Pevernow |
| 19:45 |
hmmmm |
I don't think that any PRs that genuinely add value should be 'closed', because the changes might not be 100% perfect, or they might not fit in with what minetest needs *right now*, but that doesn't mean it should go down into a memory hole |
| 19:46 |
hmmmm |
the reason why PR closings are so aggressive these days is a side effect of the sheer volume and complete disorder if they are left open |
| 19:47 |
hmmmm |
too bad there's no "maybe later" tag D: |
| 19:55 |
sfan5 |
I tend to agree but what practical value is there to keeping something open if there are no concrete plans to do anything to it? |
| 19:57 |
Desour |
I didn't want to say that one shouldn't close any PR. But the number of open PRs is definitely not the real bottleneck in development speed, it's rather the available coredev time. And as you said, nobody is paid here (well, at least as good as nobody), this includes contributors. Having high-quality PR lying around that does not "follow" the roadmap doesn't slow others down following the roadmap. And contributors kinda don't care about the roadmap, |
| 19:57 |
Desour |
they do stuff that *they* want to be changed, for themselves, because nobody else will. A "maybe later" tag like hmmmm suggested would be nice to have, but it's only applicable for large features. |
| 19:57 |
hmmmm |
sometimes you don't know the practical value of something until much later on D: |
| 19:59 |
hmmmm |
I guess this is where minetest 'hits the wall' or so to speak. the linux kernel gets around this by having corporate sponsorships and paid developers, because it has utility far beyond fun vidya gamez |
| 20:00 |
hmmmm |
too bad that one guy who wanted to sponsor minetest dev to turn it into a viable educational product isn't around anymore. if we could find somebody like that... |
| 20:00 |
hmmmm |
I want to spend time working on MT again so bad too, but I have to be honest with myself when there are too many other prior committments |
| 20:00 |
Desour |
Anyway, don't just reject something before enough people have looked at it. I.e. let enough core devs express their uninterested-ness before closing |
| 20:01 |
sfan5 |
Desour: inactive but open PRs are in the way everytime someone looks at the list and the canonical way to have things disappear from the list is closing them |
| 20:01 |
hmmmm |
ye I agree, one core dev is not going to understand how everything can fit into the roadmap |
| 20:02 |
|
YuGiOhJCJ joined #minetest-dev |
| 20:02 |
rubenwardy |
[21:00] <Desour> let enough core devs express their uninterested-ness before closing |
| 20:02 |
rubenwardy |
That's what we do in meetings |
| 20:02 |
rubenwardy |
Or should be doing |
| 20:02 |
Desour |
for inactive PRs we have the 30 days rule, which should work fine imo |
| 20:02 |
Krock |
even though you can wait 30 days, it might simply be forgotten |
| 20:03 |
Krock |
rather than neglected entirely |
| 20:03 |
sfan5 |
I used 'inactive' as a shorthand for 'PR that is not planned to be merged anytime soon' here |
| 20:04 |
Desour |
ah, well then 'inactive' could use the "maybe later" tag |
| 20:06 |
rubenwardy |
If a PR isn't on the roadmap, it's labelled. PRs with the label are discussed during meetings, and then either marked as supported or closed |
| 20:06 |
rubenwardy |
Or they can be marked as supported before then, to save time |
| 20:08 |
Zughy[m] |
since you're all here, do you have time to discuss them? |
| 20:09 |
Zughy[m] |
I'm just the secretary |
| 20:09 |
|
kilbith joined #minetest-dev |
| 20:10 |
Zughy[m] |
I'll just open it, let's see if someone has got time |
| 20:10 |
Zughy[m] |
#12757 Add dynamic media without loading from disk |
| 20:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/12757 -- Add dynamic media without loading from disk by GoodClover |
| 20:10 |
Desour |
rubenwardy: yes, sure. what I complained about was rather that one shouldn't go into such a discussion with the goal to close as much as possible, just to get them out of ones eyes, especially for new PRs, because that would be dismissive, imo |
| 20:11 |
sfan5 |
most of the PRs in the list I'd put down as maybe |
| 20:11 |
sfan5 |
(including this one e.g.) |
| 20:11 |
sfan5 |
all in all it's not that many and IMO if a dev has time right now it's better spent looking at any of the "One approval" PRs which there are more of |
| 20:15 |
sfan5 |
https://0x0.st/oOrA.png but don't want to discuss this now |
| 20:19 |
|
proller joined #minetest-dev |
| 20:48 |
MTDiscord |
<MisterE> so why does escaping not work anymore for textures? even the example given in the api docs: cobble.png^[lowpart:50:color.png\^[mask\:trans.png causes a crash with: "invalid escape sequence near 'cobble.png^[lowpart:50:color.png'" |
| 20:49 |
Desour |
have you tried escaping the \? "\^" isn't valid lua |
| 20:50 |
Desour |
("\\") |
| 20:52 |
MTDiscord |
<MisterE> what? |
| 20:52 |
MTDiscord |
<MisterE> this is in a string |
| 20:52 |
MTDiscord |
<MisterE> there is no ? in there |
| 20:52 |
Desour |
the `\` I mean |
| 20:53 |
Desour |
did you write "cobble.png^[lowpart:50:color.png\^[mask\:trans.png" ? |
| 20:53 |
Desour |
because that should be "cobble.png^[lowpart:50:color.png\\^[mask\\:trans.png" |
| 20:53 |
MTDiscord |
<MisterE> I wrote what I pasted above |
| 20:54 |
MTDiscord |
<MisterE> cobble.png^[lowpart:50:color.png^[mask:trans.png |
| 20:54 |
MTDiscord |
<MisterE> aaah |
| 20:54 |
MTDiscord |
<MisterE> it is being un escaped for me |
| 20:54 |
MTDiscord |
<MisterE> by discord |
| 20:54 |
MTDiscord |
<MisterE> cobble.png^[lowpart:50:color.png\^[mask\:trans.png |
| 20:54 |
MTDiscord |
<MisterE> does that show the escapes? |
| 20:55 |
MTDiscord |
<GoodClover> "cobble.png^[lowpart:50:color.png\\^[mask\\:trans.png", or use [[]] strings to only have to use one \ |
| 20:55 |
MTDiscord |
<MisterE> ok, why? |
| 20:56 |
Desour |
ahh, discord is doing weird, non-plain-text, things |
| 20:56 |
MTDiscord |
<MisterE> and it works, but why are the api docs wrong? |
| 20:56 |
MTDiscord |
<GoodClover> "\^" is a Lua escape, we want the backslash to stay for the texmod parser to see. So "\\^" |
| 20:56 |
MTDiscord |
<MisterE> grr |
| 20:56 |
MTDiscord |
<MisterE> some mention should be made about that in the api |
| 20:56 |
MTDiscord |
<GoodClover> Just use [[]], makes like easier. |
| 20:56 |
MTDiscord |
<MisterE> totally non-intuitive |
| 22:25 |
|
YuGiOhJCJ joined #minetest-dev |
| 22:35 |
|
panwolfram joined #minetest-dev |
| 23:27 |
Zughy[m] |
MisterE: it takes less time to fill in a PR to fix #12759 than opening a issue about it with a debatable name ? |
| 23:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/12759 -- DOCS: |
| 23:27 |
Zughy[m] |
*an issue |
| 23:34 |
MTDiscord |
<Jonathon> https://github.com/minetest/minetest/pull/12760 done |
| 23:45 |
MTDiscord |
<MisterE> well, thx, you're right. But I consider it a hassle to fork minetest, open a branch, run into some problem, figure it out, and make the PR. I didnt consider doing it on the web, that would have been super easy. |
