Time Nick Message 08:30 Zughy[m] erle: because I'm already busy with other projects in my free time, because I don't have the necessary knowledge, and because I'm here as a content creator 09:25 erle sfan5 distributions take bug reports usually through their infrastructure. on debian, it is reportbug. 16:15 ROllerozxa the Minetest Windows buildbot scripts break if you try to build from an existing Minetest directory that contains IrrlichtMt at lib/irrlichtmt... 16:54 rubenwardy those scripts are intended for CI use 17:36 sfan5 #11131 is now finished for real 17:36 ShadowBot https://github.com/minetest/minetest/issues/11131 -- [MANUAL MERGE] Async environment for mods to do concurrent tasks by sfan5 17:50 MTDiscord Guess I can multi-thread IKEA's mapgen now 17:52 MTDiscord I already break it up into 16x16 chunks, so pushing those onto async jobs doesn't sound too hard. The question is whether the overhead is worth it. 17:54 erle i doubt it 17:56 erle almost anything i have seen that blocked mapgen thread was either sloppy coding or kays attempt to sidestep mapgen griefing (which *almost* works but is so slow and fails in not-so-nice ways) 17:56 MTDiscord This is a Lua only mapgen, not a C++ one 17:57 MTDiscord So its running on the main Lua thread 17:59 MTDiscord If I get some time this week I might take an hour or so and mess around with that, I don't think it'd be difficult to push the chunks onto the async system 18:00 MTDiscord I may have to increase the generation chunk (the size of the area passed to on_generated, not my own 16x16 areas) to make it worthwhile, but we'll see 18:00 erle and i am talking about lua mapgen 18:02 erle Benrob0329 what actually do you think is slow in particular in lua-space? 18:03 erle i mean i can of course invent fancy scenarios, but i isn't IKEA pretty simple in terms of generating rooms? 18:03 MTDiscord In my case, not much. I'm actually pretty happy with the speed of IKEA's mapgen, but it's an interesting experiment 18:03 erle nevertheless, i'd be interested in your evaluation. as always, benchmark! 18:04 Krock sfan5: might it be faster to use PackedValue rather than core.serialize() ? 18:04 erle may i ask how you avoid mapgen griefing and stone clouds in IKEA? 18:04 MTDiscord sfan5: Is there an await equivalent or do I need to busywait? 18:04 Krock about variables that are pushed to the async env 18:05 MTDiscord erle: What do you mean? 18:05 MTDiscord IKEA is built on singlenode, so nothing generates that I don't say to 18:06 erle oh lol, right, sorry! 18:38 sfan5 Krock: perhaps but the one-time setup isn't performance critical 18:38 sfan5 @Benrob0329 neither, busywait doesn't work 18:38 Krock thanks. I did not realize it was one-time. 18:41 MTDiscord sfan5: couldn't I set a check variable in handle_async, and loop in the main thread to check that? 18:42 sfan5 nothing is shared between threads so no 18:42 MTDiscord Er, I suppose the callback is probably synchronous to avoid race conditions 18:42 MTDiscord Hm 18:43 sfan5 as for delaying until you have had the callback called (maybe you meant that): doesn't work, job results are only polled every globalstep 18:44 sfan5 but if you are using singlenode anyway then I'd say it does not matter whether you actually use on_generated or "manually" do the map generation at runtime 18:44 sfan5 you can set up your game for this 18:45 MTDiscord True 18:46 MTDiscord It just means having multiple Vmanip objects then 18:47 MTDiscord What I do now is pass the data table to each department's mapgen function, and then set_data once 18:48 MTDiscord I was hoping I could do something similar here, just waiting for each job to finish before writing to the map 18:50 sfan5 alternatively wait 3-6 more months until I have implemented having for on_generated run in one Lua environment per emerge thread 18:50 sfan5 s/having for/having/ 18:50 sfan5 (which is the proper way to do mapgen from Lua) 18:53 MTDiscord Thats probably the best way to go about it 18:55 erle sfan5 given that you are familiar with on_generated … is there any way to suppress it being run if the mapblock is already generated? if not, how do you think that *should* be accomplished? it annoys me to no end. 18:57 erle if you need a test case, i can make one. 19:11 sfan5 you ask that as if existence of this bug was common knowledge. I don't know, you should file a bug report 19:14 sfan5 rubenwardy, Krock, HuguesRoss48: meeting? 19:15 Krock uh-oh. okay? 19:16 sfan5 wasn't it supposed to be now? 19:16 Krock https://github.com/orgs/minetest/teams/engine I hoped for an entry here 19:17 Krock I did also have a meeting in my mind, but about last week. idk. it seems to be a failure 19:18 sfan5 https://dev.minetest.net/Meetings also has no info but ? 19:26 rubenwardy hi 19:28 MTDiscord Saw that message late, but now is fine for me 19:29 sfan5 I guess we can start then 19:30 sfan5 > Review roadmap rules > Remove 1 week limit, use meetings instead 19:30 rubenwardy that depends on having regular meetings, which I guess should be point 0 19:31 sfan5 the 1 week limit obviously doesn't work (and not only because we don't actually close PRs), but having regular meetings is a problem 19:31 sfan5 I don't have a good solution but we can consider extending the limit 19:32 rubenwardy if the limit is extended then they can also be dealt with during meetings 19:32 rubenwardy if they happen 19:32 sfan5 i dont think we'll manage a meeting every month 19:33 MTDiscord Yeah, I'd be in favor of something closer to a one-month limit, though if we actually meet regularly that could be a workable solution too. It comes down to what we can manage on that end, but it sounds like everyone agrees it should be extended to some degree 19:33 rubenwardy it just needs better organisation. I'm nearly always free on Sunday evening, I imagine that would probably be the best time 19:33 rubenwardy they don't need to be that long either 19:34 MTDiscord Is it Sunday evening for you now? If so, around now is workable for me 19:34 rubenwardy oh right, time zones exist 19:34 Krock more regular meetings would surely help to bring the issue and PR count down 19:34 rubenwardy yeah 19:35 rubenwardy we can fill the agenda with the oldest PRs 19:35 rubenwardy or some other priority 19:35 Krock wasn't it somewhere around 18:00 UTC+0 before? 19:35 rubenwardy I originally suggested 18:00 UTC, which was 2.5 hours ago 19:36 rubenwardy well, 19 but then 18 19:37 rubenwardy 1800 UTC is 1400 ET and 1100 PT 19:38 MTDiscord On my end that's still fine, probably can't go earlier due to lunch but my Sundays are almost always open 19:38 Krock about the 1 week limit: it would be possible to extend, but to close them, it's often more convenient to decide on that in meetings 19:41 sfan5 okay sounds like we have agreement for doing it in meetings and doing meetings more often 19:42 Krock shall I already post a notice about a meeting on, say, 24 April 19:00 UTC ? 19:42 sfan5 sure 19:42 rubenwardy makes sense 19:42 Krock alright 19:43 Zughy[m] my two cents as a contributor: deciding on meetings only would pass the message that I can push whatever I want and make you have fun during every meeting, which would make your life worse 19:43 sfan5 wat 19:43 sfan5 anyway next point: > #11567 19:43 ShadowBot https://github.com/minetest/minetest/issues/11567 -- Use an sqlite database for the media cache by Desour 19:43 sfan5 without benchmarks I suggest closure 19:44 rubenwardy I agree 19:44 MTDiscord No strong opinion, but looking at the number of changed lines it seems reasonable to close 19:44 sfan5 in general I'm not too happy with moving cache into an sqlite db but if it's faster then we can merge it 19:45 MTDiscord As an aside re: Zughy's point, I think that assumes the rules can't be ignored in the event that they need to. The policy is for normal cases, if there's obvious abuse I don't think it will stop us from doing something 19:45 rubenwardy Zughy[m]: the problem is that currently PRs and roadmaps aren't being considered especially well, the 1 week thing isn't followed 19:45 Krock it would make sense to track media access times there, but not to save blobs 19:45 rubenwardy Yeah, this only applies to roadmap closures, we can still close for other reasons 19:45 Krock I'd opt for a close too 19:46 Krock (i.e. to track cache hits and remove old/unused files) 19:46 rubenwardy roadmap closures are a case of "no support", but they can also be closed if they have _negative_ support 19:47 sfan5 next point: > #11843 19:47 ShadowBot https://github.com/minetest/minetest/issues/11843 -- Breaking world limits. Part 1 by proller 19:47 Krock this thing scares me 19:47 rubenwardy agreed 19:48 rubenwardy I don't think it's a good idea to do a hard network break again, and this is the sort of thing that will break a lot of things 19:48 sfan5 with compatibility concerns (just look at the bithacks being proposed for hash_node_position) this whole thing is too much of a headache, I think the better way forward may be to think about easy support for transferring players between servers to emulate dimensions 19:48 Krock part 3 aims o fix the compat 19:49 MTDiscord Personally, part of the reason I haven't touched or commented on any of the "breaking world limits" PRs so far is that I'm still not convinced there's a pressing need to break said limits. But as I'm trying not to involve myself too deeply in design/direction, I'm not casting a vote against it on those grounds. 19:49 sfan5 replacing v3whatever types with pos_t or bpos_t seems like wasted work to me but I'm neutral on it, the PR would have to be remade to do that properly anyway 19:50 sfan5 (all this assuming network compat is figured out, I am also against another hard break) 19:51 Krock also the object and node position chances could be split 19:51 sfan5 this sounds like two weak votes against, one against and one neutral 19:52 sfan5 so close it? 19:52 Krock instead of doing it all at once, only migrate node positions... which alone does cause headaches, as you said. 19:52 Krock in the current state, yes. close. 19:53 rubenwardy On the scale of things, I don't consider it a priority and it's a huge task 19:54 Krock as much I'd like to see the limits pushed to 32-bit (64-bit floating point) this PR alone needs intense testing, let alone the compatibility-follow-up. 19:54 rubenwardy Yeah. It's a nice headline feature, but the cost benefit doesn't add up for me 19:54 sfan5 closed 19:55 Krock > #11630 19:55 ShadowBot https://github.com/minetest/minetest/issues/11630 -- Add API function minetest.activate_objects_in_area by TurkeyMcMac 19:56 Krock shouldn't this be some sort of "activate_block" function instead? 19:56 sfan5 I still don't really get what this is used for 19:57 Krock basically to locate entities in unloaded map parts 19:57 MTDiscord Krock, I believe that's what the predecessor #11609 was 19:57 ShadowBot https://github.com/minetest/minetest/issues/11609 -- Add an API function for synchronously activating areas by TurkeyMcMac 19:57 sfan5 #11609 had something called `activate_area` 19:57 ShadowBot https://github.com/minetest/minetest/issues/11609 -- Add an API function for synchronously activating areas by TurkeyMcMac 19:57 sfan5 ...yea 19:57 MTDiscord Would have to check why it was closed 19:58 sfan5 usefulness aside I question the need for this API to be synchronous 19:58 rubenwardy #11630 was something requested by a user, the author also requested it be reviewed 19:59 ShadowBot https://github.com/minetest/minetest/issues/11630 -- Add API function minetest.activate_objects_in_area by TurkeyMcMac 19:59 sfan5 you don't want the server to lock up during this 19:59 MTDiscord Looks like the original was closed because they were worried about the possibility of the function making callbacks that could call the same thing. I'm not sure we couldn't avoid that in the same way they did in this new PR though. Could be worth asking for clarification? 20:00 sfan5 yeah 20:01 MTDiscord I could see some use-cases for being able to find and access objects in an area reliably regardless of its load status, though it sounds like the need for it to be synchronous was due to a specific use-case they had in mind 20:01 MTDiscord Something triggering in on_dig? 20:01 MTDiscord *can_dig 20:01 erle i suggest when benchmarking the sqlite db media cache thing (#11567) one should double-check that any claimed performance gains are not solely because it does not hash everything every time. if you know how to do that well, please tell me, i only used cachegriend and that told me that the vast majority of media loading time is hashing everything again and again. 20:01 ShadowBot https://github.com/minetest/minetest/issues/11567 -- Use an sqlite database for the media cache by Desour 20:01 sfan5 that would be unfortunate but I'm very wary of adding synchronous APIs 20:02 Krock alright. I'll write up a post, unless you'd like to do that @Hugues Ross 20:02 MTDiscord If you could that'd be great 20:03 sfan5 you can also mention that the author needs to open a new PR, the old one isn't reopenable 20:03 MTDiscord One thought--I wonder if there's a way we could allow modders to explicitly call things synchronously. Would be a risky thing to use, but for those edge-cases where it needs to happen having some way to block until a callback could be useful 20:03 MTDiscord Probably not a short-term thing, just an idle thought 20:04 erle HuguesRoss48 what APIs come to mind where calling it synchronously would be an advantage? 20:04 rubenwardy I think it's more about the caller than the API 20:05 rubenwardy there are a lot of callbacks which need a response, and can't be responded to asynchronously 20:05 rubenwardy eg: prejoin 20:05 MTDiscord Yeah 20:05 MTDiscord Having an await equivalent would be nice 20:05 rubenwardy if we were doing this from scratch, making more callbacks async could be an idea 20:05 rubenwardy async being async/await 20:06 rubenwardy that's complicated though 20:06 MTDiscord It's something I do... uncommonly in the software I write for work, not usually in games but I can see the value for handling callbacks 20:06 rubenwardy well, with a Promise object it's simpler 20:06 rubenwardy guess which language I've been using a lot recently 20:06 MTDiscord JS? 20:06 sfan5 Lua has coroutines but in general async only makes things more complicated 20:07 erle rubenwardy, do you mean this? https://github.com/ms-jpq/lua-async-await/blob/neo/lua/async.lua 20:07 erle with async/await 20:07 rubenwardy JavaScript has async/await which makes writing coroutines nice 20:07 rubenwardy they work by using Promise objects, which represent a pending operation 20:07 erle which is why i linked the code, it is very short, but i do not know if this is what you want 20:07 rubenwardy so it's not threaded async, which makes things nicer 20:08 rubenwardy *easier 20:08 erle i do not understand if it is applicable here tbh 20:08 MTDiscord Yeah, coroutines aren't helpful here 20:08 sfan5 you can built await using coroutines, it just won't be built into the language 20:08 sfan5 build* 20:08 sfan5 next point: > #12131 20:08 ShadowBot https://github.com/minetest/minetest/issues/12131 -- Add `minetest.settings` to CSM API and allow CSMs to provide `settingtypes.txt` by AFCMS 20:09 sfan5 opinion: CSM will have be to be pretty much rewritten for SSCSM anyway so if it makes people happy it doesn't matter and we can add this 20:09 erle oh this actually happened to a friend of mine, who needed it! 20:10 rubenwardy I suppose 20:10 rubenwardy It is pretty simple 20:10 rubenwardy Really we need some consensus on the future of CSM and SSCSM. It's telling that no one raised it as a point for the roadmap... 20:10 Krock simple and does not hurt from what I can see 20:10 erle my friend li0n wanted it for the rumble CSM to adjust the rumble strength and length 20:10 rubenwardy even with a SSCSM environment, I'd want a settings API but just limited to a prefix like `client.` 20:11 Krock however, the server Settings instance might override CSM changes in singleplayer 20:11 erle Krock, can you elaborate what you mean with that? 20:11 sfan5 well having the ability to change client settings at runtime might open a way to mess with certain things 20:11 sfan5 but anyway yeah it can go in 20:11 Krock erle: CSM writes "hello = true" to the settings file. when singleplayer exists, the server will write to the same file and truncate that 20:11 rubenwardy s/client./csm.` perhaps 20:12 rubenwardy ah 20:12 sfan5 Krock: but CSM doesn't write to a file, it uses the same g_settings object 20:12 MTDiscord Sounds to me like it'll need testing but should be allowed to continue the PR process 20:12 Krock oh right! indeed it does use the same instance 20:13 Krock no problem then :) 20:13 erle it also means that you lose all settings if you abnormally terminate i think? 20:13 sfan5 you lose all changes, not all settings 20:13 rubenwardy there's two more roadmap approval needed: https://github.com/minetest/minetest/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3A%22Roadmap%3A+Needs+approval%22 20:13 erle oh right 20:14 sfan5 #12084 -> draft, wip and wrong approach; should be closed 20:14 ShadowBot https://github.com/minetest/minetest/issues/12084 -- feat: add text tile modifier by jingkaimori 20:14 rubenwardy agreed 20:14 Krock ^ #11939 will need some testing but is an approval from my side 20:14 ShadowBot https://github.com/minetest/minetest/issues/11939 -- Restore and enhance bouncy behavior by pecksin 20:14 Krock *concept approval 20:14 sfan5 #11939 -> yes in principle but needs a good look on the quality of changes (PR description mentions 'hacky'...) 20:14 ShadowBot https://github.com/minetest/minetest/issues/11939 -- Restore and enhance bouncy behavior by pecksin 20:15 rubenwardy well, roadmap is just concept approval. So [Supported by core dev] 20:15 sfan5 next: > game#2942 20:15 ShadowBot https://github.com/minetest/minetest_game/issues/2942 -- Don't block fluid (water, lava) flow by flowers, mushrooms, grass and saplings by bartoszkosiorek 20:16 sfan5 apparently water already has the power to drop some nodes so adding more would just increase consistency and not be a "feature" (new features are not allowed in MTG) 20:16 sfan5 opinions? 20:17 erle you should be very careful about this, as it has the potential to ruin builds 20:17 sfan5 paramat used to be very careful about this but I'm not convinced it should be given too much thought 20:17 erle i have definitely seen very unusual ”water containers” made out of random nodes 20:18 MTDiscord I'm a little split, I think consistency is very important in games but whether or not it counts as a feature is a tough question 20:18 MTDiscord personally, I'd say if it affects crops it should affect other plants. I don't remember if it does, haven't touched MTG in ages 20:18 erle it a behaviour change. 20:18 erle might be a good idea to ask admins of big servers about it 20:19 Krock plants re-grow so I think this is okay, although there might be quite many dropped items when a water node is placed on top of a hill 20:19 rubenwardy Ignoring MTG feature freeze, this change does make sense to me from a mechanic point of view 20:19 MTDiscord Are big servers following the main MTG releases? I'd imagine there's a fair bit of customization, but I don't know how much of it is in external mods vs the core 20:20 MTDiscord yes 20:20 erle it makes total sense from a mechanics POV. i just think the implementation needss work if it is decided that it destroys too much existing stuff. 20:20 erle (to not affect existing builds) 20:21 MTDiscord I'd say it could be worth warning about in advance. But I do think it would be good to have either way 20:21 erle how about making it a toggle-able option? 20:21 MTDiscord no 20:21 rubenwardy I'd rather not change anything than add another setting 20:21 MTDiscord Better to let people mod it out as their opt-out 20:21 MTDiscord Which they can if they're told in advance that it'll happen 20:22 erle my experience of about a year of minetest mod development recently is: no one ever reads any warnings or documentations unless they are flung in their face. ;) 20:22 erle (including me) 20:23 MTDiscord Aye, and in that event an option won't save them either 20:23 MTDiscord So it's a moot point 20:23 erle if it's off by default it might, but i see 20:23 MTDiscord If we have it off by default, it won't exist for anyone 20:23 MTDiscord So no point merging at that point 20:23 erle how about arguing that this change should be a mod 20:23 rubenwardy if we're spending time talking about it, then arguably it's too close to a feature :) 20:23 MTDiscord Could be! 20:23 erle rubenwardy, smart categorization hehe 20:24 erle i mean it is functional. stuff like caching security etc. is non-functional. 20:24 erle maybe functional = feature? 20:24 rubenwardy it's not just feature freeze, it's gameplay freeze 20:24 MTDiscord Yeah, sounds like it's worth closing then and suggesting they make a mod at the same time? 20:24 sfan5 or fork MTG ;) 20:25 erle instead of summer of code minetest_game has winter of code, where every feature is frozen 20:25 rubenwardy It's a shame as I think it makes sense as a mechanic 20:25 sfan5 continuing mtg is fine, it just needs someone who has a direction in mind 20:25 sfan5 (not us) 20:25 erle everyone i saw continuing mtg made a mod soup mess or a minecraft clone so far :D 20:26 erle exhibit A: mesecraft (which is cute btw) 20:26 MTDiscord I briefly considered it, but quickly realized it'd be easier to build from scratch than use MTG as a base 20:26 Krock https://github.com/minetest/minetest_game/pull/2468 this was broadly accepted 20:26 MTDiscord I suspect that's not an uncommon story 20:27 rubenwardy #2468 is a really nice mechanic 20:27 ShadowBot https://github.com/minetest/minetest/issues/2468 -- Critical error: attempt to concatenate field '?' (a table value) 20:27 rubenwardy mtg#2468 is a really nice mechanic 20:27 rubenwardy game#2468 is a really nice mechanic 20:27 ShadowBot https://github.com/minetest/minetest_game/issues/2468 -- Allow flooding of farming crops by rubenwardy 20:27 rubenwardy because there's only one game 20:27 MTDiscord At that time, flooding of other plants probably should've been implemented as well 20:27 MTDiscord Easy to say in retrospect tho! 20:27 rubenwardy was never merged 20:28 MTDiscord Oh, missed that 20:30 sfan5 oh great moving forwards in the browser deleted my changes 20:30 sfan5 I have three more PRs I want to look at but you'll have to give me a minute 20:30 rubenwardy changes to wiki? 20:30 sfan5 yes 20:30 rubenwardy sorry, I edited to add some notes 20:31 rubenwardy a live document would probably be a nicer way to do this 20:31 sfan5 the problem isn't that mediawiki can't deal with conflicts, it showed me the changes you did but I clicked the wrong thing and then going back to my edited changes become impossible 20:32 sfan5 next: #11016 20:32 ShadowBot https://github.com/minetest/minetest/issues/11016 -- Dual Wielding by EliasFleckenstein03 20:32 sfan5 do we want this or not 20:32 Krock yes. opens up more gameplay eyecandy 20:33 erle the general play pattern this would support is „tool in one hand, node in another hand” 20:33 rubenwardy yeah I like that 20:33 rubenwardy I looked into that, and it was simpler than expected 20:33 erle this is not just eyecandy 20:33 rubenwardy It doesn't seem to change the event handling at all, which I suspect will be the harder part 20:33 sfan5 well the PR apparently isn't fully finished 20:33 Pexin is it in a form that lets games define an arbitrary number of "hands"? 20:33 sfan5 but the argument brought up was that instead of hardcoding a second hand we could add an API to add as many wield slots as games want 20:33 MTDiscord I was thinking about that... 20:34 erle Krock eyecandy can be faked. shields in mcl2 for example, are fakery, because you can't interact with anything while the shield is in front of you. 20:34 MTDiscord Does it make sense with MT's very limited controls to have 3 slots, ever? 20:34 sfan5 as lhofhansl pointed out this is kind of stupid when humans clearly have two hands and not an arbitrary amount 20:34 rubenwardy arguably, it might not be finished as they may not be sure of dev support 20:34 erle the general reaction of everyone i have showed this PR to was “arbitrary hands are stupid, humans have two hands” 20:35 Krock if I have 10 fingers I want to have 10 wields 20:35 Krock (not serious though) 20:35 proller s32 pos and network compatibility was partially solved here - https://github.com/minetest/minetest/pull/12142 20:35 rubenwardy yeah, arbitrary hands aren't necessary 20:35 MTDiscord I first felt that arbitrary wield slots was a good concept, could allow for characters with more hands or utility slots... but the ability to actually use those slots will be generally limited to 2 by our inputs 20:35 Pexin doctor octopus wearable harness. adds more hands? 20:35 sfan5 well perhaps the "hands" concept is to narrow 20:36 sfan5 though you wouldn't solve armor via wield slots 20:36 erle rubenwardy fleckenstein seemed generally disillusioned with minetest stalling on stuff like this, so giving a clear go message might change it 20:36 sfan5 erle: you said they quit minetest, does not compute 20:36 sfan5 anyway it looks like the conclusion is +1 20:36 rubenwardy there are three parts to this: 1. rendering a wield item 2. adding a new wield slot / hand 3. event handling for left-dig 20:36 MTDiscord Pexin: See, that's the kind of concept I can get behind but with today's controls it's not actually possible to use those extra slots without more effort than changing slots 20:36 rubenwardy the PR appears to do the first two 20:37 rubenwardy I'm interested on the approach for the last one. Will it support eg: placing from the left hand? How does that even work with existing callbacks 20:37 erle sfan5 i'm pretty sure there are a bunch of people who will bother fleck to at least finish this, from the mcl* crowd 20:37 rubenwardy "it support" meaning the Lua API in the future 20:37 Krock proller: this is great in theory, but I doubt anyone would want to test this PR and its dependencies for proper functionality and implementation because A) most source files are touched and B) there's so many cases to test 20:38 Krock even though it is a topic that's brought up again, the priority seems to be rather low 20:39 erle rubenwardy i think the second hand (armor slot thing) would use an item if there are no usable items in the main hand or the item on the main hand can not be used directly (i.e. hoe with no grass nearby) 20:40 erle rubenwardy given that, what lua changes would be needed? 20:40 sfan5 now that sounds like something you don't want to hardcode 20:40 rubenwardy yeah 20:40 sfan5 erle: zero or all of them depending on if you want to hardcode it 20:40 sfan5 this would be an usecase for CSM 20:40 sfan5 which as you know, we don't have 20:40 rubenwardy I can see games wanting to allow left click for left hand, right click for right hand - and then length of click to control punch/place 20:40 erle right 20:41 sfan5 adding a few options for games to choose from is probably good enough 20:41 rubenwardy although honestly games could use better input APIs 20:41 rubenwardy this doesn't need to all be in one PR either, I'm fine with the first PR just being cosmetic 20:41 rubenwardy that's well suited for shields 20:41 sfan5 (also note that the client does not have the information that hoes only work on grass) 20:42 sfan5 (assuming you're not literally wanting to dig the node, but use a custom on_use callback) 20:42 sfan5 next: #11933 20:42 ShadowBot https://github.com/minetest/minetest/issues/11933 -- A light_source should not override sunlight. by lhofhansl 20:42 erle oh right, hmm 20:42 sfan5 this seems to be kind of and edge case and unlikely to break much(?) so maybe we should just pull it in 20:43 erle games might want to do stuff with the offhand like “it holds an item that modifies the thing in the primary hand”, like ammunation for a weapon that you need to hold in the hand or so 20:43 sfan5 s/and /an / 20:44 erle about the light_source thing, i have found no cases where this change seemed more than cosmetic 20:44 erle it could help to avoid bugs where sunlight is erroneously mis-detected 20:45 MTDiscord That sounds reasonably safe then 20:45 sfan5 erle: light itself is purely cosmetic so uh? 20:45 erle however, i think a test structure could help here. surely it can be quickly built. 20:45 sfan5 or what are you trying to say 20:45 Pexin sfan5: crops 20:45 Krock isn't this PR only for mapgen finish? what about nodes that are placed afterwards? 20:45 sfan5 good point 20:46 Pexin but if someone is using light source for crops, they arent depending on sunlight anyway 20:46 erle sfan5 no, light is actually gameplay relevant. in mcl* games for example, light controls mob spawning. among mods, i think mesecons has a sunlight detector. also some crops only grow in light or darkness (mushrooms). 20:47 sfan5 I know that but didn't get that you meant that 20:48 sfan5 okay next: #11073 20:48 ShadowBot https://github.com/minetest/minetest/issues/11073 -- Add rotation support for wallmounted nodes in 'ceiling' or 'floor' mode by Wuzzy2 20:48 sfan5 q: concept approval or not? 20:48 erle my “i have found nothing where this seemed more than cosmetic” should probably have been “if i would have found anything that broke because of this i would havea yelled about it” 20:48 rubenwardy I'm neutral on that 20:49 erle i can confirm that signs and buttons can look weird because of this thing 20:50 erle and it would be a good change 20:50 sfan5 I guess it's okay then 20:50 Krock I wonder why this needs 300 new lines but generally I support this 20:50 erle in fact, the wuzzy example is buttons: “In fact, I tried exactly that a long time ago to do this in MineClone 2 with the buttons, and in theory it would have been possible” 20:52 erle sfan5 the code looks straightforward to me 20:52 rubenwardy yeah it looks good. My neutral is more that I'm not planning to review it, rather than not seeing its worth 20:52 sfan5 I have not reviewed the code 20:52 erle oh okay 20:53 sfan5 I closed the mtg PR we talked about 20:53 erle i have only skimmed it of course, but found nothing i'd leave out right away (so far) 20:54 sfan5 okay so we're almost done 20:55 sfan5 I don't think we need to individually discuss PRs with one approval, just take this is a mental reminder that the ones on this list need attention -> https://github.com/minetest/minetest/pulls?q=is%3Aopen+is%3Apr+label%3A%22One+approval%22 20:57 sfan5 rubenwardy, Krock, HuguesRoss48: anything else you want to discuss? 20:58 rubenwardy nothing specific. If we have spare time in meetings, we could go older PRs (for concept review). But it's been 45 minutes so I'm fine to leave it there 20:58 v-rob[m] Ah shoot, totally forgot this was going on 20:58 rubenwardy so did we 20:58 MTDiscord Nothing to discuss from me. Will note that #11854 has a few issues to consider before anoyone gives a second review 20:58 ShadowBot https://github.com/minetest/minetest/issues/11854 -- Shader improvements: Saturation Optimization by Pevernow 20:58 Krock it's fine for now, at least from my side. 20:58 sfan5 rubenwardy: your clock is broken, it's been 1h15m 20:58 MTDiscord But I don't think it needs discussion 21:00 rubenwardy my thoughts on #11854 is that is should be part of a post processor stage, along with tone mapping 21:00 ShadowBot https://github.com/minetest/minetest/issues/11854 -- Shader improvements: Saturation Optimization by Pevernow 21:00 rubenwardy but I've said that in the PR 21:00 rubenwardy oh oops, misread the start time 21:00 sfan5 yeah that PR has some fundamental issues and can't go in like this 21:00 erle wait is the PR hilariously inefficient? 21:00 MTDiscord yeah, the issues are already mentioned in there. Sounds like it might get picked up elsewhere though, so we'll see 21:01 rubenwardy close then? 21:01 erle bc i suspect it is 21:01 sfan5 erle: adding one calculation to the shader cannot possible by "inefficient" 21:01 MTDiscord I don't recall checking the efficiency, because there's also the simple issue I demonstrated here: https://user-images.githubusercontent.com/2219707/154269257-32c99d97-ea82-4996-8187-3a54c1c0d0a3.png 21:01 rubenwardy yeah, very inefficient 21:01 rubenwardy well less efficient than doing it in post processing 21:02 sfan5 well not really 21:02 sfan5 you have to add this calculation either way, only the location differs 21:02 sfan5 am I missing something? 21:02 MTDiscord Probably that in post-processing, it'll hit fewer fragments total? 21:02 MTDiscord Since there's no overdraw to worry about 21:02 erle https://github.com/minetest/minetest/pull/11854#issuecomment-1041858919 21:03 erle > slowing down the rendering of everything as it will have to change the saturation of every fragment, including occluded fragments. 21:03 MTDiscord Yeah that's overdraw 21:03 rubenwardy sfan5: it runs on all geometry, even if discarded by depth buffer 21:03 rubenwardy yeah that 21:03 MTDiscord For a single math operation the cost is probably small. But it is a cost 21:03 rubenwardy yeah 21:03 rubenwardy it's also inconsistent to have to reimplement this for everything in the world 21:03 MTDiscord yeah 21:04 MTDiscord Post-processing would reduce the code duplication needed 21:04 v-rob[m] Any cost, no matter how small, will increase as people decide to add more features to it. 21:04 erle also easier to turn off in post-processing if it's only implemented at one point? 21:04 sfan5 rubenwardy: ah, that makes sense 21:15 Pexin not sure if this is a good time, but for the numeric tweaks in #11939 I subjectively compared number of jumps to reach various heights of pre-5.3 vs post-patch over a set of like 5 attempts each. 21:15 ShadowBot https://github.com/minetest/minetest/issues/11939 -- Restore and enhance bouncy behavior by pecksin 21:15 Pexin I am pretty confident in the numbers/formula, but not totally sure what would happen if global gravity is adjusted. 21:15 Pexin the "hacky" part is a specific check for the moment of contact with a bouncy floor ONLY, due to how collision currently works. 21:15 sfan5 merging #12179, #12173 in 5m 21:15 ShadowBot https://github.com/minetest/minetest/issues/12179 -- Remove unneeded setter return values by appgurueu 21:15 ShadowBot https://github.com/minetest/minetest/issues/12173 -- Fix item entity Z-fighting by appgurueu 21:17 erle the z fighting fix is lazy and very useful :3 21:17 erle it happened a lot 21:18 erle does anyone feel motivated to load devtest with this PR and verify that PNG texture rendering is broken? https://github.com/minetest/minetest/pull/12089 21:18 erle broken as in, gamma is not applied correctly 21:19 erle i promise to come up with another set of texture test nodes once this is merged 21:20 sfan5 that is an argument against merging it 21:20 erle well, i only make test nodes for stuff i encounter myself anyway 21:22 erle but given that everyone of us probably runs into at least a dozen bugs in software that we use daily, it might be a very low bar 22:12 MTDiscord late but re: dual wielding: The issue is not arbitrary amounts of wieldhands, the issue is generic HUD meshes with animations 22:14 MTDiscord This is not to say we shouldnt go ahead with adding an offhand 22:14 MTDiscord But ideally the concept of wieldhands themselves would be abstracted away into a generic hud element 22:15 MTDiscord Since there are many uses for HUD meshes, and not every game wants standard hands 22:15 MTDiscord It would also likely open up opportunities for custom wield animations 22:16 MTDiscord But I digress; Implementing an offhand at the very least is probably a decent step towards understanding how to implement a generic mesh hud element 22:33 MTDiscord I would never implement dual-wielding. My screen has 4 corners. If I'm gonna do any multi-wielding, I'd go for quad-wielding. 22:43 Pexin quad wielding and zero-g EVA tasks 23:48 erle Pexin and advanced trains should get multi-track drifting 23:48 erle deja-vu!