Time Nick Message 13:10 [MatrxMT] reminder meeting today 13:37 MTDiscord i just realized that our lua_api.md does not seem to state that you should be targeting 5.1? 13:40 [MatrxMT] I also don't think we state the existence of DIR_DELIM anywhere except for the main menu api 13:41 MTDiscord DIR_DELIM is in a bit of a limbo, it shouldn't really need to exist since the engine should normalize paths, replacing / with \ on windows 13:46 [MatrxMT] Even if do something like `local path = dir .. "/" .. subdir` ? 13:47 [MatrxMT] dir could be, I don't know, get_worldpath 13:47 MTDiscord yes, the moment you pass that to an io.* function, or dofile, or get_worldpath, or whatever, the path ends up in the engine's hands (it has to for mod security alone), and then it should do the normalization 13:48 [MatrxMT] Oh, nice. Do we state it somewhere? 13:48 MTDiscord i don't know 14:26 sfan5 afaik the libc even does this for you 15:09 MTDiscord related: https://github.com/luanti-org/luanti/pull/13759 17:37 [MatrxMT] meeting in ~20 minutes 17:59 Krock Pinging those who reacted. Zughy sfan5 (me) 18:00 MTDiscord i'm also here 18:00 Krock Meeting points: https://docs.luanti.org/for-engine-devs/meetings/ 18:00 [MatrxMT] hi 18:00 Krock > Feature freeze time: I suggest doing it now and err on the side of caution, keeping the feature PRs in the milestone and releasing a RC in the next meeting (Zughy) 18:01 Krock Milestone: https://github.com/luanti-org/luanti/milestone/26 18:02 Krock I suppose that the "node specular" feature and SDL key lookup would take longest 18:02 Krock 15945 is pretty much a trivial one-liner 18:03 MTDiscord can sdl2 actually be shipped this release, or would it need to be disabled yet again? 18:03 Krock hmm. Wasn't only the key input topic the last remaining part? 18:04 [MatrxMT] There are some minor loose ends that I would like to tie up first; mainly #15791 and adding a warning for older keybinding settings 18:04 ShadowBot https://github.com/luanti-org/luanti/issues/15791 -- Move keybinding settings to (Lua-based) setting menu by y5nw 18:05 Krock noted for re-review 18:06 Krock any other SDL2-blocker? 18:06 [MatrxMT] #15973? 18:06 ShadowBot https://github.com/luanti-org/luanti/issues/15973 -- Build with SDL by default on macOS? 18:07 SFENCE_arch It is nice to have, not a blocker I belive. 18:08 [MatrxMT] Ah, I was thinking "blocker" a bit loosely 18:08 Krock I do remember another issue about inputs not working on certain keyboard layouts, but couldn't find it yet to find out whether it's SDL2-related or not 18:09 Krock there's #15010 for example. 18:09 ShadowBot https://github.com/luanti-org/luanti/issues/15010 -- OS doesn't receive keys captured by Minetest [SDL] 18:10 MTDiscord given that we now use scancodes we shouldn't have problems with keyboard layouts anymore 18:12 [MatrxMT] IMO there is the also option of re-assessing keyboard issues later (e.g. when we move to SDL3) 18:13 [MatrxMT] Then we have one less source of potential bugs (sdl2-compat) 18:13 Krock targeting SDL3 right away would be nice but I presume it's still too early for that 18:16 Krock the other blocker: #15898 - sfan's suggestion does sound good. Extending the nodedef (tiledef) by a field and that's it 18:16 ShadowBot https://github.com/luanti-org/luanti/issues/15898 -- Node specular needs to be disabled *or* server-configurable and off by default 18:16 [MatrxMT] Agreed that we don't have to rush for that. I have suggested before (maybe not on IRC) that we might want to first do some refactoring anyway before switching to SDL3 18:17 Krock refactoring/cleaning up sounds good. let's hope someone has time for that 18:19 Krock Shall we discuss any other issue (preferably from the milestone) ? 18:22 cx384 Should #15979 be added to the milestone, because the issue is high priority? (like it was done for #15971) 18:22 ShadowBot https://github.com/luanti-org/luanti/issues/15979 -- Add `inventory_image_animation` and `wield_image_animation` by cx384 18:22 ShadowBot https://github.com/luanti-org/luanti/issues/15971 -- Add allow_close[] element to formspecs by v-rob 18:23 SFENCE_arch if we want to do feature freeze today... 18:24 MTDiscord i'm reviewing 15971 right now 18:24 Krock SFENCE_arch: looking at the milestone I would assume perhaps another 3 weeks until freeze 18:26 SFENCE_arch Yes, there is two blockers in milestone and some regression bugs. 18:27 cx384 I will just add it. 18:29 SFENCE_arch We can always move PR, issues to next milestone, how we did many times. So question is probably, what we really want to fix for next release. 18:29 Krock okay. I'll have to test the animation feature in the first place to see whether the proposed API makes sense. 18:30 Krock adding it to the milestone for the reason you mentioned is OK 18:31 MTDiscord SFENCE_arch: The next meeting point may make fitting more features in the next release tricky 18:32 Krock > Release schedule shift to accommodate game jam schedule 18:33 Krock Are the modders already relying on 5.12.0-dev features, or will they be? 18:33 MTDiscord Thats not the point of that 18:34 MTDiscord The jam is in November which will coincide with a release every year which makes things worse for everyone (a release directly mid-work-period means inconsistent versions across entries and also means you get less consistent testing) 18:35 Krock ah, November again. that explains why there's yet nothing to be found in the forums. I don't think we can plan this far ahead 18:35 MTDiscord Also not the point 18:35 MTDiscord The point is that we are proposing shifting the Luanti release schedule entirely 18:36 Krock uhm where's this schedule documented? 18:36 MTDiscord In the note 18:36 Krock which note? 18:37 MTDiscord Its on the meeting point 18:37 SFENCE_arch I remember that in previous year, we wants to keep on schedule, four rleases per year? If it is a point, we sould not postpone release because of features. 18:37 MTDiscord The proposal is to continue the normal schedule for May, then do an early light-weight release in July, then continue the 3-month pattern from there 18:38 MTDiscord That way the Luanti release will fall in October instead of November 18:38 Krock I meant: "where is this 3 month schedule documented?" 18:38 MTDiscord The current one? 18:38 Krock the practice that is apparently active now. I cannot find anything. 18:38 MTDiscord Beats me. Zughy? 18:39 [MatrxMT] I don't know if it's documented (sorry, busy with a lovely segfault report), but it's definitely what we've been doing for months 18:40 MTDiscord It is intrinsically documented in the milestone due dates ;p 18:40 Krock okay time to open an issue. 18:41 MTDiscord on the docs repo 18:41 Krock on the docs repo 18:41 MTDiscord Since it isnt documented, before we go writing it down, we should finish discussing the alteration 18:41 Krock or I could open it in the luanti repo, since we have some documentation there as well 18:42 MTDiscord https://tenor.com/view/agony-gif-23084585 18:42 MTDiscord Luanti documentation will get moved to the docs repo at some point anyway, may as well get ahead 18:42 MTDiscord i think the docs repo (formerly the wiki) is the right place for development process things, specifically https://docs.luanti.org/for-engine-devs/releasing-luanti/ seems like a good place for this 18:44 Krock @luatic I'm already ahead 18:44 MTDiscord Regardless of what is written down, the current schedule is Feb May Aug Nov. The proposed new schedule is Jan April Jul Oct. I dont think anyone on the dev side really cares what months the releases happen in. The transition would be to do an early release in July after the May release. 18:46 MTDiscord yeah given there's a tangible reason i wouldn't mind juggling the months a little 18:47 Krock https://github.com/luanti-org/docs.luanti.org/issues/225 18:47 Krock the months don't matter but if we should align for something, that should be noted. 18:48 Krock *the months generally don't 18:49 Krock Any other points to discuss? 18:50 Krock cx384: #15979 - why does this need a specific API? is there an edge-case that cannot be covered by using the default animation? 18:50 ShadowBot https://github.com/luanti-org/luanti/issues/15979 -- Add `inventory_image_animation` and `wield_image_animation` by cx384 18:51 Krock (as in: the same animation that's used in-world) 18:51 Krock are there any specific use-cases? 18:52 MTDiscord non-node items? 18:52 MTDiscord like a shiny diamond craftitem 18:52 [MatrxMT] since we're all here, I have a segfault for you: #15988 18:52 ShadowBot https://github.com/luanti-org/luanti/issues/15988 -- Segfault with attachments 18:53 Krock @luatic I see. Yes, that could be an interesting effect. 18:54 sfan5 <+Krock> I suppose that the "node specular" feature [...] would take longest 18:54 sfan5 removing it is trivial 18:54 Krock sfan5: it's already disabled by default so it wouldn't make much difference for most players 18:55 sfan5 I know 18:55 sfan5 the point is control 18:55 Krock also reading your suggestion made me realize that it could be solved very easily (perhaps 40 LoC) 18:55 Krock @Zughy: is this the full backtrace? 18:56 [MatrxMT] all the lines below kept repeating the one prior 18:56 Krock stack overflow 18:56 MTDiscord as for the specular thing, let's please write the API in such a way that it can be cleanly extended to a proper PBR material API later on 18:56 cx384 Krock: Which part of the API do you mean? It uses the existing "Tile Animation definition" which is also used for nodes. 18:57 sfan5 and how should that look? 18:57 sfan5 IMO we should just get rid of this feature 18:58 Krock @luatic I'd say feel free to propose a simple code example of how the definition would look like. I suppose it would be similar to what sfan5 suggested in the tiel def 18:58 Krock *tile def 18:59 cx384 Krock: Craftitems can only have an inventory_image and no tiles. So you can't use animated tiles for items. 18:59 MTDiscord somewhat, though if i give it a second thought maybe it is good for this to be a separate thing from proper PBR 18:59 MTDiscord because the formulae currently being used probably have little to do with a proper PBR model like the gltf one 19:00 Krock cx384: couldn't we change the code to re-use the animated tiles field instead? 19:00 Krock introduction a new field for the same thing seems... complicated? 19:00 sfan5 adding a field to the tiledef is also in the way of using a specular map texture in the future 19:00 Krock disclaimer: I haven't looked at this code area yet 19:04 cx384 Krock: The inventory_image is used to override the image (also for node items) so even if we get #3551 the "tiles" field can't be reused, I think. 19:04 ShadowBot https://github.com/luanti-org/luanti/issues/3551 -- Add support for mesh items 19:08 cx384 For example if you have a node item which should use an animated item image different form the node mesh, like the minetest game torch. 19:11 cx384 Krock: Look at the video I added at the PR, the animated torch item image would not be possible if it would reuse the "tiles" field. 19:11 Krock cx384: haha I see. without the inventory_image field, the torch is rotated by 90° which looks funny but sadly incorrect 19:14 Krock but.. why 19:18 cx384 It uses a mesh drawtype so I guess the mesh is rotated. 19:20 Krock because it uses wallmounted param2, and value 1 by default 19:20 Krock this torch is cooked 19:20 cx384 there is also default:torch_ceiling 19:22 Krock yes. that uses param2 = 0, which would make sense. the upright torch is not meant to be rotated and yet it uses a non-zero param2, which is a strange thing to do. 22:19 [MatrxMT] so how about the freeze? Have we decided something?