Time Nick Message 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 i am in front of my computer but the sunburn is setting in 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 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 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 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 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 yeah i think luanti has always rolled its own crypto? 18:19 MTDiscord (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 MTDiscord looking at those changes most don't seem very meaningful 18:21 MTDiscord at least the recent ones 18:21 MTDiscord 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 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 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 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 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 > 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 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 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 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 "Replacement" seems an odd term, it'd just be a utility to help us implement more flexible param2 types 18:57 MTDiscord 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 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 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 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 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 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*