Time Nick Message 04:48 MTDiscord its still not relaying messages 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 11:12 MTDiscord Once Bountysource is fixed, £5 bounty on #11640. 11:12 ShadowBot https://github.com/minetest/minetest/issues/11640 -- Manual media management 12:17 MTDiscord passive aggressive reminder that I would like a wiki account: https://forum.minetest.net/viewtopic.php?p=412951#p412951 12:25 Krock Calinou: ^ 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 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 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 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 yes. It would probably use the mod channels api to send musical scripts to the client 14:11 MTDiscord alda would be ideal for that, since there are no constructs that can do anything other than play music in alda 14:12 MTDiscord sfan5 14:41 Desour alda requires java (according to ), 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! 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 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: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 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 MTDiscord 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 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 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 minetest.get_mod_storage() <- as such, now crashes 19:13 MTDiscord 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 stop it shadowbot :{ 19:14 MTDiscord 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 oh thank you 19:19 MTDiscord that was it 19:27 Zughy[m] can we see some of these closed 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: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 rubenwardy [21:00] 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: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:48 MTDiscord 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 what? 20:52 MTDiscord this is in a string 20:52 MTDiscord 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 I wrote what I pasted above 20:54 MTDiscord cobble.png^[lowpart:50:color.png^[mask:trans.png 20:54 MTDiscord aaah 20:54 MTDiscord it is being un escaped for me 20:54 MTDiscord by discord 20:54 MTDiscord cobble.png^[lowpart:50:color.png\^[mask\:trans.png 20:54 MTDiscord does that show the escapes? 20:55 MTDiscord "cobble.png^[lowpart:50:color.png\\^[mask\\:trans.png", or use [[]] strings to only have to use one \ 20:55 MTDiscord ok, why? 20:56 Desour ahh, discord is doing weird, non-plain-text, things 20:56 MTDiscord and it works, but why are the api docs wrong? 20:56 MTDiscord "\^" is a Lua escape, we want the backslash to stay for the texmod parser to see. So "\\^" 20:56 MTDiscord grr 20:56 MTDiscord some mention should be made about that in the api 20:56 MTDiscord Just use [[]], makes like easier. 20:56 MTDiscord totally non-intuitive 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 https://github.com/minetest/minetest/pull/12760 done 23:45 MTDiscord 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.