| Time |
Nick |
Message |
| 01:30 |
|
Baytuch joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:55 |
|
calcul0n joined #minetest-dev |
| 09:22 |
|
Warr1024 joined #minetest-dev |
| 10:20 |
|
Baytuch joined #minetest-dev |
| 10:48 |
|
YuGiOhJCJ joined #minetest-dev |
| 12:25 |
|
YuGiOhJCJ joined #minetest-dev |
| 12:29 |
|
YuGiOhJCJ joined #minetest-dev |
| 12:29 |
|
appguru joined #minetest-dev |
| 12:31 |
|
kilbith joined #minetest-dev |
| 12:49 |
Zughy[m] |
kilbith: why was this closed? #2816 |
| 12:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/2816 -- Biomes transitions |
| 12:52 |
kilbith |
idk, rage quit probably |
| 12:55 |
|
YuGiOhJCJ joined #minetest-dev |
| 13:01 |
Zughy[m] |
Meeting reminder, today at 18:00 UTC |
| 13:30 |
sfan5 |
can we quickly get an approval for #12391? would simplify some cleanup I'm doing |
| 13:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/12391 -- Make OpenGLES 2 the default driver on Android by rollerozxa |
| 13:35 |
sfan5 |
merging #13271 soon |
| 13:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/13271 -- Tile: Fix segfault caused by invalid PNG data by SmallJoker |
| 13:35 |
rubenwardy |
Gles2 code looks good to me, have you tested? |
| 13:36 |
Krock |
giving it a quick test on android 5 |
| 13:37 |
Krock |
correction: android 6 |
| 13:38 |
Krock |
blue screen, nothing happens |
| 13:39 |
Krock |
perhaps it really needs the manifest line? checking with that specific PR... |
| 13:40 |
sfan5 |
ogles2 is already the default since the "drop irrcompileconfig" PR and I'm pretty sure I tested that during #13245 |
| 13:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/13245 -- [no squash] Fix task ordering and more in Gradle Android build by sfan5 |
| 13:40 |
sfan5 |
make sure the assets got extracted correctly and you aren't missing the shader files from irrlicht |
| 13:41 |
rubenwardy |
Yeah you might need to delete storage as Minetest only extracts when version code changes |
| 13:45 |
Krock |
after installing the apk from the PR the issue magically solved itself :) |
| 13:47 |
Krock |
all exposed shader checkboxes work too |
| 13:50 |
sfan5 |
>(hacky-signed apk) |
| 13:50 |
sfan5 |
heh |
| 13:50 |
sfan5 |
you mean you downloaded the one from gh actions? |
| 13:53 |
|
kilbith_ joined #minetest-dev |
| 13:56 |
Krock |
sfan5: exactly. then signed with the "apk-signer" app |
| 13:56 |
sfan5 |
yeah we should probably document that one day :D |
| 13:57 |
Krock |
definitely. it eases the development process a lot. I had no idea this was possible at all |
| 14:01 |
MTDiscord |
<luatic> app? I've been signing from the command line |
| 14:02 |
Krock |
I suppose that's a saner way if you have at least a semi-usable keyboard |
| 14:03 |
sfan5 |
merging #12391, #13263 |
| 14:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/12391 -- Minor adjustments now that OpenGLES 2 is the default driver on Android by rollerozxa |
| 14:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/13263 -- Kubernetes: Deployments are stable since v1.16 by poggenpower |
| 16:40 |
|
fluxionary joined #minetest-dev |
| 16:40 |
|
Baytuch joined #minetest-dev |
| 16:49 |
|
Flitzpiepe joined #minetest-dev |
| 16:50 |
Flitzpiepe |
Hello everyone |
| 17:05 |
|
Desour joined #minetest-dev |
| 17:13 |
|
Baytuch joined #minetest-dev |
| 17:22 |
sfan5 |
reminder: less than 40 minutes to meeting |
| 17:24 |
Krock |
I'll ping the devs 15 minutes ahead of time. timer prepared. |
| 17:44 |
rubenwardy |
!dev Meetings |
| 17:44 |
ShadowBot |
Meetings - Minetest Developer Wiki -- http://dev.minetest.net/Meetings |
| 17:45 |
Zughy[m] |
One minute earlier, buuu |
| 17:47 |
Krock |
sfan5 @x2048 rubenwardy nrz_ and whoever else has time for it. Meeting in 14 minutes. |
| 17:59 |
rubenwardy |
5.8.0, let's go! |
| 17:59 |
rubenwardy |
wait *5.7 |
| 17:59 |
Krock |
sure |
| 18:00 |
Krock |
okay let's get started |
| 18:00 |
rubenwardy |
wouldn't be the first time a version was skipped |
| 18:00 |
Krock |
> Feature freeze? |
| 18:00 |
Krock |
https://github.com/minetest/minetest/milestone/20 |
| 18:01 |
Krock |
the dual wield will be discussed later |
| 18:01 |
sfan5 |
IMO yes |
| 18:01 |
sfan5 |
question is just when, maybe not immediately |
| 18:02 |
Krock |
we can set it in 2 weeks and if dual-wield isn't ready by then so be it |
| 18:02 |
sfan5 |
well actually I'm mainly thinking about the ongoing work on Irrlicht, which might get in the way |
| 18:02 |
Krock |
would you like to have that merged before 5.7.0? |
| 18:03 |
sfan5 |
no, not like we'd turn it on by default anyway |
| 18:03 |
sfan5 |
or be able to support it in any way |
| 18:03 |
Krock |
are you talking about SDL2 integration? |
| 18:03 |
sfan5 |
the opengl3 stuff and support changes that go along with it |
| 18:04 |
sfan5 |
anyway I can tag a new irrlicht revision soon so we have a clean state |
| 18:04 |
sfan5 |
so that's solved |
| 18:04 |
Krock |
so it's mainly about irr#167 and irr#163 |
| 18:04 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/167 -- Add unified OpenGL driver by numberZero |
| 18:04 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/163 -- Drop IrrCompileConfig by numberZero |
| 18:06 |
Krock |
suggestion: let's set a feature freeze date and try to get the PRs done before that. it'll give some motivation to meet the deadline |
| 18:06 |
Desour |
if dual wield (or other APIs where we are not sure if they're designed well enough) are merged, can we please declare such new APIs as instable until the next minor release, so that we may break backwards in that next release compat for that specific feature? |
| 18:07 |
sfan5 |
Krock: the irrlicht ones? |
| 18:07 |
Krock |
sfan5: yes, if they're not enabled by default anyway then it does not matter for a release, right? I'm also thinking the same for Dual Wield |
| 18:09 |
Krock |
what do you think about that? |
| 18:10 |
sfan5 |
there's no advantages having them in a release either (almost nobody builds with SDL2) so I'd rather we not rush them in |
| 18:10 |
Desour |
s/backwards in that next release compat for/backwards compat in that next release for |
| 18:11 |
Krock |
Desour: I think it should be made as compatible as possible |
| 18:12 |
Krock |
in the current state there's no way in my option that it'll get merged |
| 18:13 |
Krock |
judging by the activity, it looks almost as if it needed adoption |
| 18:15 |
Krock |
Dual Wield could also be "fixed" by omitting the interaction part of the offhand. it would serve as a shield-indicator only until a solution is found |
| 18:15 |
sfan5 |
@x2048, rubenwardy: opinions on feature-freeze? |
| 18:16 |
rubenwardy |
I think it should happen in the next couple of weeks, it's overdue already. If dual wielding gets in that's great, but I don't want it to be rushed in any case |
| 18:19 |
sfan5 |
ok then let's freeze immediately |
| 18:21 |
Zughy[m] |
should I make an issue to pin, called "Feature freeze"? |
| 18:21 |
Krock |
seems reasonable. 5.7.0 summary so far: faster mapblock mesh, improved lua error handling, a few Lua API additions, attached facedir/4dir nodes, postgresql mod storage, rotating entity selection boxes, shadows improvements |
| 18:21 |
MTDiscord |
<x2048> +1 for a freeze |
| 18:21 |
sfan5 |
Zughy[m]: its usually just announced in irc 🤷 |
| 18:21 |
Krock |
IRC /topic |
| 18:21 |
MTDiscord |
<x2048> postprocessing: bloom, dynamic exposure etc. |
| 18:22 |
Krock |
right! I totally forgot the fancy shader additions |
| 18:22 |
Zughy[m] |
sfan5: I know but people might follow MT just on GitHub and miss it |
| 18:22 |
Zughy[m] |
If no one opposes, I'll make it |
| 18:22 |
sfan5 |
sure |
| 18:22 |
sfan5 |
next meeting point? |
| 18:22 |
kilbith |
but 2% of the userbase will actually discover bloom because the masses don't dig into advanced settings |
| 18:23 |
Krock |
please open an issue or PR to improve that in the future |
| 18:23 |
Krock |
> Dedicate the upcoming version to Jude/TurkeyMcMac |
| 18:23 |
sfan5 |
is bloom a client-side setting? I thought we wanted to make everything an API |
| 18:23 |
sfan5 |
definitely to that |
| 18:23 |
Desour |
kilbith: the same is true for many other settings |
| 18:23 |
Krock |
it's server-controllable |
| 18:23 |
kilbith |
I don't think so |
| 18:24 |
rubenwardy |
it's server-controllable but the client still needs to enable it |
| 18:24 |
Krock |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L7508-L7524 |
| 18:24 |
MTDiscord |
<x2048> bloom is client side but requires exposure to be supported by the server |
| 18:24 |
kilbith |
that's overly complicated for the average people I can tell you |
| 18:25 |
MTDiscord |
<x2048> we can make a blog post about it |
| 18:25 |
Krock |
so I'll propose a PR to update the main menu accordingly with a note. |
| 18:25 |
Desour |
kilbith: ok, maybe not "many", but e.g. always_fly_fast, inventory_items_animations |
| 18:26 |
rubenwardy |
can remove filtering and antialiasing (as it's broken anyway) |
| 18:26 |
rubenwardy |
to make space |
| 18:26 |
kilbith |
for now you can collapse all the "Waving leaves/etc." to a single "Waving environment" checkbox, so it leaves space for a bloom checkbox |
| 18:26 |
rubenwardy |
well, antialiasing will be replaced by #13253 |
| 18:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/13253 -- Add antialiasing filters (FXAA, SSAA) by x2048 |
| 18:27 |
sfan5 |
antialiasing works fine for me |
| 18:27 |
rubenwardy |
I believe it doesn't work in 5.7-dev with shaders enabled? |
| 18:27 |
rubenwardy |
or is it just with bloom/etc enabled |
| 18:27 |
sfan5 |
not sure |
| 18:28 |
sfan5 |
anyway what are the votes for > Dedicate the upcoming version to Jude/TurkeyMcMac |
| 18:28 |
kilbith |
I support that |
| 18:28 |
rubenwardy |
obviously use, should make an issue "Update credits for 5.7" and do it htere |
| 18:28 |
rubenwardy |
*yes |
| 18:28 |
MTDiscord |
<x2048> +1 from me |
| 18:28 |
Desour |
you mean the "fsaa" msaa, right? the mipmapping and aniso filter antialiasing works and should stay. |
| 18:29 |
sfan5 |
rubenwardy: yes, I plan on updating the credits anyway |
| 18:29 |
rubenwardy |
it is part of the release precedure, maybe doesn't need an issue |
| 18:29 |
MTDiscord |
<x2048> reg. AA - I will change the menu to allow the right settings whether using direct or pp pipeline. |
| 18:29 |
Krock |
sfan5: if you could do that while updating the credits that would be great. thanks. |
| 18:29 |
sfan5 |
Desour: I have 8x fsaa and mipmapping here |
| 18:32 |
Krock |
> We're choking on PRs again: shouldn't MT advertise itself more so to potentially find new core devs and/or recruit existing contributors? |
| 18:32 |
Krock |
Zughy[m]: how should that be done? |
| 18:32 |
Zughy[m] |
for instance, how about NumberZero? They seem pretty active and with enough knowledge |
| 18:33 |
kilbith |
he declined in the past |
| 18:33 |
Krock |
AFAIK the last time we asked they declined |
| 18:33 |
sfan5 |
do they want to be a coredev? |
| 18:33 |
rubenwardy |
yeah, a few times |
| 18:33 |
rubenwardy |
can't make someone be a core dev |
| 18:33 |
Zughy[m] |
We might ask again though |
| 18:34 |
kilbith |
not everybody have/want a sense of responsability over time |
| 18:34 |
Krock |
it's better if people ask on their own |
| 18:34 |
Zughy[m] |
advertising is hard, also because the only one that takes care of it is rubenwardy. Which is already busy with CDB and the engine |
| 18:34 |
Zughy[m] |
the point is, PRs keep increasing, and I fear we might reach the 150 cap again |
| 18:34 |
rubenwardy |
when it comes to recruiting core devs: it's a pipeline. User -> contributor -> core dev. If your PR takes months to years to be merged, you probably won't make more. It's a bit of a vicious cycle |
| 18:35 |
Zughy[m] |
Also, the blog is unstable |
| 18:35 |
Zughy[m] |
^ and I also guess that's kind of depressing as a core dev to see that huge pile becoming even more huge |
| 18:37 |
Zughy[m] |
unfortunately issues can't be tackled anymore, I spent months hunting them down, but I'm afraid there are no invalid/duplicate/solved issues around |
| 18:38 |
MTDiscord |
<x2048> we have a high bar for entry, might need work targeted with people who want to become core like caffeinatedblocks |
| 18:39 |
kilbith |
I'd oppose caffeinatedblocks |
| 18:39 |
kilbith |
they're annoying with pointless stuff like MariaDB |
| 18:39 |
kilbith |
can't give responsibility to someone like that |
| 18:39 |
Zughy[m] |
(in the meanwhile: feature freeze issue done, I hope is alright #13285) |
| 18:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/13285 -- 🧊 Feature freeze time |
| 18:39 |
kilbith |
or the auth stuff |
| 18:41 |
sfan5 |
next meeting point? |
| 18:41 |
rubenwardy |
devs need to be experienced enough in the language, Minetest, and the codebase to do code review |
| 18:41 |
rubenwardy |
sure |
| 18:41 |
Krock |
> "SSCSM execution" (TurkeyMcMac) |
| 18:41 |
Krock |
#13046 |
| 18:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/13046 -- SSCSM execution by TurkeyMcMac |
| 18:41 |
Krock |
it's a huge chunk that needs adoption |
| 18:43 |
Krock |
the IPC part seems to be up and running and it looks quite sophisticated |
| 18:43 |
MTDiscord |
<x2048> I can take a look at it in a couple of months |
| 18:43 |
rubenwardy |
would be a shame for this to go to waste |
| 18:43 |
Krock |
although the TODO list in the description is way too long |
| 18:44 |
Krock |
if someone wants to adopt it, the IPC part and a PoC should be merged first |
| 18:44 |
sfan5 |
if split into chunks it can probably be adopted, though I don't know which chunks since I haven't recently looked at it |
| 18:44 |
sfan5 |
I also don't know who is going to do the work, I certainly don't have the time |
| 18:45 |
rubenwardy |
it sounds a lot like SSCSM is going to be a strong contender for the roadmap, so would be good to work out how it can be done |
| 18:45 |
rubenwardy |
hopefully more successfully than the GUI replacement |
| 18:45 |
kilbith |
* the fabled GUI replacement please |
| 18:47 |
Krock |
> Reorder client initialization |
| 18:47 |
Krock |
#12189 |
| 18:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/12189 -- Reorder client initialization by SmallJoker |
| 18:48 |
Krock |
eh I guess I could rebase it when it celebrates its anniversary. there doesn't seem to be much interest in it |
| 18:48 |
sfan5 |
well I suppose it's not worth blocking this fix |
| 18:48 |
sfan5 |
(retracting my informal -1) |
| 18:49 |
Krock |
it does not seem important so it's fine to postpone a bit |
| 18:50 |
Krock |
> MariaDB |
| 18:50 |
Krock |
#13266 |
| 18:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/13266 -- MariaDB Database Backend by caffeinatedblocks |
| 18:50 |
Krock |
I added this point to clarify whether or not it's on the roadmap and in the meantime this already clarified |
| 18:52 |
Krock |
> Dual Wielding - How should we go ahead with this? |
| 18:52 |
Krock |
#11016 |
| 18:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/11016 -- Dual Wielding by LizzyFleckenstein03 |
| 18:53 |
Krock |
Desour and I already talked about it earlier. sfan5's solution is better than nothing at least |
| 18:53 |
Krock |
any inputs, suggestions, ideas? |
| 18:53 |
sfan5 |
which part? the first or second? |
| 18:53 |
Krock |
the part where you suggested an additional callback parameter and API functions |
| 18:54 |
sfan5 |
yeah |
| 18:54 |
Krock |
actually the alternative seems to be even more promising |
| 18:54 |
sfan5 |
I feel like the second could still be useful in some way in addition (modders that don't want items to work offhand?) |
| 18:54 |
MTDiscord |
<x2048> Having items declare that they support offhand sound like a cleaner solution |
| 18:55 |
Krock |
is_offhand_aware = true item def field, for example |
| 18:55 |
sfan5 |
I think we all agree that `set_offhand_wielded_item()` should exist |
| 18:56 |
sfan5 |
independent of the rest |
| 18:56 |
Krock |
isn't the offhand one stack only, anyway? |
| 18:56 |
sfan5 |
what do you mean |
| 18:56 |
Krock |
inv:set_list("offhand", { "itemstring" }) would be the alternative to that |
| 18:57 |
Krock |
assuming that the inventory list is only 1 stack big |
| 18:57 |
sfan5 |
ah, yeah sure |
| 18:57 |
sfan5 |
the hotbar has multiple slots |
| 18:57 |
sfan5 |
I guess it's not that important then |
| 18:57 |
Krock |
same situation with the "hand" slot where we don't have a function for it either (AFAIK) |
| 18:58 |
MTDiscord |
<x2048> Is hand a slot or inventory? |
| 18:58 |
sfan5 |
one thing to note: if you have an item that declares offhand awareness you'd still want to know inside on_place whether it's being used offhand or not |
| 18:58 |
Krock |
inventory list of size 1 or 0 |
| 18:58 |
sfan5 |
so we'd want the parameter either way |
| 18:59 |
MTDiscord |
<x2048> yes |
| 18:59 |
Krock |
would it make sense to include that information in pointed_thing? |
| 18:59 |
sfan5 |
hmm, I don't think so |
| 19:00 |
Krock |
mentioning that because both are calculated in the same place of the client and it's propagated to all callbacks anyway |
| 19:00 |
Krock |
("both" meaning the active stack and pointed_thing) |
| 19:00 |
sfan5 |
I mean it would fit there but offhand usage is not a property of the thing you are pointing at |
| 19:00 |
sfan5 |
not strictly |
| 19:01 |
Krock |
ah right |
| 19:02 |
Desour |
how about listname and listindex that state where the item comes from. then mods could make a player place something that they're not wielding |
| 19:02 |
Desour |
might also be interesting for fake players |
| 19:03 |
Krock |
is it needed, though? usually you update the itemstack with the return value |
| 19:03 |
sfan5 |
good idea, maybe save it up for 6.0 :D |
| 19:03 |
Desour |
6.0, or include it in that "offhand_aware" field ;) |
| 19:04 |
Krock |
the issue only starts when you use set_wielded_item(), thus offhand_aware=true might already suffice |
| 19:04 |
Krock |
because the return value properly overwrites the wielded/used stack |
| 19:05 |
Krock |
or am I missing something? |
| 19:05 |
sfan5 |
yes |
| 19:05 |
Desour |
the field could also be a "assume_use_from_wield = true" in that case |
| 19:06 |
sfan5 |
I mean "no", you're not missing anything |
| 19:06 |
Desour |
(if true, on_use and co. may only happen if the item is currently wielded) |
| 19:07 |
Krock |
Desour: obviously the callbacks should only be run when the flag is set to true |
| 19:11 |
Krock |
goddamn it. we cannot use return values in case the player dies from eating something |
| 19:11 |
Desour |
the assume_use_from_wield would inverted, and default true, that's why it's the other way around |
| 19:11 |
Krock |
https://github.com/minetest/minetest/blob/master/builtin/game/item.lua#L412 |
| 19:12 |
Krock |
perhaps the HP setter has to be delayed by a server step to make it work properly again |
| 19:13 |
Desour |
core.after(0, <kill them>) |
| 19:13 |
sfan5 |
I don't think you want to violate the invariant that p:set_hp(1);assert(p:get_hp()==1) |
| 19:13 |
sfan5 |
or allow the player to do things for 1 step while they're supposed to be dead |
| 19:14 |
MTDiscord |
<x2048> what's wrong with killing immediately? |
| 19:14 |
sfan5 |
anyway I will write the discussion results down in a comment in the PR |
| 19:14 |
Krock |
or redirect `set_wielded_item` for the time while callbacks are called? is that an option? |
| 19:14 |
Krock |
sfan5: okay then I'll not submit mine :3 |
| 19:15 |
Desour |
x2048: https://github.com/minetest/minetest/blob/master/builtin/game/item.lua#L391 |
| 19:15 |
Desour |
>-- Changing hp might kill the player causing mods to do who-knows-what to the |
| 19:15 |
Desour |
-- inventory, so do this before set_hp(). |
| 19:15 |
sfan5 |
bad idea, you never know which code is acting in intent of the item usage or another mod is just randomly wanting to check the wield item |
| 19:16 |
MTDiscord |
<x2048> ah yes, dropping items to the ground |
| 19:16 |
sfan5 |
https://github.com/minetest/minetest/issues/6546#issuecomment-488622306 this should be easiest to understand |
| 19:17 |
Krock |
sfan5: this part is single-threaded, though. the itemstack (and override) is only available inside the callback sequence. outside of that the player might already have moved the stack |
| 19:17 |
Desour |
if we had an item source params, like suggested earlier, do_item_eat could overwrite that slot instead of the wielded item |
| 19:18 |
sfan5 |
Krock: sure but you never know which side effects an item usage has and which other code it might inadvertedly call |
| 19:18 |
Krock |
sfan5: well then in this case the item def flag would prevent from running the callback, I guess? |
| 19:19 |
Krock |
that way the responsibility is again at the modder's side |
| 19:20 |
|
appguru joined #minetest-dev |
| 19:21 |
Krock |
might you please be so nice to add a link to the logs? |
| 19:22 |
Krock |
thanks |
| 19:22 |
Krock |
> Add world-independent storage directory for mods |
| 19:23 |
Krock |
#12315 |
| 19:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/12315 -- Add world-independent storage directory for mods by rubenwardy |
| 19:23 |
Krock |
question is how server owners run their stuff |
| 19:24 |
rubenwardy |
So, mod directories may be readonly and any changes will be reset when the package is updated. This PR adds a new storage directory for mods to write to rather than their own mod directory. |
| 19:24 |
rubenwardy |
The problem with this is that if there are multiple instances of Minetest running, you can end up with the same mod writing multiple times to the same file - which can cause issues |
| 19:24 |
Krock |
on another side it's handy to have a shared media cache if they want to (issues only arise when writing) |
| 19:24 |
rubenwardy |
Use cases include the ability to save schematics / stats / achievements between worlds |
| 19:24 |
sfan5 |
Krock: this is more for the sake of singleplayer/games |
| 19:25 |
rubenwardy |
yeah, this is mostly for singleplayer |
| 19:25 |
rubenwardy |
There's 3 options 1) get server owners to change the mod data path 2) add some way to handle multiple access, say with locking 3) scrape + rethink |
| 19:26 |
rubenwardy |
Mods can already write to their own directories and cause multiple process issues. I think 1) is the best thing to do here |
| 19:26 |
sfan5 |
what does 1) mean here |
| 19:26 |
Krock |
you could add a lock file and return an error if mods are trying to write while there's a lock file |
| 19:27 |
Krock |
(error return value upon io.open) |
| 19:27 |
sfan5 |
writing is not the problem with minetest.safe_file_write |
| 19:27 |
Desour |
a simple locking API should be easy enough to use. and deadlocks can be prevented with forced timeouts (of i.e. 10s) that cause a mod crash |
| 19:27 |
rubenwardy |
1) would essentially allow server owners to make the mod data per-server |
| 19:27 |
Krock |
that misses the point. It's supposed to be *independetly of worlds", as you wrote |
| 19:27 |
sfan5 |
but you cannot properly read + update + write, you'd need a lock for the entire duration |
| 19:27 |
sfan5 |
rubenwardy: I don't see how that's needed |
| 19:28 |
sfan5 |
and if they want they can just use run_in_place |
| 19:28 |
sfan5 |
or docker containers |
| 19:28 |
sfan5 |
or something else |
| 19:28 |
sfan5 |
many server owners probably also run a setup incompatible with this feature |
| 19:28 |
Desour |
local lock = minetest.lock_world_independet_dir(modname) --[[ do file operations ]] lock:free() |
| 19:31 |
Krock |
or a per-mod persistent directory could be added. one that's not overwritten |
| 19:31 |
rubenwardy |
that's functionally equivalent, doesn't solve the problem here |
| 19:32 |
Krock |
not if you place the mods into worldmods/ 8) |
| 19:33 |
Krock |
but in that case it's not exchangeable. if you want shared data, then you need locking. simple as that. |
| 19:34 |
rubenwardy |
yeah. Well, the idea behind 1) is that it's the responsibility of the server owner and can be disabled |
| 19:34 |
rubenwardy |
How hard is filesystem locking without causing and server freezes? |
| 19:36 |
Krock |
what if all write operations are sent to temporary file, and these swapped at once? |
| 19:37 |
rubenwardy |
sounds like safe_file_write |
| 19:37 |
sfan5 |
doesn't fix anything |
| 19:37 |
sfan5 |
rubenwardy: not very, sqlite3 does it |
| 19:37 |
sfan5 |
but if you give mods free hand in allocating and freeing locks that'll be bad |
| 19:37 |
Krock |
I meant to integrate it into io.open() |
| 19:39 |
sfan5 |
Krock: instance A: reads value=1, increments, instance B: reads value=1, increments, A: safely writes value=2, B: safely writes value=2 |
| 19:39 |
sfan5 |
doesn't work |
| 19:40 |
Desour |
>but if you give mods free hand in allocating and freeing locks that'll be bad <-- why? |
| 19:40 |
Krock |
that's nasty |
| 19:40 |
rubenwardy |
the locking API could be a callback, acting like try-with |
| 19:40 |
rubenwardy |
also solves issues where the lock isn't immediately available |
| 19:40 |
sfan5 |
I guarantee you at least one mod author will unconditionally take the log at startup and never free it |
| 19:41 |
sfan5 |
and it will work, usually |
| 19:41 |
sfan5 |
(how many people start Minetest multiple times?) |
| 19:41 |
rubenwardy |
pretty much only server owners |
| 19:41 |
Krock |
(too many) |
| 19:41 |
rubenwardy |
*start Minetest servers |
| 19:42 |
rubenwardy |
this feature is designed for singleplayer and local worlds, rather than for server owners |
| 19:42 |
MTDiscord |
<x2048> Can it be disabled by default minetestserver / --server? |
| 19:43 |
sfan5 |
what exactly do you want to "disable!" |
| 19:44 |
rubenwardy |
make it act per-world rather than independently |
| 19:44 |
Desour |
if the lock is never freed, that's fine. users can then not run multiple instances of the mod at once, which can even be an intended restriction |
| 19:44 |
rubenwardy |
should have bought more mod licenses |
| 19:45 |
Desour |
rubenwardy: I can sell you some LICENSE.txt files if you want c: |
| 19:45 |
MTDiscord |
<x2048> I'd go with the feature without concurrency guarantees actually. Like network filesystems. |
| 19:47 |
Desour |
btw. there's also another issue than concurrency stuff. what if there are two mods with the same name that are completely different, or at least forks |
| 19:47 |
sfan5 |
NFS has locks I think(?) |
| 19:49 |
sfan5 |
rubenwardy: anyway here's what I was thinking https://0x0.st/HzlG.txt |
| 19:49 |
pgimeno |
is in-database mod storage not an option? |
| 19:50 |
sfan5 |
would minimize abuse potential by mods and be easy to use and hard to get wrong |
| 19:50 |
rubenwardy |
that makes sense to me |
| 19:52 |
sfan5 |
pgimeno: can probably do safe writes but I don't think the "locked incrementing" usecase can be done with that either |
| 19:53 |
rubenwardy |
providing it can be implemented easily without blocking the server thread |
| 19:53 |
pgimeno |
if databases can't do locked incrementing then the world has a problem |
| 19:53 |
sfan5 |
databases can but our mod storage can't |
| 19:54 |
pgimeno |
sounds like an API problem then? |
| 19:54 |
nrz_ |
Sorry, what is the issue with locks you Want to solve? |
| 19:54 |
sfan5 |
rubenwardy: well maybe, question is would you actually want to delay the callback a mod has given to you until a later step? IMO it's better if the server tries immediately and just times out if it doesn't work |
| 19:55 |
rubenwardy |
how long would the timeout be? 0? |
| 19:55 |
sfan5 |
one or two seconds, mods should avoid using it that often |
| 19:56 |
Krock |
you could specify the timeout in the API call |
| 19:56 |
sfan5 |
pgimeno: well sure? this is just the first time it would ever be relevant since mods are fully single-threaded |
| 19:56 |
Krock |
(if what we're talking about is the timeout until calling the callback after X server steps) |
| 19:57 |
sfan5 |
nrz_: https://github.com/minetest/minetest/pull/12315#issuecomment-1435415253 |
| 19:57 |
Krock |
hard-locking the server - regardless of the time - is a bad idea |
| 19:58 |
Desour |
(it could also time-out as soon as any other callback needs to be executed) |
| 19:59 |
sfan5 |
rubenwardy: what usecases do modders have for this anyway |
| 19:59 |
rubenwardy |
Use cases include the ability to save schematics / stats / achievements between worlds |
| 19:59 |
sfan5 |
the usecase that would require the "locked incrementing" I keep talking about would be statistics |
| 20:00 |
pgimeno |
I wonder if we're talking about a non-problem though. I'd rather we forbid separate instances to run at all when the data dir is shared, via a file lock. |
| 20:00 |
rubenwardy |
what about server owners hosting multiple servers? |
| 20:00 |
Krock |
envrionment variable |
| 20:00 |
rubenwardy |
option 1 is to allow server owners to make the mod data directory via a setting |
| 20:00 |
sfan5 |
shared folder that is exclusive to use ;) |
| 20:01 |
Krock |
unshared shared folder |
| 20:01 |
rubenwardy |
option 1 at the start of this convo was to allow server owners to make the mod data directory per-world/server via a setting |
| 20:01 |
rubenwardy |
** |
| 20:01 |
rubenwardy |
(which they could also do with a container or run_in_place) |
| 20:02 |
pgimeno |
so, first step would be to gather information on how people who host multiple servers organize the data dirs |
| 20:02 |
MTDiscord |
<x2048> I'd vote for that and skip the locking problem entirely |
| 20:02 |
MTDiscord |
<x2048> And make that the default for servers |
| 20:03 |
Desour |
it's shared, but not used by two entities at once that are both active, like a toilet |
| 20:03 |
sfan5 |
that's just handwaving the problem away |
| 20:03 |
sfan5 |
this feature is meant for singleplayer or games anyway |
| 20:04 |
sfan5 |
assuming we don't want to do the "don't allow multiple instances" thing |
| 20:06 |
sfan5 |
well I don't know, we could elect not to care and not do anything |
| 20:06 |
pgimeno |
forbidding multiple instances if they share a data dir, would be the way to ensure that option 1 is viable and respecting |
| 20:06 |
pgimeno |
respected* |
| 20:07 |
Desour |
but it would be bad for subgames that want to add achievements |
| 20:08 |
sfan5 |
since all instances are supposed to share this folder this would mean prohibiting multiple instances -> not an option |
| 20:08 |
MTDiscord |
<x2048> How would achievements work with shared dir? |
| 20:08 |
rubenwardy |
arguably, the use case there would only be in singleplayer - with servers, you wouldn't know if it's the same player and each server could have different ecomies |
| 20:08 |
rubenwardy |
*economies |
| 20:08 |
rubenwardy |
RE: achievements |
| 20:08 |
Desour |
but people start multiple singleplayer instances |
| 20:09 |
sfan5 |
you keep a file where you save whether the player has gotten the achivement, since it's global you know whether he has ever gotten it not just in this world, if he gets an achievement you update the file. |
| 20:09 |
rubenwardy |
obviously we just need client meta 🍪 |
| 20:09 |
sfan5 |
in this case the player = singleplayer, no use in MP |
| 20:10 |
MTDiscord |
<x2048> each world is uniquely randomly generated, why achievements in one would mean anything in another? |
| 20:10 |
Desour |
client meta 🍪 then also needs synchronization between multiple client instances |
| 20:10 |
MTDiscord |
<x2048> It's sounds like a very niche case. |
| 20:11 |
MTDiscord |
<x2048> If we wamt a global ladder, let's build a global ladder. |
| 20:11 |
|
Pexin joined #minetest-dev |
| 20:11 |
|
Thomas-S joined #minetest-dev |
| 20:11 |
|
basxto joined #minetest-dev |
| 20:11 |
|
nore joined #minetest-dev |
| 20:11 |
MTDiscord |
<x2048> *want |
| 20:12 |
MTDiscord |
<luatic> Skin mods could potentially benefit from a shared global folder. |
| 20:12 |
sfan5 |
this is literally how achievements work in just about every game (even random open world games) |
| 20:12 |
rubenwardy |
yeah, lots of games have cross-save achievements |
| 20:12 |
MTDiscord |
<luatic> Epidermis downloads SkinDB skins to the world folder. This leads to duplicate skins across worlds. |
| 20:12 |
rubenwardy |
for use-cases, you probably want to look at the reasons why mods are currently writing to the mod dir |
| 20:13 |
MTDiscord |
<luatic> I could also write to the mod dir, but that would require an insecure environment. |
| 20:13 |
MTDiscord |
<luatic> (that said, I do like writing to the world dir, because it means I don't have to worry about such locking / concurrency issues) |
| 20:29 |
MTDiscord |
<x2048> ok, achievements per game sound reasonable, but it's per game, not per mod like the epidermis case. |
| 20:29 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. FEATURE FREEZE IN EFFECT SINCE 2023-03-05.Chit-chat goes to #minetest. https://dev.minetest.net/ https://irc.minetest.net/ https://github.com/minetest |
| 20:29 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. FEATURE FREEZE IN EFFECT SINCE 2023-03-05. Chit-chat goes to #minetest. https://dev.minetest.net/ https://irc.minetest.net/ https://github.com/minetest |
| 20:30 |
sfan5 |
a game is just a mod in this case ;-) |
| 20:30 |
sfan5 |
however we might have a problem if different games have a mod called e.g. 'default' |
| 20:30 |
MTDiscord |
<x2048> does not work |
| 20:30 |
MTDiscord |
<x2048> exactly, evdryone will reuse the mod |
| 20:30 |
rubenwardy |
yeah - Desour has suggested using paths.replace("/", ".") |
| 20:30 |
rubenwardy |
virtual path would be a good candidate, as it's normalised to be portable |
| 20:30 |
sfan5 |
well what if you move a mod |
| 20:31 |
MTDiscord |
<x2048> I'd suggest having per-game and per-mod state |
| 20:31 |
rubenwardy |
then it will lose the data |
| 20:31 |
rubenwardy |
per-game can just be a mod named the same as the game |
| 20:31 |
MTDiscord |
<x2048> Abstracted from filesystem |
| 20:31 |
sfan5 |
maybe we game mods could additionally be distinguished by game |
| 20:31 |
sfan5 |
-we |
| 20:31 |
sfan5 |
but we could also not care about this since most non-MTG games already use different names |
| 20:32 |
rubenwardy |
yeah - and ContentDB also enforces mod name uniqueness (minus forks) which will avoid a lot of cases |
| 20:32 |
MTDiscord |
<x2048> I don't think it will |
| 20:33 |
MTDiscord |
<x2048> Someone publishes achievementd mod for MTG, and them it lands im all modsoups |
| 20:33 |
Desour |
my example (see github) involves a fork |
| 20:33 |
Desour |
(i.e. a fork "updates" a data format) |
| 20:34 |
sfan5 |
hmm |
| 20:34 |
MTDiscord |
<x2048> Games are a thing. Forcing gamedevelopers to rename the mods to implement it is unfair. |
| 20:35 |
Desour |
> well what if you move a mod <-- users should be told about the data stored in there. they also need this information for doing backups and for removing data that came from now uninstalled mods |
| 20:35 |
Desour |
I hate it when programs do not document their stored data |
| 20:35 |
rubenwardy |
ContentDB already forces game developers to rename mods, to namespace them. This issue documents that problem #12034 |
| 20:35 |
rubenwardy |
Obviously, this doesn't apply to games shipped outside of CDB |
| 20:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/12034 -- Improve mod dependency system |
| 20:36 |
Desour |
s/in there/in the world independent dir/ |
| 20:36 |
rubenwardy |
perhaps rather than path it could use `author-name` |
| 20:36 |
Desour |
^ that would be inconsistent to what world.mt does |
| 20:37 |
Desour |
(and I wonder what happens if some author wants their name to be changed or removed, for privacy reasons) |
| 20:37 |
rubenwardy |
sfan5: probably a good idea to do a release candidate for the feature freeze - please may I have a Windows build? |
| 20:38 |
rubenwardy |
CDB has package aliases for changing author name, could change mod data too - but that only works when installing from CDB |
| 20:38 |
rubenwardy |
also, going back to the path option, by default if you try to install a mod with the same name as an installed mod at mods/, it'll overwrite that mod |
| 20:38 |
rubenwardy |
so forks will have the same path |
| 20:38 |
rubenwardy |
*may |
| 20:39 |
Desour |
that's not an issue. if you knowingly replace a mod, that mod should inherit the data path |
| 20:40 |
|
appguru joined #minetest-dev |
| 20:43 |
sfan5 |
rubenwardy: I'll tag irrlichtmt first |
| 20:43 |
rubenwardy |
makes sense |
| 20:55 |
|
Desour_ joined #minetest-dev |
| 21:11 |
Desour_ |
would someone like to merge #12979? it's quite trivial |
| 21:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/12979 -- Improvement of #12974: better lin independent vector by Desour |
| 21:12 |
sfan5 |
https://github.com/minetest/minetest/commit/9ef3c8ce388011f4f57adc9a7eb0326376aec750 pushing to master shortly |
| 21:13 |
rubenwardy |
lgtm |
| 21:13 |
rubenwardy |
does the android dep repo need to be updated? |
| 21:13 |
rubenwardy |
guess so https://github.com/minetest/minetest_android_deps/blob/master/scripts/Irrlicht.sh#L2 |
| 21:15 |
sfan5 |
yes |
| 21:32 |
rubenwardy |
can that be done now? |
| 21:33 |
sfan5 |
it has to happen before release, that includes now |
| 21:33 |
rubenwardy |
right done |
| 21:34 |
rubenwardy |
when the CI builds, I'll do an Android build - will try using CI + apksigner |
| 21:40 |
sfan5 |
rubenwardy: https://github.com/sfan5/minetest/files/10893025/minetest-5.7.0-9ef3c8c-rc1-win32.zip https://github.com/sfan5/minetest/files/10893026/minetest-5.7.0-9ef3c8c-rc1-win64.zip |
| 21:41 |
rubenwardy |
thanks |
| 21:45 |
rubenwardy |
https://forum.minetest.net/viewtopic.php?f=18&t=29249 |
| 21:46 |
sfan5 |
I wonder if the different server list sorting is subtle enough that people won't notice |
| 21:47 |
sfan5 |
(don't edit the post now to put it in there) |
| 21:47 |
rubenwardy |
too late, someone already made a topic about it |
| 21:48 |
rubenwardy |
https://forum.minetest.net/viewtopic.php?f=5&t=29184 |
| 22:40 |
pgimeno |
could the dedication be made somehow visible in the release? like in the main menu, or at least in the log |
| 22:40 |
rubenwardy |
for RBA, it was at the top of the credits in [About] |
| 22:41 |
pgimeno |
that works |
| 22:45 |
rubenwardy |
kilbith: what's your latest long-range (1000+) performance on 5.7-dev? |
| 22:46 |
rubenwardy |
still https://www.youtube.com/watch?v=P28BBRu7hQM |
| 22:46 |
rubenwardy |
want to put a statistic to the long distance performance improvements, like 1000 view range at X FPS |
| 22:47 |
rubenwardy |
that video looks like it has jitter / a lower fps |
| 22:47 |
rubenwardy |
but is also 4k |
| 23:00 |
kilbith |
jitter come from screen recording and big fat shaders, and >8 million pixels to display |
| 23:01 |
kilbith |
https://irc.minetest.net/minetest-dev/2023-02-18#i_6056582 |
| 23:02 |
kilbith |
would get more FPS with 8x block meshes obviously |
| 23:07 |
|
kilbith joined #minetest-dev |
| 23:16 |
rubenwardy |
oh, I built Android but then completely forgot to do anything with it |
| 23:22 |
|
proller joined #minetest-dev |
| 23:28 |
rubenwardy |
added android build |
| 23:32 |
rubenwardy |
is the macos-build from GitHub actions useable? |
| 23:44 |
rubenwardy |
user reports that it works, added |
