Minetest logo

IRC log for #minetest-dev, 2022-04-10

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

All times shown according to UTC.

Time Nick Message
03:39 YuGiOhJCJ joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
05:10 MaxStirner[m] joined #minetest-dev
05:37 calcul0n joined #minetest-dev
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:15 Fixer joined #minetest-dev
09:25 erle sfan5 distributions take bug reports usually through their infrastructure. on debian, it is reportbug.
09:37 Fixer joined #minetest-dev
10:16 HuguesRoss48 joined #minetest-dev
11:56 Fixer_ joined #minetest-dev
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 <Benrob0329> Guess I can multi-thread IKEA's mapgen now
17:52 MTDiscord <Benrob0329> 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 <Benrob0329> This is a Lua only mapgen, not a C++ one
17:57 MTDiscord <Benrob0329> So its running on the main Lua thread
17:59 MTDiscord <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> erle: What do you mean?
18:05 MTDiscord <Benrob0329> IKEA is built on singlenode, so nothing generates that I don't say to
18:06 erle oh lol, right, sorry!
18:23 mrkubax10 joined #minetest-dev
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 <Benrob0329> 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 <Benrob0329> Er, I suppose the callback is probably synchronous to avoid race conditions
18:42 MTDiscord <Benrob0329> 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 <Benrob0329> True
18:46 MTDiscord <Benrob0329> It just means having multiple Vmanip objects then
18:47 MTDiscord <Benrob0329> What I do now is pass the data table to each department's mapgen function, and then set_data once
18:48 MTDiscord <Benrob0329> 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 <Benrob0329> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> Would have to check why it was closed
19:57 mrkubax10 left #minetest-dev
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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> Something triggering in on_dig?
20:01 MTDiscord <Hugues Ross> *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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> Yeah
20:05 MTDiscord <Benrob0329> 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 <Hugues Ross> 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 <Benrob0329> 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 <Benrob0329> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Jonathon> yes
20:20 Desour joined #minetest-dev
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 <Hugues Ross> 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 <Hugues Ross> no
20:21 rubenwardy I'd rather not change anything than add another setting
20:21 MTDiscord <Hugues Ross> Better to let people mod it out as their opt-out
20:21 MTDiscord <Hugues Ross> 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 <Hugues Ross> Aye, and in that event an option won't save them either
20:23 MTDiscord <Hugues Ross> So it's a moot point
20:23 erle if it's off by default it might, but i see
20:23 MTDiscord <Hugues Ross> If we have it off by default, it won't exist for anyone
20:23 MTDiscord <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> At that time, flooding of other plants probably should've been implemented as well
20:27 MTDiscord <Hugues Ross> Easy to say in retrospect tho!
20:27 rubenwardy was never merged
20:28 MTDiscord <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> Probably that in post-processing, it'll hit fewer fragments total?
21:02 MTDiscord <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> 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 <Hugues Ross> yeah
21:04 MTDiscord <Hugues Ross> 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:09 proller joined #minetest-dev
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
21:28 Taoki joined #minetest-dev
21:35 proller joined #minetest-dev
22:12 MTDiscord <GreenXenith> late but re: dual wielding: The issue is not arbitrary amounts of wieldhands, the issue is generic HUD meshes with animations
22:14 MTDiscord <GreenXenith> This is not to say we shouldnt go ahead with adding an offhand
22:14 MTDiscord <GreenXenith> But ideally the concept of wieldhands themselves would be abstracted away into a generic hud element
22:15 MTDiscord <GreenXenith> Since there are many uses for HUD meshes, and not every game wants standard hands
22:15 MTDiscord <GreenXenith> It would also likely open up opportunities for custom wield animations
22:16 MTDiscord <GreenXenith> 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:32 panwolfram joined #minetest-dev
22:33 MTDiscord <Warr1024> 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
22:58 Alias joined #minetest-dev
23:21 AliasAlreadyTake joined #minetest-dev
23:48 erle Pexin and advanced trains should get multi-track drifting
23:48 erle deja-vu!

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