Time Nick Message 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 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: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 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:50 Flitzpiepe Hello everyone 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 +1 for a freeze 18:21 sfan5 Zughy[m]: its usually just announced in irc 🤷 18:21 Krock IRC /topic 18:21 MTDiscord 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 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 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 +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 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 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 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 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 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 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, ) 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 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 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: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 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 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 I'd vote for that and skip the locking problem entirely 20:02 MTDiscord 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 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 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 It's sounds like a very niche case. 20:11 MTDiscord If we wamt a global ladder, let's build a global ladder. 20:11 MTDiscord *want 20:12 MTDiscord 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 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 I could also write to the mod dir, but that would require an insecure environment. 20:13 MTDiscord (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 ok, achievements per game sound reasonable, but it's per game, not per mod like the epidermis case. 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 does not work 20:30 MTDiscord 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 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 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 I don't think it will 20:33 MTDiscord 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 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:43 sfan5 rubenwardy: I'll tag irrlichtmt first 20:43 rubenwardy makes sense 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:16 rubenwardy oh, I built Android but then completely forgot to do anything with it 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