Time Nick Message 07:42 Krock rubenwardy: How can I execute builtin/mainmenu/content/tests/pkgmgr_spec.lua ? 07:43 Krock what framework does it use? 07:45 Krock hm. I found the "describe" function here: https://lunarmodules.github.io/busted/ so busted... perhaps. 07:53 Krock > busted --lua=luajit --pattern=pkgmgr_spec builtin 17:31 Krock Meeting in 30 minutes or so. Thanks to @luatic for arranging that ;) 18:00 MTDiscord no problem, thanks for taking the time! ping Krock, Desour, @y5nw 18:00 Desour pong 18:00 SFENCE Hi 18:00 Krock may the lecture begin 18:02 MTDiscord Alright, let's discuss #16870 18:02 ShadowBot https://github.com/luanti-org/luanti/issues/16870 -- Add matrix & rotation Lua APIs (2nd try) by appgurueu 18:03 MTDiscord First of all, the meta-questions: Should we mark the APIs experimental just to be sure we can fix obvious deficiences if they are reported to us following a release? 18:03 MTDiscord We could probably remove the "experimental" note after 2 or 3 versions have released with nobody complaining. 18:04 MTDiscord This ties into the broader question of whether we should mark things experimental more, and how we should stabilize new features. 18:06 MTDiscord The other meta-question is whether we should put it on the 5.17.0 milestone. On my end, I think it'll likely be ready for 5.16.0 already, but there's no rush. 18:06 SFENCE Will it be a problem to fix a bug if it will not be marked as experimental? 18:06 Krock Seeing just the statistics of +1888 lines makes me wonder whether whether we couldn't have it expanded incrementally? 18:07 Krock The point of "experimental" is from how I'd understand it to justify breaking changes. 18:07 MTDiscord Yes, to be able to correct API misdesign (which would be a bit of a stretch to call a bug) 18:08 MTDiscord For example, had I not gotten some valuable feedback on Euler angles, I might've made XYZ the standard and this would've been nasty. 18:08 SFENCE Oh. So, than it takes sence. Can we use same method to mark it as experimental as we use for deprecated functions? 18:09 Desour print a warning every time the api is used? 18:09 Desour meh 18:09 SFENCE First time only. 18:09 MTDiscord I think a short note in the docs should be enough. We should probably also explain what "experimental" and "deprecated" means at the top of lua_api.md. 18:10 MTDiscord There are models where you would require users to explicitly opt in, say with a mod.conf flag, but I don't really want to increase the friction to reduce the pool of potential users even further. 18:10 MTDiscord I don't expect to be changing a lot about the APIs once I'm done addressing the reviews. 18:10 SFENCE I am afrad, user will easy miss that in doc, if it will not be mentioned for every function standalone. 18:12 Krock **THIS API IS EXPERIMENTAL. EXPECT BREAKAGES UNTIL THE REMOVAL OF THIS NOTICE** <-- should be plenty 18:13 MTDiscord can we automatically remove that once those APIs haven't been updated in a few years 18:13 SFENCE Should be. But user will be primary checking function parameter and returns values, not API description I assume. 18:13 MTDiscord Both rotations and matrices have a common section in the docs the user is expected to read, repeating that for every function would be quite verbose. 18:14 MTDiscord frog: yes, the plan is to remove them relatively soon even, maybe after half a year. 18:14 SFENCE Well. Than it shoudl be enough. 18:16 MTDiscord Okay. So, about the milestone. Is everyone fine with 5.17.0? 18:17 Krock fine by me 18:18 SFENCE I think, as experimental think, it can be in 5.16.0 also, if you get approval before feature freeze. 18:19 MTDiscord Hmm yes. I'll try to get that. 18:20 MTDiscord Unless anyone has any thoughts on the implementation or API design to discuss right now, we can move on to #16839. 18:20 ShadowBot https://github.com/luanti-org/luanti/issues/16839 -- Node param2 bitfield by sfence 18:21 Krock oh, and the matrix/rotation PR might also benefit from some more tests 18:22 MTDiscord sure 18:22 MTDiscord i plan to make some in-world tests that demonstrate that the APIs are consistent with object rotations if used properly 18:22 MTDiscord i could also do the same for bone overrides 18:23 Krock about 16839 (bitfield): What again were the benefits? To add drawtypes more easily? 18:24 Desour Krock: rather to add paramtype2s more easily, and to avoid the combinatorial explosion 18:25 SFENCE luatic: You can use devtest mods testlookdir from #14231, I used for verifiing calcualtion of look vector in different ways.. 18:25 ShadowBot https://github.com/luanti-org/luanti/issues/14231 -- Fix camera to follow player eyes when player is attached by sfence 18:25 MTDiscord I like the idea of the PR, right now I'm wondering whether there might be a better way for a long-term solution. 18:25 MTDiscord SFENCE: I'll take a look at that, thanks 18:26 Desour I think there are only few types of paramtype2s: rotation (facedir, wallmounted, 4dir, degrotate), level (flowingliquid, level, glasslike liquid level (it's drawtype dependent)), color, and modifying what should be nodedef (meshoptions) 18:26 MTDiscord I think the extent to which we're squeezing things in a single byte (param2) is silly, and I feel like it should not be terribly hard to lift that constraint. 18:27 Krock currently, a node is 4 bytes big. The next size would be 8 bytes, effectively doubling the RAM usage of the mapblocks held in memory 18:27 Desour (what is CPT2_FULL?) 18:27 SFENCE Krock: primary to makes adding new param types more easy and allow mod developers to better optimalize usage of param2 bits. 18:28 MTDiscord Krock: Not necessarily. We can store a potential "param3" out-of-band as byte array. 18:29 MTDiscord This also lets us make this very low cost if not used. 18:29 Krock surely that would need some effort to not run out of sync by accident 18:29 MTDiscord Related: Mapblock meta, #16125 (I call this "dense auxiliary data") 18:29 ShadowBot https://github.com/luanti-org/luanti/issues/16125 -- Add Mapblock meta 18:30 MTDiscord Krock: Well yes, but I think we already have all the necessary abstractions 18:30 Krock (i.e. all node getter and setter functions would have to use MapNode2 instead of MapNode to carry over any additional param data 18:30 Krock ) 18:31 MTDiscord something like that, sure 18:31 MTDiscord though i'm also somewhat fine with keeping this separate-ish, with the onus on the modder to manage it properly 18:31 SFENCE Krock: CPT2_FULL looks like some residuum from past... 18:31 Krock ^ Desour 18:32 MTDiscord which e.g. metadata basically is (which arguably has led to a few bugs where modders have forgotten to clean it up) 18:34 Desour I'd like to have an abstraction over node meta/param2, where the engine is free how to store it (i.e. how dense): specify in the node def the types (e.g. node has a u32 field "mymod:foo"), if there are many of these nodes in a block, the engine can store it dense. otherwise with a hashtable. in the serialized mapblock it would store the format (like with the name id mapping). then there needs to be a way to handle db with current format mismatches 18:36 Desour I might have described it somewehre else already. should I open another issue? 18:36 MTDiscord probably a good idea 18:37 Krock About the param2 PR: I think this has a benefit when constructing param2 values from within a mod, such that value ranges can be handled more intuitively (i.e. have helper functions to dis- and reassemble the rotation and color information based on the drawtype 18:37 Krock s/drawtype/param2type 18:37 Krock However, I would not be yet in favour of making this dynamic 18:38 Krock the PR does not make it dynamic either - otherwise there would be plenty of bit shifting going on 18:39 MTDiscord well the PR is a draft, but the bit shifting is abstracted by ParamBits right 18:39 SFENCE bit shifting is already used for reading values from param2, this will not be a difference 18:39 SFENCE it is still one shift, nad one AND... only not with constant values 18:40 Krock depending on the bit width for facedir, you might have all 24 rotations available or just 8... 18:41 Desour being able to lower the amount of bits, or to overlap them, is a feature 18:42 SFENCE Yes... because actually we have param2type 4dir, color4dit, facedir, colorfacedir... so with this PR I found that 4dir and facedir can be merged, as it is same baviors, only top bit always 0 for 4dir 18:43 Krock I don't think the same values for "facedir" result in the same "4dir" rotation, though. 18:43 Krock yes, the upper bits would be zero due to missing width, but also the relevant rotation code would be different 18:43 SFENCE same rotation function is used in code for visual 4dir, what I saw 18:43 cx384 Regarding param2, imo a bitfield alone is too restrictive it would be better to make it more flexible and let the server send some kind of code (like bpf?) to create new drawtypes, that can use parem2, position dependent random numbers, adjacent nodes, ... to change the mesh, rotation, texture mapping, ... 18:43 MTDiscord Haha, yes it's been brought up 18:44 MTDiscord The best plan I've seen is node metadat 18:44 MTDiscord Krock: hmm i feel like it would work out just fine. the upper bits are the axis in facedir, so you would get Y+ axis (same as 4dir), and then the low 2 bits are just the rotation around that? 18:44 cx384 But I guess it's too far away for now. The main problem with simper solution is the combinatorial explosion. 18:44 MTDiscord cx384: yes yes, eventually we want meshgen to be hookable by SSCSM. 18:44 SFENCE Krock: also testing in devetest show, that mergind facedir with 4dir does no visual difference.... but if it is a problem. I can separate it again 18:45 MTDiscord That allows graphical flexibility, because you can have arbitrary amounts of data in node metadata, just would need to store it per mapblock if we don't right now. 18:45 Krock SFENCE: not quite. 4dir values are postprocessed in MapNode::rotateAlongYAxis, CPT2_4DIR 18:46 Desour we could wait with the bitfield pramtype2 thing until we have dehardcoded meshgen in other ways (i.e. programmable via sscsm) 18:46 Desour or is it urgent? 18:46 MTDiscord ExeVirus: hmm? node metadata is stored per mapblock, but there currently is no such thing as mapblock metadata (hence the issue i linked) 18:46 Krock SFENCE: eh no sorry. Ignore my comment. Yes. They indeed seem compatible. 18:48 SFENCE So, can I continue on it in this way or should I do same changes? 18:50 Krock If I were to continue the PR, I'd focus on Lua <---> Bitfield conversion functions for the known types first and then make them dynamic. I'll leave a few comments in your PR. 18:50 SFENCE Thatconversion is already done. 18:50 SFENCE check register.lua in PR 18:52 MTDiscord All good, wasn't sure if we had a global node meta or if it was already per mapblock, that's all I was after 18:52 SFENCE will require little changes, but logic will keep same I assume 18:52 Krock That's not what I meant. Writing up and exmaple .... 18:52 MTDiscord Personally I think the way that PR looks might be influenced greatly by the existence of more than param2, which we will probably want soon (TM) 18:52 Desour SFENCE: you could also just make it an internal c++ side change first 18:54 Krock SFENCE: https://pastebin.com/GGdadeL3 18:54 MTDiscord if you'll excuse me, i need to take a break for a minute 18:55 SFENCE Krock: It is in lua_api.md mentioned, as it can look in node def.. paramtype2 will be text, old behaviors or, table with tables, new behaviors 18:56 MTDiscord https://github.com/luanti-org/luanti/pull/16839/changes#diff-c60ce2a4d38acfedec97ac1b19e9e207aa60f223f1b7fdd1048c00bdf1f8d5d9 18:57 Desour Krock: would turn it into {rotation = {kind = "facedir", value = 2}, color = 3} 18:59 SFENCE but now, no reader of that is prepared... I want to know it can looks like this, before implementing all needed changes to code 18:59 Krock Desour: you could argue that there might be another kind of "color" too, somewhen. Thus I kept it stupid simple. 19:00 SFENCE based on prevous discussion, I make it minimal, just to chect principe and style 19:01 Desour Krock: the thing is, if you want to rotate your node, you'd otherwise have to check for facedir, wallmounted, ... in sequence, whereas with this you could have a switch-case (or in lua func_table[v]()) on the one value. it scales better 19:02 Desour and rotation paramtype2s should be exclusive, or you need to define how they interact with each other 19:04 Desour ... hm, being able to combine degrotate with wallmounted would be neat though. so maybe allowing combination would be better. idk 19:04 Krock hehe 19:04 Krock it ain't that simple 19:05 MTDiscord at some point we're going into "oddly specific feature" territory again... 19:05 Krock Oddly specific features are exactly why we have different drawtypes 19:05 Krock excuse me. paramtype2 19:06 MTDiscord i mean yes-ish, but it doesn't scale super well, does it? 19:06 Desour no no, "drawtypes" was right 19:06 Krock With something like SFENCE's PR, we'd have it more generic. New features would still need engine adjustments 19:07 Krock it surely covers what we currently have - question is what comes next 19:07 MTDiscord well it is an extension of what we currently have, right 19:07 MTDiscord because you can decide how precisely to allocate bits 19:08 MTDiscord i just think the utility is unfortunately limited by the fact that there are only a whopping 8 bits to allocate 19:08 Krock right. On a per-node-registration basis. 19:09 MTDiscord so i feel like doing this PR optimally depends, on some extent, on knowing how SSCSM 19:09 MTDiscord ah dang i sent that prematurely 19:10 Krock fortunately, appending after sending is easier than truncating 19:10 MTDiscord yeah but i was also rewording :p 19:10 MTDiscord doing the extension optimally depends on knowing (1) how the SSCSM meshgen dehardcoding will look like and (2) how our extension to node data will look like (mapblock meta, param3, whatcha call it) 19:12 MTDiscord we could probably agree on some medium-term extensions, and then the PR could be made under the assumption that they will happen 🤷 19:13 MTDiscord for example, if we decide to extend the value range of param2 (say, we allow 16-bit or even 32-bit param2), the design of this PR would apply nicely to that. 19:18 SFENCE Just can not imagine different stile of extending param2 then increasing bit width... 19:20 MTDiscord well, suppose for example we were to add a param3 as a separate field that is stored out of band 19:21 SFENCE then it will not affect param2, or there will be extra code withc combine param3 and param2 to 16bit/ 32bit number.. so nothing will change I suppose? 19:22 MTDiscord well yes, but you would want to use param3 for these kinds of APIs, for example you would like to be able to say "use param2 for color, use param3 for degrotate" 19:23 Krock The chaotic evil approach would be to malloc() the mapblock as raw bytes and have it cast to MapNode (packed attribute) at the desired offset. 19:23 MTDiscord so then either the API would need to be extended to allow referencing param3, or param2 and param3 would need to be packed together as you say (which is basically just a param2 extension in a trenchcoat / an implementation detail of doing such an extension then) 19:24 MTDiscord so what i'm saying is: the design of this PR influences, and is influenced by, how we decide to extend the space of possible auxiliary node params. 19:25 Krock (.. and pray that all architectures allow that hackery. It might be necessary to memcpy if the address is not padded to 4 byte steps) 19:25 SFENCE in that case, we just combine param3 and param2 to one value and read from it... 19:26 SFENCE only documentation will say to use top bites for param3 19:27 MTDiscord SFENCE: well yes, that would be one likely influence on how we decide to make the extension. is it a good influence? i don't know. 19:27 MTDiscord though so far it seems to me like an (opt in) param2 extension would work okay as a medium-term solution. 19:28 MTDiscord i figure the current design is fine, provided we can agree on effectively extending the space of param2 (opt-in) as a short-term solution 👍 19:29 Krock also extend param1 while we're at it to allow colored light 19:30 Krock Anyway. Are there more PRs to discuss? 19:30 SFENCE if there will be same big change not compatible with jsut bit width extend, it will require big update anyway 19:30 MTDiscord sfan5 wanted #16697 to be discussed 19:30 ShadowBot https://github.com/luanti-org/luanti/issues/16697 -- [no squash] Make static world lighting (light curve & AO) configurable via API by sfan5 19:31 MTDiscord "yes/no?" 19:32 MTDiscord from a quick look, seems like reasonable dehardcoding to me. 19:33 SFENCE This will be probalby usage for same special games. But if I remember well, somebody asked for feature like this. 19:33 Krock Concept-wise this seems fine by me. Night-vision goggles, for example- 19:34 Krock But wasn't there already a light-related API? 19:35 MTDiscord not a huge fan of the fact that we have to touch all mapblock meshes to fix the vertex colors, but that's just the way the engine works at the moment. 19:35 MTDiscord in the future we might want to move that to the shaders with custom vertex attributes. 19:35 MTDiscord (we need to separate light and color anyways: this was what killed the ambient light PR) 19:35 Krock I remember that set_lighting -> exposure already allowed similar tricks 19:36 SFENCE PR looks liek it is per player setting.. so it should not change data on server side in mapblocks 19:36 MTDiscord notably there's also #14091 by SFENCE 19:36 ShadowBot https://github.com/luanti-org/luanti/issues/14091 -- API for light intensity and color at night and day by sfence 19:37 MTDiscord but these are different parameters, i don't see a direct conflict 19:40 Krock With the exposure parameters I honestly don't see too much use for the light curve PR. Changing between the old and new curve gives a nice touch, but is not important to me. 19:43 MTDiscord 🤷 19:44 MTDiscord indeed most users probably just want relatively simple effects (make everything darker / lighter, that kind of thing), so it would probably be a bit niche 19:45 Krock to be fair - this is currently the most direct/generic way to change the appearance, which is probably the best solution. I just don't see much use for it that couldn't be covered with the exposure parameters. 19:48 SFENCE Making thinks lighter can be really helpfull.. I have partially sighted friend. He is now playing wit localy edited shaders, which result in different light curve.. so, he see longer then to 3 nodes with torch 19:56 MTDiscord Alright so any more thoughts on that PR? 19:58 Krock enjoy the silence 19:59 MTDiscord Personally I will probably prioritize sfence's PR when it comes to reviewing, if it is rebased, because the APIs there seem less niche to me. 20:00 MTDiscord Separate topic for later: #15451 20:00 ShadowBot https://github.com/luanti-org/luanti/issues/15451 -- [no sq] Make Luanti buildable with ANGLE for macOS, iOS and iPhoneSimulator and runnable on iPhoneSimulator by sfence 20:02 MTDiscord Sure. If there are no objections, I'd like to move on to #16921 for the moment. 20:02 ShadowBot https://github.com/luanti-org/luanti/issues/16921 -- Add 2d, maybe 4d vectors to Lua API 20:02 MTDiscord Basically: 2d vectors, yay or nay 20:03 lhofhansl QQ: Should I expect the hwbuffer count (in use) to be much (about 10x) higher than the number of loaded meshes (no objects in this case). 20:03 MTDiscord Yay from me. More options is good, and there are verifiable usecases 20:04 MTDiscord lhofhansl: well, meshes often have multiple buffers 20:05 Krock @luatic: Wouldn't the need for 4D vectors almost disappear once the 4x4 matrix PR gets though? That already allows vector manipulations and rotations 20:05 SFENCE From a discussion under issue, 2d/4d vectoprs looks reasonable ot have. 20:06 Krock as for 2D ... those should be rather trivial to implement - yet - they're not used in too many places. 20:06 MTDiscord Krock: well, especially with a 4d matrix, you might want 4d vectors to work on would be another way of viewing it 20:07 MTDiscord Matrixes are often multiplied by 1x4 vectors. Also quaternions are essentially 1x4s 20:08 MTDiscord well quaternions will be covered by the Rotation API 20:08 Krock how are mods doing it currently? Are there none that need it, or are they implementing matrixes and vector operations themselves? 20:08 MTDiscord Themselves 20:08 MTDiscord This is basically a free feature that standardizes the implementation and is convenient 20:09 MTDiscord I agree 20:10 Krock I was mostly wondering because transformations of entity rotations and attached entities are handled entirely on C++ side, without much need to manipulate vectors in Lua 20:11 Krock and other use-cases currently don't come to my mind 20:11 MTDiscord ?? Games and mods manipulate vectors in Lua all the time. Theres a reason the vector api exists 20:11 MTDiscord I can show you some once I'm at a proper keyboard in a couple minutes 20:12 Krock sorry, I meant manipulating using matrices 20:14 MTDiscord Ah. Less common but if its low cost to implement it is helpful to have for a few people. It also paves the way for the future, such as client side handling 20:14 Krock vector.add/subtract and so on is used in plenty occasions, I'm aware of that. Rotations however are to my knowledge mostly used on entities, which currently allow offset + rotation. 20:16 Desour rotation is also required for nodes, e.g. tube goes in forward, where is forward with this param2? 20:16 Desour having rotation helpers is definitely too useful not to add these helpers 20:17 Krock for that a LUT + vector.add already suffices, no matrices needed (although it could be implemented with them too) 20:17 Desour and who gives you the LUT? 20:18 Krock core.facedir_to_dir or similar 20:18 Desour and how do you rotate a facedir? 20:19 Desour I agree that the matrix api in the PR not really suitable for node rotations though. I'd prefer something like my rotnums https://desour.codeberg.page/dslib/modules/dslib:rotnum.html 20:20 Krock hehe. good question. Indeed, for that you'd currently have to fall back to core.yaw_to_dir or so 20:22 MTDiscord Krock: one example would be turrets. the barrel should track a target. this requires proper rotation interpolation so you don't rotate too fast (want to give players a chance to dodge). at a given rate, you fire. this requires the ability to apply the rotation to a vector. 20:24 MTDiscord there are a couple similar cases where people need to compute the rotations they apply to objects or bone overrides 20:24 MTDiscord and really, i want to stop people from committing crimes with Euler angles 20:25 MTDiscord We're getting a bit into the weeds here. I think we can conclude the regular part of the meeting at this point? 20:26 Krock sure. Thanks for the explanations. 20:26 MTDiscord So let's get to #15451 now. ping @greenxenith SFENCE 20:26 ShadowBot https://github.com/luanti-org/luanti/issues/15451 -- [no sq] Make Luanti buildable with ANGLE for macOS, iOS and iPhoneSimulator and runnable on iPhoneSimulator by sfence 20:27 SFENCE here 20:27 MTDiscord o/ 20:28 SFENCE From my side, it only waiting for another review 20:28 SFENCE I want to keep this simple, next think I wants to do with PR which will follow. 20:29 MTDiscord i can probably give you a pro forma review, but be warned that i'm not at all familiar with the apple platform specifics and own no apple hardware 20:29 Krock I did not review this PR because I don't have a setup to test it 20:29 MTDiscord I do own Apple hardware (specifically for this PR) and have verified that it works. Plenty of issues to resolve, but the point of the PR is to make it buildable, which it is. 20:31 MTDiscord i think the PR is awesome not only because it extends builds to iOS, but also because of the ANGLE part which means we get to use OpenGL 3 on apple 20:31 SFENCE From core dev, only I have HW to test it, I think. It nothing has changed. 20:32 MTDiscord I think a pro forma review or 2 would be fine, those still have value to check quality and consistency 20:34 Krock I'll dig through the PR to check whether there's something to improve style-wise 20:44 Desour btw, I've written the typed meta stuff into an issue now: #16950 20:44 ShadowBot https://github.com/luanti-org/luanti/issues/16950 -- Typed node meta (tmeta) 20:44 MTDiscord Good. I'll take a look at the iOS + ANGLE PR after Krock. I'll be having dinner now. 20:45 MTDiscord Thanks Krock, luatic.. I also have to go. By