| Time |
Nick |
Message |
| 00:22 |
|
SFENCE joined #luanti-dev |
| 00:54 |
|
SFENCE joined #luanti-dev |
| 01:28 |
|
SFENCE joined #luanti-dev |
| 01:52 |
|
SFENCE joined #luanti-dev |
| 02:28 |
|
SFENCE joined #luanti-dev |
| 03:01 |
|
SFENCE joined #luanti-dev |
| 03:32 |
|
SFENCE joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 04:01 |
|
SFENCE joined #luanti-dev |
| 04:31 |
|
SFENCE_arch joined #luanti-dev |
| 04:36 |
|
SFENCE joined #luanti-dev |
| 04:51 |
|
SFENCE joined #luanti-dev |
| 05:04 |
|
SFENCE joined #luanti-dev |
| 05:43 |
|
SFENCE joined #luanti-dev |
| 05:58 |
|
SFENCE joined #luanti-dev |
| 06:35 |
|
SFENCE joined #luanti-dev |
| 07:00 |
|
YuGiOhJCJ joined #luanti-dev |
| 07:20 |
|
SFENCE joined #luanti-dev |
| 07:46 |
|
SFENCE joined #luanti-dev |
| 07:50 |
|
SFENCE joined #luanti-dev |
| 08:22 |
|
Warr1024 joined #luanti-dev |
| 08:42 |
|
SFENCE joined #luanti-dev |
| 08:46 |
|
Warr1024 joined #luanti-dev |
| 09:49 |
|
SFENCE joined #luanti-dev |
| 11:01 |
|
SFENCE joined #luanti-dev |
| 11:06 |
|
SFENCE joined #luanti-dev |
| 11:27 |
|
SFENCE joined #luanti-dev |
| 11:44 |
|
SFENCE joined #luanti-dev |
| 12:03 |
|
SFENCE joined #luanti-dev |
| 12:15 |
|
SFENCE joined #luanti-dev |
| 13:04 |
|
SFENCE joined #luanti-dev |
| 13:10 |
[MatrxMT] |
<Zughy> reminder meeting today |
| 13:37 |
MTDiscord |
<luatic> i just realized that our lua_api.md does not seem to state that you should be targeting 5.1? |
| 13:40 |
[MatrxMT] |
<Zughy> I also don't think we state the existence of DIR_DELIM anywhere except for the main menu api |
| 13:41 |
MTDiscord |
<luatic> 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] |
<Zughy> Even if do something like `local path = dir .. "/" .. subdir` ? |
| 13:47 |
[MatrxMT] |
<Zughy> dir could be, I don't know, get_worldpath |
| 13:47 |
MTDiscord |
<luatic> 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] |
<Zughy> Oh, nice. Do we state it somewhere? |
| 13:48 |
MTDiscord |
<luatic> i don't know |
| 14:26 |
sfan5 |
afaik the libc even does this for you |
| 14:37 |
|
SFENCE joined #luanti-dev |
| 14:50 |
|
SFENCE joined #luanti-dev |
| 15:09 |
MTDiscord |
<wsor4035> related: https://github.com/luanti-org/luanti/pull/13759 |
| 15:43 |
|
SFENCE joined #luanti-dev |
| 16:09 |
|
fluxionary joined #luanti-dev |
| 17:37 |
[MatrxMT] |
<Zughy> meeting in ~20 minutes |
| 17:50 |
|
SFENCE joined #luanti-dev |
| 17:58 |
|
cx384 joined #luanti-dev |
| 17:59 |
Krock |
Pinging those who reacted. Zughy sfan5 (me) |
| 18:00 |
MTDiscord |
<luatic> i'm also here |
| 18:00 |
Krock |
Meeting points: https://docs.luanti.org/for-engine-devs/meetings/ |
| 18:00 |
[MatrxMT] |
<Zughy> 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 |
<wsor4035> 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] |
<y5nw> 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 |
|
SFENCE joined #luanti-dev |
| 18:06 |
[MatrxMT] |
<y5nw> #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] |
<y5nw> 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 |
<luatic> given that we now use scancodes we shouldn't have problems with keyboard layouts anymore |
| 18:12 |
[MatrxMT] |
<y5nw> IMO there is the also option of re-assessing keyboard issues later (e.g. when we move to SDL3) |
| 18:13 |
[MatrxMT] |
<y5nw> 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 |
|
SFENCE joined #luanti-dev |
| 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] |
<y5nw> 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 |
<luatic> 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 |
<greenxenith> 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 |
<greenxenith> Thats not the point of that |
| 18:34 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> Also not the point |
| 18:35 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> In the note |
| 18:36 |
Krock |
which note? |
| 18:37 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> 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 |
<greenxenith> 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 |
|
SFENCE joined #luanti-dev |
| 18:38 |
MTDiscord |
<greenxenith> The current one? |
| 18:38 |
Krock |
the practice that is apparently active now. I cannot find anything. |
| 18:38 |
MTDiscord |
<greenxenith> Beats me. Zughy? |
| 18:39 |
[MatrxMT] |
<Zughy> 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 |
<greenxenith> It is intrinsically documented in the milestone due dates ;p |
| 18:40 |
Krock |
okay time to open an issue. |
| 18:41 |
MTDiscord |
<luatic> on the docs repo |
| 18:41 |
Krock |
on the docs repo |
| 18:41 |
MTDiscord |
<greenxenith> 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 |
<luatic> https://tenor.com/view/agony-gif-23084585 |
| 18:42 |
MTDiscord |
<greenxenith> Luanti documentation will get moved to the docs repo at some point anyway, may as well get ahead |
| 18:42 |
MTDiscord |
<luatic> 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 |
<greenxenith> 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 |
|
SFENCE joined #luanti-dev |
| 18:46 |
MTDiscord |
<luatic> 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 |
<luatic> non-node items? |
| 18:52 |
MTDiscord |
<luatic> like a shiny diamond craftitem |
| 18:52 |
[MatrxMT] |
<Zughy> 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] |
<Zughy> all the lines below kept repeating the one prior |
| 18:56 |
Krock |
stack overflow |
| 18:56 |
MTDiscord |
<luatic> 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 |
|
SFENCE joined #luanti-dev |
| 18:59 |
MTDiscord |
<luatic> 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 |
<luatic> 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:08 |
|
SFENCE joined #luanti-dev |
| 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:19 |
|
MTDiscord joined #luanti-dev |
| 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. |
| 19:41 |
|
SFENCE joined #luanti-dev |
| 21:26 |
|
MTDiscord joined #luanti-dev |
| 22:02 |
|
YuGiOhJCJ joined #luanti-dev |
| 22:19 |
[MatrxMT] |
<Zughy> so how about the freeze? Have we decided something? |
| 22:32 |
|
panwolfram joined #luanti-dev |
