| Time |
Nick |
Message |
| 00:21 |
|
crazylad joined #luanti-dev |
| 02:39 |
|
crazylad joined #luanti-dev |
| 04:27 |
|
AliasStillTaken joined #luanti-dev |
| 05:00 |
|
MTDiscord joined #luanti-dev |
| 05:27 |
|
MTDiscord1 joined #luanti-dev |
| 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 |
| 09:22 |
|
Warr1024 joined #luanti-dev |
| 09:47 |
|
Warr1024 joined #luanti-dev |
| 10:21 |
|
YuGiOhJCJ joined #luanti-dev |
| 11:01 |
|
alek13 joined #luanti-dev |
| 11:05 |
|
SFENCE joined #luanti-dev |
| 11:12 |
|
alek13_ joined #luanti-dev |
| 11:35 |
|
SFENCE joined #luanti-dev |
| 11:39 |
|
SFENCE joined #luanti-dev |
| 13:08 |
|
SFENCE joined #luanti-dev |
| 14:33 |
|
Desour joined #luanti-dev |
| 15:09 |
|
Eragon joined #luanti-dev |
| 15:13 |
|
Eragon_ joined #luanti-dev |
| 15:25 |
|
AliasAlreadyTake joined #luanti-dev |
| 17:31 |
Krock |
Meeting in 30 minutes or so. Thanks to @luatic for arranging that ;) |
| 17:55 |
|
SFENCE joined #luanti-dev |
| 17:55 |
|
luatic_ joined #luanti-dev |
| 18:00 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> We could probably remove the "experimental" note after 2 or 3 versions have released with nobody complaining. |
| 18:04 |
MTDiscord |
<luatic> This ties into the broader question of whether we should mark things experimental more, and how we should stabilize new features. |
| 18:06 |
MTDiscord |
<luatic> 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 |
<luatic> Yes, to be able to correct API misdesign (which would be a bit of a stretch to call a bug) |
| 18:08 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<et086> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> Okay. So, about the milestone. Is everyone fine with 5.17.0? |
| 18:17 |
|
cx384 joined #luanti-dev |
| 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 |
<luatic> Hmm yes. I'll try to get that. |
| 18:20 |
MTDiscord |
<luatic> 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 |
<luatic> sure |
| 18:22 |
MTDiscord |
<luatic> i plan to make some in-world tests that demonstrate that the APIs are consistent with object rotations if used properly |
| 18:22 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> Krock: Not necessarily. We can store a potential "param3" out-of-band as byte array. |
| 18:29 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> something like that, sure |
| 18:31 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<exe_virus> Haha, yes it's been brought up |
| 18:44 |
MTDiscord |
<exe_virus> The best plan I've seen is node metadat |
| 18:44 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<exe_virus> 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 |
<luatic> 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 |
<exe_virus> 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 |
<luatic> 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 |
<luatic> 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 |
<sfence> https://github.com/luanti-org/luanti/pull/16839/changes#diff-c60ce2a4d38acfedec97ac1b19e9e207aa60f223f1b7fdd1048c00bdf1f8d5d9 |
| 18:56 |
|
imi joined #luanti-dev |
| 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> well it is an extension of what we currently have, right |
| 19:07 |
MTDiscord |
<luatic> because you can decide how precisely to allocate bits |
| 19:08 |
MTDiscord |
<luatic> 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 |
<luatic> so i feel like doing this PR optimally depends, on some extent, on knowing how SSCSM |
| 19:09 |
MTDiscord |
<luatic> ah dang i sent that prematurely |
| 19:10 |
Krock |
fortunately, appending after sending is easier than truncating |
| 19:10 |
MTDiscord |
<luatic> yeah but i was also rewording :p |
| 19:10 |
MTDiscord |
<luatic> 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:11 |
|
SFENCE joined #luanti-dev |
| 19:12 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> though so far it seems to me like an (opt in) param2 extension would work okay as a medium-term solution. |
| 19:28 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> "yes/no?" |
| 19:32 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> in the future we might want to move that to the shaders with custom vertex attributes. |
| 19:35 |
MTDiscord |
<luatic> (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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 🤷 |
| 19:44 |
MTDiscord |
<luatic> 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 |
<luatic> Alright so any more thoughts on that PR? |
| 19:58 |
Krock |
enjoy the silence |
| 19:59 |
MTDiscord |
<luatic> 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 |
<greenxenith> 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:01 |
|
lhofhansl joined #luanti-dev |
| 20:02 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<greenxenith> Yay from me. More options is good, and there are verifiable usecases |
| 20:04 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<greenxenith> Matrixes are often multiplied by 1x4 vectors. Also quaternions are essentially 1x4s |
| 20:08 |
MTDiscord |
<luatic> 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 |
<greenxenith> Themselves |
| 20:08 |
MTDiscord |
<greenxenith> This is basically a free feature that standardizes the implementation and is convenient |
| 20:09 |
MTDiscord |
<luatic> 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 |
<greenxenith> ?? Games and mods manipulate vectors in Lua all the time. Theres a reason the vector api exists |
| 20:11 |
MTDiscord |
<luatic> 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 |
<greenxenith> 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 |
<luatic> 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 |
<luatic> there are a couple similar cases where people need to compute the rotations they apply to objects or bone overrides |
| 20:24 |
MTDiscord |
<luatic> and really, i want to stop people from committing crimes with Euler angles |
| 20:25 |
MTDiscord |
<luatic> 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 |
<luatic> 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:26 |
|
SFENCE joined #luanti-dev |
| 20:27 |
SFENCE |
here |
| 20:27 |
MTDiscord |
<greenxenith> 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 |
<luatic> 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 |
<greenxenith> 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 |
<luatic> 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 |
<greenxenith> 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 |
<luatic> Good. I'll take a look at the iOS + ANGLE PR after Krock. I'll be having dinner now. |
| 20:45 |
MTDiscord |
<sfence> Thanks Krock, luatic.. I also have to go. By |
| 20:58 |
|
SFENCE joined #luanti-dev |
| 21:32 |
|
SFENCE joined #luanti-dev |
| 22:44 |
|
SFENCE joined #luanti-dev |
