| 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! |
