| Time |
Nick |
Message |
| 00:07 |
|
Juri joined #luanti-dev |
| 00:07 |
|
Niklp joined #luanti-dev |
| 01:21 |
|
fluxionary_ joined #luanti-dev |
| 02:03 |
|
aliasstilltaken joined #luanti-dev |
| 02:08 |
|
v-rob_ joined #luanti-dev |
| 03:00 |
|
aliasalreadytake joined #luanti-dev |
| 03:59 |
|
SFENCE_arch joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 04:41 |
|
v-rob_ joined #luanti-dev |
| 04:46 |
|
v-rob joined #luanti-dev |
| 05:32 |
|
SFENCE_arch joined #luanti-dev |
| 06:28 |
|
v-rob joined #luanti-dev |
| 06:39 |
|
v-rob joined #luanti-dev |
| 07:02 |
|
nekobit joined #luanti-dev |
| 07:38 |
|
nekobit joined #luanti-dev |
| 08:22 |
|
Warr1024 joined #luanti-dev |
| 08:47 |
|
Warr1024 joined #luanti-dev |
| 08:47 |
|
imi joined #luanti-dev |
| 09:57 |
|
ivanbu joined #luanti-dev |
| 10:52 |
|
nekobit joined #luanti-dev |
| 12:02 |
|
pgimeno joined #luanti-dev |
| 12:16 |
|
SFENCE joined #luanti-dev |
| 12:36 |
|
SFENCE joined #luanti-dev |
| 13:00 |
|
SFENCE joined #luanti-dev |
| 13:30 |
|
SFENCE joined #luanti-dev |
| 14:05 |
|
SFENCE joined #luanti-dev |
| 14:14 |
|
turtleman joined #luanti-dev |
| 16:38 |
|
cx384 joined #luanti-dev |
| 16:58 |
|
imi joined #luanti-dev |
| 17:00 |
|
v-rob joined #luanti-dev |
| 17:56 |
Krock |
Meeting in 3 minutes. https://docs.luanti.org/for-engine-devs/meetings/#2025-06-15 |
| 17:56 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/2025 -- Fix documentation for string operations. by kaeza |
| 17:57 |
Krock |
thanks ShadowBot. Very helpful. |
| 18:00 |
SFENCE_arch |
I am here. |
| 18:00 |
Krock |
Pinging those who reacted to the meeting announcement. cx384 sfan5 y5nw @luatic |
| 18:00 |
Krock |
hello :) |
| 18:01 |
cx384 |
hi |
| 18:01 |
Krock |
waiting two minutes for people to notice the ping |
| 18:01 |
MTDiscord |
<luatic> i am in front of my computer but the sunburn is setting in |
| 18:02 |
|
Desour joined #luanti-dev |
| 18:03 |
Krock |
ouch. that sucks. I hope it's not too intense. |
| 18:03 |
Krock |
> Is it important that passwords are not stored excessively long in plain text in memory? [...] |
| 18:03 |
Krock |
#14196 #14129 |
| 18:03 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/14196 -- Change the way how password is stored in C++ engine. by sfence |
| 18:03 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/14129 -- Add transfer_player function to request client move to new server by sfence |
| 18:06 |
Krock |
If a process gains access to program memory, then you've got more important issues. I think the main argument here could be to ensure nothing too bad happens in case of a CVE where the server could abuse a bug in the client. |
| 18:07 |
SFENCE_arch |
14196 PR has been created in reaction to comment from @luatic under 14129. I do not understand much the security in SW. |
| 18:08 |
MTDiscord |
<luatic> I will say that at the time of making that comment, I was not aware of the effort required to implement this. |
| 18:09 |
MTDiscord |
<luatic> But still it doesn't seem like a bad idea to me. The new code is mostly separate, this shouldn't add much maintenance burden. |
| 18:09 |
Krock |
the LoC statistics are slightly biased too, due to the license header of two new files. In general it does seem to isolate the auth-related code better from the existing files |
| 18:09 |
MTDiscord |
<luatic> And passwords are sensitive data and worth protecting especially as users might - even though they should not - reuse them. |
| 18:10 |
SFENCE_arch |
So, should we afk #sfan5 to remove change request from 14196, and @luatic will review it? |
| 18:10 |
Desour |
>If a process gains access to program memory |
| 18:10 |
Krock |
I also have a few comments on there; yet not submitted. I think we can continue this PR |
| 18:10 |
Desour |
read access* |
| 18:11 |
Krock |
Desour: read or write does not matter. it's both the same restrictions |
| 18:11 |
Desour |
other things an attacker could read are private info, like paths |
| 18:12 |
Desour |
it does matter. if an attacker has write access, then you certainly have bigger worries. but if it's just read access... |
| 18:12 |
sfan5 |
I don't plan to review 14196 further btw |
| 18:12 |
sfan5 |
also hi |
| 18:12 |
MTDiscord |
<luatic> sure, i'll try to find time for it |
| 18:13 |
SFENCE_arch |
sfan5: So, cna you remove change request, so somebody else can review, approve and merge? |
| 18:13 |
sfan5 |
sure just remove the label |
| 18:15 |
SFENCE_arch |
Ok, i will rebase it. |
| 18:17 |
Krock |
hmm. aren't we supposed to use the official "srp.cpp" file? |
| 18:17 |
Krock |
or has it been modified too much to be drop-in compatible in case of updates? |
| 18:18 |
Krock |
asking because I'm currently looking through that PR and there's a few non-trivial changes to that file |
| 18:18 |
Desour |
according to the copyright header, it comes from est31: https://github.com/est31/csrp-gmp |
| 18:18 |
Desour |
and this upstream hasnt changed since 9 years |
| 18:19 |
MTDiscord |
<luatic> yeah i think luanti has always rolled its own crypto? |
| 18:19 |
MTDiscord |
<luatic> (w.r.t. SRP) |
| 18:19 |
SFENCE_arch |
We already did changes to srp.cpp file. |
| 18:19 |
Desour |
but est31's is a based on https://github.com/cocagne/csrp , which has changes |
| 18:20 |
|
btcgiveaway joined #luanti-dev |
| 18:20 |
MTDiscord |
<luatic> looking at those changes most don't seem very meaningful |
| 18:21 |
MTDiscord |
<luatic> at least the recent ones |
| 18:21 |
MTDiscord |
<luatic> we should probably take a closer look though |
| 18:22 |
Krock |
So the question is answered, I presume. Continue 14196. |
| 18:23 |
Krock |
proceeding with the next topic in a minute if there are no objections |
| 18:24 |
Krock |
> The original author of #13811 introduced a class BitField -> see here. If we like this class [...] |
| 18:24 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/13811 -- [no squash] Add node texture variants by sfence |
| 18:24 |
Krock |
"here" = https://github.com/luanti-org/luanti/pull/13811/files#diff-2be35250aa71dc4852f4955c67e13cabe131c20b7373cc92385484b391aa8f62 |
| 18:25 |
SFENCE_arch |
That class can replace param2 types strings in node definitions. |
| 18:25 |
MTDiscord |
<luatic> That utility seems useful, but BitField feels like a misnomer. I'd be inclined to call it something like "BitView". It is after all essentially a view into a bunch of bits. |
| 18:25 |
Krock |
BitViewSetter because it also can set bits :P |
| 18:26 |
MTDiscord |
<luatic> Or "BitSlice" maybe, you get the idea. Maybe also put the reference to the value into the class. |
| 18:26 |
Krock |
but why are we reinventing structs with bitfields? |
| 18:27 |
Krock |
* packed structs with bitfields |
| 18:27 |
Desour |
because it's dynamic, probably |
| 18:28 |
MTDiscord |
<sfence> Now paramtype2 has to accept string keys for all posible combinations of parameters stored in param2. We can add more and more paramtype2 keys, or replace it by some more flexible way for moders. |
| 18:28 |
Krock |
there's at maximum as many as there's paramtype2 types |
| 18:29 |
Krock |
I'm afraid that read_bitfield_parts/push_bitfield_parts could perform rather badly if used carelessly |
| 18:30 |
Krock |
reference to the C++ -> Lua optimizations where the values were pushed as arguments to Lua such that it could perform optimizations. This isn't possible as long the data type is an entire table |
| 18:31 |
SFENCE_arch |
We can have some check if bit areas are in allowed range and do not overlap. |
| 18:31 |
MTDiscord |
<luatic> The entire paramtype2 situation is one of those "it's a mess but a proper solution is not feasible short term"... |
| 18:32 |
cx384 |
I generally don't like how the node texture variants are implemented in this PR. |
| 18:32 |
cx384 |
Instead I would prefer tile modifier (also for param2 conditions), like I proposed in https://github.com/luanti-org/luanti/issues/15203 |
| 18:33 |
SFENCE_arch |
So, the best way now is probaly to just add more paramtype2 keys in #13811 |
| 18:33 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/13811 -- [no squash] Add node texture variants by sfence |
| 18:34 |
Krock |
> <Desour> because it's dynamic, probably |
| 18:35 |
Krock |
I see, yes. Some paramtype2' share the same property but do not have the same bit count for e.g. rotations or color |
| 18:36 |
Krock |
In that regard, such class could be more helpful, e.g. when using a LuT to retrieve the bit offset and width of a specific (let's say) property |
| 18:36 |
Krock |
after thinking over this a bit, I think having a BitField class (or however one may want to call it) can be helpful. ofc, this also needs unittests tests. |
| 18:37 |
Desour |
IIRC, the idea is that you, as a modder, give for each paramtype2 an offset and width, and the engine uses that to get the value from param2. so we don't have hardcoded combinations (like colorfacedir) anymore |
| 18:38 |
SFENCE_arch |
cx384: Looks like 15203 attempt to fix different problem than 13811. |
| 18:38 |
MTDiscord |
<luatic> it should also not be in numeric.h, that header is already too bloated as is |
| 18:38 |
Krock |
I can see purposes outside of just node variants. -- Any other opinions on this particular helper class? |
| 18:38 |
Desour |
(dynamic as opposed to structs that you can't declare on runtime) |
| 18:38 |
SFENCE_arch |
Desour: Yes, it is idea behind. |
| 18:40 |
cx384 |
SFENCE_arch: It's API can be used to solve both problems and more. |
| 18:40 |
SFENCE_arch |
Krock: Now, you cannot limit nuber of colors in palette. You will have always 256 or 8 or 32, depend if colored is used with wallmounted, rotated or normal node. |
| 18:40 |
cx384 |
e.g. position depended textures |
| 18:41 |
Krock |
cx384: The feature request that you linked in a new concept that does not blend in very nicely with the generic tile API that is currently available. It's not entirely necessary to define conditions in the tiledef. They could as well be sent by the server when placing the node. Ofc, there woudn't be any visual prediction. |
| 18:43 |
Krock |
SFENCE_arch: there's only a specific amount of bits available - which is 8. Hence, a dynamic implementation wouldn't get you far. I think the benefit here is to potentially make the code more generic and understandable. |
| 18:43 |
Desour |
Krock: the client would need to store the selected tiles then, so it can always meshgen it |
| 18:44 |
SFENCE_arch |
cx384: but param2 allow players to select node with texture they wants. you can have one marble node with N textures/colors without needs to register N node for each stairs variant etc. And player will be able to place marble with wanted texture anyway. it will be probably very dificult to do with conditional textures. And also limited by neighbours nodes. |
| 18:44 |
Krock |
Desour: sorry, would you mind explaining a bit more what you mean by that? |
| 18:45 |
Desour |
Krock: you said that the server could send the selected tiledef on placement of a node |
| 18:46 |
Desour |
Krock: but that has to be transfared to meshgen somehow |
| 18:46 |
Krock |
Desour: no no. I meant that the server sends the param2 value anyway, and that would likely define which tile (or blend mode) it would pick |
| 18:46 |
Desour |
ah, ok |
| 18:47 |
cx384 |
SFENCE_arch: I already implemented this partly, and hopefully will make I PR soon. Maybe it will make more sense when you see it in action. |
| 18:47 |
SFENCE_arch |
luatic: now it is where it was in adpoted PR... if we decide to use it, I will try to create PR only for it soon. And apply ideas from this discusion. |
| 18:48 |
SFENCE_arch |
cx384: ok. |
| 18:50 |
MTDiscord |
<luatic> personally such a view seems useful to me |
| 18:50 |
Krock |
before you spend too much time, it might also be a good idea to write a "mockup" API concept beforehand to find out whether it's what people seem to want |
| 18:51 |
Krock |
oh nvm I thought you were referring to the node texture variants in the sentence "And apply ideas from this discusion." |
| 18:52 |
SFENCE_arch |
Krock: it was mean in case of creating separate PR for class BitField |
| 18:53 |
Krock |
okay. perfect. |
| 18:54 |
Krock |
Are there any other meeting PRs/issues that someone would like to discuss? |
| 18:55 |
MTDiscord |
<luatic> I wonder whether there are better ways to achieve backwards compatibility |
| 18:55 |
SFENCE_arch |
So to be clear, do I uderstand well that we want separate PR for class BitField (mey be with different name) as replacemnet for paramtype2 string keys in node definitions? |
| 18:56 |
MTDiscord |
<luatic> "Replacement" seems an odd term, it'd just be a utility to help us implement more flexible param2 types |
| 18:57 |
MTDiscord |
<luatic> but I'd say yes, this utility is worth having if executed well |
| 18:57 |
Desour |
paramtype2 = "p2type" | {w, o, "p2type", w, o, "p2type"} |
| 18:57 |
Desour |
^ would be a nice api, imo |
| 18:58 |
Desour |
(maybe with subtables) |
| 18:58 |
SFENCE_arch |
Ok. I expect that actual paramtype2 will be converted in Lua register_node function to bitfields in that case... |
| 18:59 |
SFENCE_arch |
subtables will be nice for this I belive. |
| 18:59 |
Krock |
SFENCE_arch: In a first iteration you could propose the struct/class and demo it with one drawtype. if it turns out to be nice to use, we can have a look at implementing it for other drawtypes too. |
| 19:01 |
Krock |
or just the struct/class with unittests. I don't care. |
| 19:01 |
SFENCE_arch |
Krock: ok |
| 19:02 |
Desour |
you could also start by not doing any lua api changes and just implement colorfacedir and co. in C++ with bitfields |
| 19:02 |
sfan5 |
fwiw i think we should keep a simple solution for the time being and go with ##13811 |
| 19:02 |
sfan5 |
##13811 |
| 19:02 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/13811 -- [no squash] Add node texture variants by sfence |
| 19:02 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/13811 -- [no squash] Add node texture variants by sfence |
| 19:03 |
sfan5 |
well wait |
| 19:03 |
sfan5 |
the param2_variant doesn't seem as simple as i thought |
| 19:03 |
SFENCE_arch |
sfan5: that PR actually include BitField class. |
| 19:03 |
sfan5 |
(did the PR change or was I just unaware?) |
| 19:04 |
SFENCE_arch |
Only rebased, not any big changes from my side to this moment. |
| 19:04 |
sfan5 |
I see |
| 19:04 |
sfan5 |
I thought it was a simpler reimplementation |
| 19:04 |
SFENCE_arch |
No it is adoption of original abnded PR. |
| 19:06 |
cx384 |
(SFENCE_arch: This is how the tile_modifier API will probably look like https://gist.github.com/cx384/df409b4021bdcfd1b74d3502697234c8 it's like a binary decision diagram.) |
| 19:06 |
SFENCE_arch |
cx384: So, it will be aslo able to use param2... nice :) |
| 19:07 |
sfan5 |
maybe we should go all the way and implement BPF for client side scripting 😎 |
| 19:07 |
sfan5 |
starting with arbitrary mini-programs to make mesh building decisions |
| 19:08 |
SFENCE_arch |
Client side scriptiong is optional because of security reasons? |
| 19:08 |
Krock |
what does BPF stand for? |
| 19:08 |
sfan5 |
https://en.wikipedia.org/wiki/Berkeley_Packet_Filter |
| 19:08 |
sfan5 |
linux uses it heavily to allow userspace to give the kernel mini programs to execute but safely |
| 19:08 |
MTDiscord |
<luatic> sfan5: which brings us right back to my initial point of "the proper solution is more work" 🙃 but yeah long term we'll need scriptable client meshgen |
| 19:09 |
sfan5 |
for example if you run tcpdump 'port 80 or (port 123 and net 1.0.0.0/8)' the latter program gets turned into BPF and actually executed in kernel space |
| 19:10 |
Krock |
uhm is this a new topic, or somehow related to node variants? |
| 19:10 |
Krock |
'cause I currently do not see any meaningful connection |
| 19:10 |
MTDiscord |
<luatic> Krock: I think cx384's proposal starts to resemble the beginnings of a programming language ;) |
| 19:11 |
Desour |
how hard would it actually be to support ebpf modding? is there a lib, or would we have to copy code from linux? x) |
| 19:11 |
Krock |
@luatic I'm afraid of that too |
| 19:12 |
cx384 |
there are not jumps (yet), so it is not turing complete, but it has a variable you can set, adjacent_nodes. |
| 19:12 |
sfan5 |
Krock: it's a half-serious proposal |
| 19:16 |
Krock |
mhm. It's one idea. Perhaps it can be of some use. Who knows. |
| 19:17 |
Krock |
As there's no new messages coming, I assume there's no other topic to discuss? Otherwise let's end it here to not drag it on for longer than needed. |
| 19:19 |
MTDiscord |
<luatic> fine by me |
| 19:25 |
Desour |
(to answer my question from before: I've found at least 2 bpf userspace vms https://github.com/eunomia-bpf/llvmbpf https://github.com/iovisor/ubpf ) |
| 19:36 |
Desour |
I'd like to propose a new label: @ Meshgen (idk if the @ makes sense). reason: we have so many issues and PRs about meshgen, and it's a relatively important and isolated part of the engine |
| 19:40 |
Krock |
most of the rendering part is related to meshgen, thus it would be mostly synonymous to "@ Client / Audiovisuals" |
| 19:40 |
Krock |
hmm. formspec has its own label, though. |
| 19:41 |
Desour |
with @ Client rendering * |
| 19:41 |
Krock |
since when does that exist? |
| 19:41 |
Desour |
idk |
| 19:41 |
Desour |
since long? |
| 19:42 |
Krock |
approx 2020. okay. |
| 19:42 |
Desour |
why does "@ Client / Audiovisuals" exist btw.? audio and visual are very different |
| 19:43 |
Krock |
such issues date back to 2014 |
| 19:49 |
sfan5 |
take this with a grain of salt but an interpreter only BPF implementation should be easy |
| 19:52 |
|
SFENCE joined #luanti-dev |
| 19:52 |
celeron55 |
i have tried to propose a BPF like thing since forever |
| 19:52 |
celeron55 |
so, +1 from me |
| 19:53 |
celeron55 |
(i've been talking about it in terms of physics, but graphics is fitting also) |
| 19:54 |
MTDiscord |
<luatic> Lua. |
| 19:54 |
Desour |
wasm. |
| 19:55 |
Desour |
wgsl (webgpu). |
| 19:55 |
sfan5 |
spir-v |
| 19:56 |
sfan5 |
anyway you could just have bpf program that get param0, param1, param2 as input and then from a fixed array of vertices, decides which ones to use |
| 19:57 |
sfan5 |
same for texturing |
| 19:57 |
celeron55 |
small lua environments would work just fine as BPF-like things |
| 19:57 |
celeron55 |
with very limited apis |
| 19:58 |
sfan5 |
BPF has the nice property of being guaranteed loop-free |
| 19:58 |
celeron55 |
well that is a distinct benefit, that's for sure |
| 19:59 |
Desour |
unbounded loop free* |
| 20:16 |
|
YuGiOhJCJ joined #luanti-dev |
| 20:18 |
|
SFENCE joined #luanti-dev |
| 22:33 |
|
panwolfram joined #luanti-dev |
| 22:42 |
|
stg-developer joined #luanti-dev |
| 22:45 |
|
stg-developer left #luanti-dev |
| 23:05 |
|
Eragon joined #luanti-dev |
