| Time |
Nick |
Message |
| 02:48 |
MTDiscord |
<herowl> Is it expected that heavy usage of LVMs in area that is already emerged slows down emerging (non-mapgen seemingly)? |
| 02:49 |
MTDiscord |
<herowl> If not, let someone please test latest master (not release) of VoxeLibre, holding nothing in hand or holding a torch, and compare the two options in terms of emerge speed, because I can't explain the results I'm getting |
| 02:52 |
MTDiscord |
<herowl> Or just grab vl_wieldlight from VoxeLibre master (mods/PLAYER) |
| 02:52 |
MTDiscord |
<herowl> I don't think it is using any VL-specific APIs...? |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 08:22 |
|
Warr1024 joined #luanti-dev |
| 08:25 |
|
ZenonSeth joined #luanti-dev |
| 08:28 |
sfan5 |
LVM? you mean voxelmanipulators? |
| 08:36 |
ZenonSeth |
Krock: Zughy: I've restored and re-opened my PRs. Certain discussions can be extremely draining especially when compounding other issues and similar (but opposite) discussions at my job. That being said, me closing my PRs is on me and was not necessary |
| 08:37 |
Krock |
ZenonSeth: I am sure you haven't witnessed the good old -dev flamewars :3 |
| 08:38 |
Krock |
people also got emotional here, though that was already many years ago. -- Thanks for re-opening those. |
| 08:39 |
ZenonSeth |
I wasn't around for a while in Luanti community so yea. To be clear though, I am not taking this personal nor did I every make (or intend) any personal attacks on anyone. Professional discussions can get to me just as much, again especially when issues are compounding. If you want to read my rant, i've slapped it in my about on gh |
| 08:44 |
Krock |
As you mentioned - LLMs are just one part where you can totally get frustrated with. The cryptomining essentially wastes electricity for potential money is another one, for example. It's marketing. All faces of it. |
| 08:47 |
|
Warr1024 joined #luanti-dev |
| 08:50 |
[MatrxMT]_ |
<Zughy> ZenonSeth: I've been there, don't worry |
| 08:50 |
[MatrxMT]_ |
<Zughy> Glad to see you and your work back! |
| 08:52 |
Krock |
PS: might anyone be interested in testing/reviewing some of my PRs? |
| 08:53 |
ZenonSeth |
Krock: I'm correctly assuming you're SmallJoker on gh? |
| 08:54 |
Krock |
yes |
| 08:54 |
ZenonSeth |
also Zughy: thanks. I'm still going to slow down but appreciate it |
| 11:03 |
|
YuGiOhJCJ joined #luanti-dev |
| 12:55 |
ZenonSeth |
ok i dont know the entire history of SSCSM discussion, but has it been considered to leverage existing systems such as contentdb? |
| 12:56 |
ZenonSeth |
for example: a server can have a simple list of CSMs to install from contentdb (which are not currently on there but can be) - and the client simply downloads them from there - since they'd be reviewed there its easier to ensure safety |
| 12:56 |
ZenonSeth |
the only thing missing would be to establish a SM <-> CSM communication channel for completely interactive CSMs |
| 12:57 |
ZenonSeth |
the idea is also that if any server makes a CSM that is useful it can automatically be available for other servers - though the downside here ofc is that there won't truly be private CSMs i guess |
| 13:09 |
ZenonSeth |
also with contentdb as the source of CSMs, no need to worry about authentication connection - i mean it can still be MITM attacked but at most would tell it to download some random CDB CSMs |
| 13:36 |
MTDiscord |
<wsor4035> yes |
| 13:37 |
MTDiscord |
<wsor4035> re mitm, migrating to quic or some other encrypted medium for sscsm has been hinted towards |
| 13:39 |
Krock |
ZenonSeth: OpenTTD does it like this - you have to download the content in order to play on a server. For reference. |
| 13:42 |
ZenonSeth |
never played openTTD |
| 13:43 |
ZenonSeth |
about quick/etc - that's for transport integrity right? - I'm saying don't send CSMs from server to client. Just a list of mod ids that the client will then lookup and download from contentdb (this already exists, contentdb url is set and i can download mods today form it from the client) |
| 13:45 |
ZenonSeth |
a list of mod ids = a list of CSM mod ids - for a new section that doesn't exist today on CDB, so no executable code is transferred server->client at all |
| 13:46 |
MTDiscord |
<wsor4035> what about when contentdb goes down? what if someone wants a private settup? etc. |
| 13:47 |
Krock |
also servers might require different CSM versions |
| 13:47 |
ZenonSeth |
the private setup is a real tradeoff for this, but on the other hand ensures review of CSMs for safety |
| 13:48 |
ZenonSeth |
versioning is a solvable problem, i know not trivial - and yes tradeoffs, but I'm suggesting this because in a lot of ways this solves other big issues that don't have good solutions - e.g. how to verify servers, not using TOFU etc |
| 13:48 |
ZenonSeth |
biggest of all sending malicious CSM code to clients |
| 13:48 |
Krock |
malicious CSMs should not exist by design |
| 13:49 |
Krock |
well.. difficult to protect against cryptomining... but they surely have to be fully isolated, like what's done with IPC for SSCSM |
| 13:49 |
ZenonSeth |
neither should malicious mods, but security flaws have happened |
| 13:50 |
ZenonSeth |
and removing a malicious mod from a central db immediately solves the problem for all clients without requiring clients to be smart enough to update |
| 13:50 |
ZenonSeth |
anyway, it's an idea |
| 13:50 |
MTDiscord |
<wsor4035> may i introduce you to browsers? |
| 13:51 |
ZenonSeth |
brow-sers? what is this? I get all my news from the usenet |
| 13:52 |
ZenonSeth |
but jokes aside, not sure i get your point? |
| 13:53 |
MTDiscord |
<wsor4035> javascript is sscsm basically |
| 13:54 |
ZenonSeth |
yea, sure - a) javascript is huge and lots of people fixing vulnerabilities (and bugs and annoyances in browser implementations still exist) and b) that's kinda my point - javascript is the current direction of sscsm - download some executable code from an unknown third party (only global certificate exists though) |
| 13:55 |
ZenonSeth |
thats why im saying - Luanti server just sends list of CSM ids to get from contentdb, and client gets them from there, caching locally |
| 13:55 |
ZenonSeth |
tradeoffs exist ofc, but solves issues imho |
| 13:55 |
MTDiscord |
<wsor4035> also as the person who approves most cdb packages, if your going to rely on cdb for security, rodl |
| 13:55 |
MTDiscord |
<wsor4035> *rofl |
| 13:56 |
ZenonSeth |
see point above: "and removing a malicious mod from a central db immediately solves the problem for all clients without requiring clients to be smart enough to update" |
| 13:57 |
MTDiscord |
<wsor4035> sure, that requires finding its malicous in the first place |
| 13:58 |
ZenonSeth |
yes, but that isn't made better or easier in any way by the server-send CSM which is current design |
| 13:58 |
ZenonSeth |
in fact its worse |
| 13:58 |
ZenonSeth |
im not trying to outrun a bear, I'm just trying to outrun the last person (the SSCSM) :D |
| 14:09 |
ZenonSeth |
besides, I'm not saying contentdb should replace sandboxing, I'm saying it could be an additional layer to catch things that sadnboxing can't - basically malicious but technically allowed bheavior like cryptomining or something else crazy im sure someone will think of given enough time. |
| 14:10 |
ZenonSeth |
and again, central point makes it much easier to control - I might make an issue to summarize these points maybe |
| 14:40 |
MTDiscord |
<luatic> ZenonSeth: lol this is literally what my SRCSM proposal was: https://github.com/luanti-org/luanti/issues/5393#issuecomment-2545450450. though i did argue that it should replace (one layer of) sandboxing, namely process sandboxing. |
| 14:41 |
MTDiscord |
<luatic> but ultimately i think if we can get luanti to a point where running arbitrary SSCSM is safe enough that's a much preferable, and still attainable, solution |
| 14:41 |
ZenonSeth |
ah i see so it was addressed before, fair |
| 14:42 |
MTDiscord |
<luatic> and you still have trust in there, you just trust specific servers |
| 14:42 |
MTDiscord |
<.zenonseth> yes, but people already put massive trust in mods they downoad from contentdb, plenty of it |
| 14:43 |
MTDiscord |
<luatic> yep i made that comparison too :p |
| 14:43 |
MTDiscord |
<luatic> too much trust arguably if you look at the history of mod security. we're just lucky the gaping holes haven't been (to the best of our knowledge) exploited yet. |
| 14:44 |
MTDiscord |
<.zenonseth> ok i mean if it was discussed and addressed, I'm not going to make a new issue |
| 14:45 |
MTDiscord |
<.zenonseth> you could use cdb to check hashes of csm but ofc if servers customize them that's out the door |
| 14:45 |
MTDiscord |
<luatic> yeah we basically have a consensus on the architecture now which is web-like |
| 14:46 |
MTDiscord |
<.zenonseth> yeah Im just coming in too late |
| 15:44 |
MTDiscord |
<herowl> sfan5: yes, docs call it Lua Voxel Manipulator, LVM for short |
| 15:50 |
MTDiscord |
<herowl> The difference in emerging speed (or range...?) is very big and very noticable, especially if you set view range like 1000 and your PC can handle it – in that case, wielding a torch decreases it to 100 maybe |
| 15:52 |
sfan5 |
I mean of course any Lua scripting "blocks" emerging to some degree (envlock), but if there's a specific performance regression you're observing the answer is "it depends" |
| 15:53 |
sfan5 |
could even be a side effect of the recent occlusion optimization by lhofhansl |
| 15:53 |
sfan5 |
a very low tech thing to try is bisecting when it started happening |
| 15:53 |
sfan5 |
next steps are profiling (luajit + perf) |
| 16:51 |
MTDiscord |
<herowl> sfan5: I doubt it's a regression; it's happening with Luanti 5.16.1. The issue appeared after adding Lua code to VoxeLibre, not after some Luanti change, thing is it is so weird I think it may be a Luanti issue. I'm not sure what do you mean by perf, but flamegraph from luajit does show a lot of "C" called from Lua |
| 17:11 |
MTDiscord |
<herowl> View distance of terrain seems to fall down to about 64 when wielding a light (which is triggering the lighting calculations), but mapgen seems to be happening beyond it: for example, a structure generates in distance, and spawns its mobs, and I see the mobs floating in air there |
| 17:12 |
MTDiscord |
<herowl> Regardless of what the distance was before, it falls down to that specifically |
| 17:12 |
MTDiscord |
<herowl> it's weird, it's not even a pure slowdown: if you stand, nothing more seems to be emerged |
| 17:42 |
MTDiscord |
<herowl> this is the flamegraph when holding a wielded light on voxelibre master and flying around |
| 17:42 |
MTDiscord |
<herowl> https://cdn.discordapp.com/attachments/747163566800633906/1528456981126451240/torch5.svg?ex=6a5e5dfd&is=6a5d0c7d&hm=482ade676ff020d2156f733ddcaf77897ae9f441b49d42102a25bde964d44488& |
| 17:42 |
MTDiscord |
<herowl> doesn't seem to be enough to stall everything relaly |
| 17:46 |
MTDiscord |
<herowl> well, not exactly master, because I cut the gargantuan function into smaller one for the profiling data to be more meaningful |
| 17:46 |
MTDiscord |
<herowl> but in terms of logic, same as master |
| 17:46 |
MTDiscord |
<herowl> I tried to replicate what the engine does when placing a light |
| 17:47 |
MTDiscord |
<herowl> so it is similar logic, but in Lua using voxel manipulators |
| 17:48 |
MTDiscord |
<herowl> so anyway |
| 17:49 |
MTDiscord |
<herowl> despite it being much, it is main server thread, it shouldn't stall the emerge thread in any way, and indeed mapgen seems to be happening anyway... |
| 17:49 |
MTDiscord |
<herowl> please someone look into it, so that we at least know what is the reason for this behavior (and whether anything can be done on the Lua side to alleviate it) |
| 18:02 |
|
vampirefrog joined #luanti-dev |
| 18:27 |
sfan5 |
> despite it being much, it is main server thread, it shouldn't stall the emerge thread in any way |
| 18:27 |
sfan5 |
yes it will, especially if you have lots of on_generated callbacks |
| 18:28 |
sfan5 |
>but flamegraph from luajit does show a lot of "C" called from Lua |
| 18:28 |
sfan5 |
that's why I suggested perf to also profile the C++ part |
| 18:30 |
MTDiscord |
<kneekoo> in my case, as long as I wield a light source, the terrain 64+ blocks away from me won't render no matter how much I wait there |
| 18:30 |
MTDiscord |
<kneekoo> https://cdn.discordapp.com/attachments/747163566800633906/1528469126643716247/screenshot_20260719_202911.png?ex=6a5e694d&is=6a5d17cd&hm=83354f918e939bd7f522e77c8a83445dd181ec4cc3bde765850c20d619e16448& |
| 18:31 |
MTDiscord |
<kneekoo> it's like the engine is somehow blocked by whatever vl_wieldlight does |
| 18:31 |
|
crazylad joined #luanti-dev |
| 18:31 |
MTDiscord |
<kneekoo> as soon as I switch to something else in my hand, the terrain loads (my view range is 1000) |
| 18:32 |
MTDiscord |
<kneekoo> the CPU doesn't sweat while I wait, but nothing happens either - as long as I wield any source of light |
| 18:34 |
sfan5 |
question is: does the terrain not load on the server? or is it just not sent to the client? |
| 18:44 |
MTDiscord |
<kneekoo> the logging indicates that the stuff is generated around me as I moved around: 2026-07-19 20:41:13: ACTION[Emerge-0]: [mcl_dungeons] Placing new dungeon at (2154,-22,559) 2026-07-19 20:41:13: ACTION[Emerge-0]: [mcl_dungeons] Filling chest 2 at (2161,-21,564) 2026-07-19 20:41:13: ACTION[Emerge-0]: [mcl_dungeons] Filling chest 1 at (2161,-21,562) 2026-07-19 20:41:18: ACTION[Emerge-0]: [mcl_dungeons] Placing new dungeon at (2105,-4,374) |
| 18:44 |
MTDiscord |
2026-07-19 20:41:18: ACTION[Emerge-0]: [mcl_dungeons] Filling chest 2 at (2108,-3,375) 2026-07-19 20:41:18: ACTION[Emerge-0]: [mcl_dungeons] Filling chest 1 at (2106,-3,381) 2026-07-19 20:41:20: ACTION[Emerge-0]: [mcl_dungeons] Placing new dungeon at (2035,27,412) 2026-07-19 20:41:20: ACTION[Emerge-0]: [mcl_dungeons] Filling chest 2 at (2040,28,413) 2026-07-19 20:41:20: ACTION[Emerge-0]: [mcl_dungeons] Filling chest 1 at (2037,28,413) 2026-07-19 |
| 18:44 |
MTDiscord |
20:41:23: ACTION[Emerge-0]: [mcl_structures] mineshaft placed at (2096,16,344) 2026-07-19 20:41:23: ACTION[Emerge-0]: [mcl_dungeons] Placing new dungeon at (2063,-29,360) 2026-07-19 20:41:23: ACTION[Emerge-0]: [mcl_dungeons] Filling chest 2 at (2065,-28,365) 2026-07-19 20:41:23: ACTION[Emerge-0]: [mcl_dungeons] Filling chest 1 at (2064,-28,362) 2026-07-19 20:41:27: ACTION[Emerge-0]: [mcl_structures] mineshaft placed at (2084,17,270) |
| 18:45 |
MTDiscord |
<kneekoo> even below surface |
| 18:45 |
MTDiscord |
<kneekoo> https://cdn.discordapp.com/attachments/747163566800633906/1528472885587349615/screenshot_20260719_204152.png?ex=6a5e6ccd&is=6a5d1b4d&hm=3daece4fb2b800c69e58eb4ced94e2d1abc900635bab4700f9c07fbcc610f766& |
| 18:45 |
MTDiscord |
<herowl> stuff gets generated and I even see mobs floating in air in distance |
| 18:46 |
MTDiscord |
<kneekoo> yes, entities show up - chests in dungeons are visible |
| 18:46 |
MTDiscord |
<herowl> I'm trying with structures known to have mobs and dummy backend, to repeateadly approach them while they're generating |
| 18:46 |
MTDiscord |
<herowl> yeahi, it's just that there's no terrain |
| 18:46 |
MTDiscord |
<herowl> visible I mean |
| 18:49 |
MTDiscord |
<herowl> sfan5: not loaded on the server it seems, get_node() calls return ignore |
| 18:51 |
MTDiscord |
<herowl> sfan5: the c++ part is LVM data getters and setters and writing |
| 18:56 |
MTDiscord |
<herowl> sfan5: if I run core.emerge_area(), it loads fine on the server, in the sense of subsequent get_node() calls immediately returning whatever is there, but still I don't see it on the client |
| 19:00 |
sfan5 |
this partially disagrees with what kneekoo said |
| 19:04 |
MTDiscord |
<herowl> sfan5: wdym? |
| 19:06 |
sfan5 |
"the logging indicates that the stuff is generated around me as I moved around" vs "not loaded on the server it seems, get_node() calls return ignore" |
| 19:07 |
MTDiscord |
<herowl> sfan5: actually not all calls to get_node() outside the area return ignore |
| 19:08 |
MTDiscord |
<herowl> sfan5: https://i.imgur.com/nq9sFmP.png |
| 19:09 |
MTDiscord |
<herowl> those entities are visible outside the visible area |
| 19:09 |
MTDiscord |
<herowl> get_node() in that area returns the nodes there, despite nothing rendering, no matter how long I am standing still |
| 19:13 |
sfan5 |
ok so a problem with block sending |
| 19:14 |
sfan5 |
if I had to guess the frequent block updates cause the block sending to restart from the origin (player pos) and never reach further places |
| 19:14 |
sfan5 |
https://github.com/luanti-org/luanti/blob/c85db9339cc1532b997cf5f262b7c11df2ed27ca/src/server/clientiface.cpp#L437-L438 specifically this |
| 19:50 |
|
crazylad48 joined #luanti-dev |
| 20:00 |
|
vampirefrog joined #luanti-dev |
| 20:17 |
|
chripo joined #luanti-dev |
| 20:38 |
|
crazylad joined #luanti-dev |
| 21:10 |
MTDiscord |
<herowl> sfan5: mapgen and emerges per se clearly aren't stalled, I just checked and core.emerge_area() calls the passed callback, and remaining calls reaches 0 under a second even for a large area... and none of those appear to the client |
| 21:10 |
MTDiscord |
<herowl> (singleplayer) |
| 21:10 |
MTDiscord |
<kneekoo> 😆 |
| 21:10 |
MTDiscord |
<kneekoo> https://cdn.discordapp.com/attachments/747163566800633906/1528509460165689394/screenshot_20260719_230936.png?ex=6a5e8edd&is=6a5d3d5d&hm=f734bcbe507744e3614df82be7a0c3eb37db126d684f109da16e1e5bd7e43dbc& |
| 21:10 |
MTDiscord |
<kneekoo> https://cdn.discordapp.com/attachments/747163566800633906/1528509460522209301/screenshot_20260719_231024.png?ex=6a5e8edd&is=6a5d3d5d&hm=039e3abceb0b70ebf425c16e3bdea3a71cebead10fdd89c2bf21f0a61c02db09& |
| 21:12 |
MTDiscord |
<herowl> also changing the various block sending related settings in the advanced section doesn't change anything |
| 21:15 |
sfan5 |
feel free to test my theory directly |
| 21:16 |
sfan5 |
it's possible that you can't fix this by tuning the settings |
| 21:18 |
|
chripo joined #luanti-dev |
| 21:35 |
MTDiscord |
<herowl> sfan5: making the function you linked always return right at the start fixes mapblock loading but makes the light not work |
| 21:36 |
sfan5 |
yes, incorrect things will happen if you stub it out |
| 22:18 |
|
chripo joined #luanti-dev |
| 22:24 |
|
foofofo joined #luanti-dev |
| 22:32 |
|
panwolfram joined #luanti-dev |
| 22:46 |
MTDiscord |
<herowl> sfan5: https://cdn.discordapp.com/attachments/1164672169863819295/1528532502950449213/Nagranie_ekranu_20260720_003803.webm?ex=6a5ea453&is=6a5d52d3&hm=8ba1e287ddebe6318194531952fbc053e439df96a756ec93a214d5ef657ef152& |
| 22:46 |
MTDiscord |
<herowl> tell me if the link doesn't work |
| 22:46 |
MTDiscord |
<herowl> https://cdn.discordapp.com/attachments/1164672169863819295/1528533259909070999/Nagranie_ekranu_20260720_004443.webm?ex=6a5ea507&is=6a5d5387&hm=8c6dafee00f87b3fd53aaa2fe2ff8f701ac795dec84f36bffb9558178af10a0b& |
| 22:46 |
MTDiscord |
<herowl> and another one (notice no redstone torch in offhand in the second one) |
| 22:46 |
MTDiscord |
<herowl> this is absolutely cursed |
| 22:47 |
MTDiscord |
<herowl> It's Luanti latest master, clean (no changes from me) and VL at this commit https://git.minetest.land/VoxeLibre/VoxeLibre/pulls/5652/commits/4e54c4340c802950509c6dfe8212dd3a9bfab437 |
| 22:47 |
MTDiscord |
<herowl> if you care to test yourself |
| 22:48 |
MTDiscord |
<herowl> but this seems to be random each run |
| 22:48 |
MTDiscord |
<herowl> it feels very wrong |
| 22:48 |
MTDiscord |
<herowl> @luatic please see above too |
| 23:11 |
|
chirpo0 joined #luanti-dev |
| 23:21 |
|
chripo joined #luanti-dev |
