Time Nick Message 01:04 cheapie I assume that a segfault if a mod tries to create a VoxelManip of absurd size (billions of nodes) counts as both a mod bug (it shouldn't try that) and engine bug (it shouldn't segfault), right? 01:04 ireallyhateirc how big in mapchunks is that? 01:06 ireallyhateirc a mapchunk is 512K nodes so billions is insane 01:10 cheapie I haven't narrowed things down too much, but as a semi-minimal reproduction, this segfaults: local v1=vector.new(0,0,0);local v2=vector.new(1500,1500,1500);VoxelManip(v1,v1):read_from_map(v2,v2) 01:10 cheapie (this isn't me doing something silly myself again, a mod was trying something similar) 01:14 ireallyhateirc that's a fat one lol 01:15 ireallyhateirc for generating big stuff I use map abstraction written in Lua 01:15 cheapie It's not even generating, it's just trying to load stuff and doing it strangely. 01:16 ireallyhateirc the biggest I have is 800x800 city generating plan, though it's just one flat layer to draw roads on (in the future hopefully I'll make it volumetric) 01:16 ireallyhateirc but it's basically a 2D lua array 01:17 ireallyhateirc you should probably spawn smaller VMs and read the data in packets 01:28 cheapie I'm not the developer of the mod in question 01:34 MTDiscord cheapie: it's not a bug, it's a feature 😆 I actually have used that exact segfault in the past to test my Luanti debugging setups. 01:35 cheapie I'll file a bug in the mod for sure (soon, anyway, I have a few other loose ends to deal with here), just not sure if the engine devs really /want/ that bug report or not. 01:35 MTDiscord I asked once "I'm trying to automate capture in gdb and I need to segfault Luanti on demand to test it" and the answer I got back was "well you're in luck" 01:45 ireallyhateirc I think you can also get a segfault if you tile name to = {{}} or something like this 01:46 ireallyhateirc if you set* 01:50 MTDiscord We should fix those bugs, but then add a core.request_segfault() API 😄 01:50 MTDiscord (technically I guess that should be insecure_env.request_segfault() 🤔 01:53 ireallyhateirc I'd like to be able to push a segfaulting code into a malicious client 01:53 ireallyhateirc so that we can shadowban griefers by making their client crash when they connect 02:11 cheapie warr1024: Hmm... I was just thinking, if you want it to segfault on demand, can't you just "killall -SEGV luanti"? 09:34 sfan5 cheapie: yes. the engine should throw an error rather than crashing 09:58 MinetestBot 02[git] 04appgurueu -> 03minetest/minetest: Silence failing raycast unit test (#15644) 137f13162 https://github.com/minetest/minetest/commit/7f1316236bafef9dae1a80aa6de6df4482942cd9 (152025-01-08T09:56:05Z) 09:58 MinetestBot 02[git] 04sfan5 -> 03minetest/minetest: Fix reduced bloom at 10 bits 1341f7031 https://github.com/minetest/minetest/commit/41f7031e49adfb4accd8df2986dd68ece44711f6 (152025-01-08T09:56:28Z) 09:58 MinetestBot 02[git] 04sfan5 -> 03minetest/minetest: Remove or restrict some client settings (#15633) 13e5542e5 https://github.com/minetest/minetest/commit/e5542e5b024719bc5f1b111fb2e3eded3fbffca6 (152025-01-08T09:56:45Z) 10:30 cheapie Bleh, #15633 was merged, time for me to add some more stuff to playersettings later today (fsck clouds) I guess 10:30 ShadowBot https://github.com/minetest/minetest/issues/15633 -- Remove or restrict some client settings by sfan5 10:31 cheapie sfan5: I'll try to get around to filing a bug report for the VoxelManip thing later today if I have time 10:35 cheapie I did file one with the mod last night, there's been a bit of discussion from the maintainers of that project about it. In the meantime I put in a simple patch on the affected server (just creates a new VoxelManip instance every time it wants to load something) and it's been working so far. 10:41 sfan5 you can skip the bug report, I already got a backtrace 10:42 cheapie Ah, OK, I had one too but that works 10:50 sfan5 hmm since it's v2,v2 shouldn't it be emerging a single block? 13:14 MTDiscord Warr1024: insert this update breaks my workflow xkcd 13:15 MTDiscord https://xkcd.com/1172/ 13:24 cheapie sfan5: Yeah, I think that's what the mt-mods/technic devs were expecting, but it seems that if the volume of a box defined by v1 and v2 exceeds about 2^31 nodes then it crashes (is something signed that shouldn't be? I tried following along in the code but I'm not great with C/C++) 13:25 cheapie If I use 1000,1000,1000 for v2 (~1B nodes) it takes some time but doesn't crash. 13:26 cheapie I can't remember if I shared this link before (I'm at work right now, no access to most of the scrollback) but I did report the bug in the mod too: https://github.com/mt-mods/technic/issues/394 13:28 MTDiscord In an hour and a half, my Minigame server, "Oasis Minigames" is launching. IP: sever.oasisminigames.xyz Port: 30000 13:29 MTDiscord It features art by notsowow 13:33 cheapie I just tried with v2=vector.new(1000,1000,1000) on my work potat- erm, laptop - led to it thrashing swap for 49 seconds but did complete successfully. 13:33 cheapie IIRC at home (much faster CPU, enough RAM) it took about 2 seconds 13:46 ireallyhateirc 2 seconds for billions of nodes? 13:46 ireallyhateirc what does the VM do? 13:50 cheapie ireallyhateirc: See https://github.com/minetest/minetest/issues/15658 13:50 cheapie TL;DR not much, just loads two nodes far apart 13:51 ireallyhateirc hmm but does it do any reading/writing ? 13:51 cheapie Aside from :read_from_map()? No. 13:51 cheapie They're using it just to force the mapblock to load, that's it. 13:52 ireallyhateirc uh, sounds like an ugly hack 13:52 cheapie yes 13:52 cheapie I didn't write it (but don't worry, mine was worse, never worked properly, and *still* comes back to haunt me in forks sometimes) 13:53 ireallyhateirc your what exactly in this case? 13:53 cheapie My version of the code to do what it's trying to do, more or less 13:54 cheapie Technic had a rather infamous bug for a while where it would drive forceload reference counts up into the millions or more, that was my fault - I think minetest-mods and mt-mods have both fixed it by now, but every so often I come across a fork that still has the broken coede. 13:54 cheapie code* 13:55 ireallyhateirc I think you're supposed to use core.forceload_block and core.forceload_free_block 13:55 ireallyhateirc Could be that when you make that obese VM the game chokes on mapgen 13:56 cheapie re: forceload - Sort of, yes - the broken code I wrote years ago did use them, but it used them incorrectly since the documentation was wrong. 13:56 ireallyhateirc though not that alone, otherwise it wouldn't segfault 13:56 cheapie As for VM - it's not emerging the whole area, only two (or a handful) of mapblocks in it, but the engine seems to be allocating memory for the whole thing. 13:57 ireallyhateirc is the documentation good now? I'm not sure if "pos" is node pos or mapblock pos 13:58 cheapie I'll have to check if the forceload documentation is any better now, but at the time it falsely claimed that forceload_free_block() would actually stop forceloading the mapblock, and the reference count mechanism was completely undocumented. 13:58 ireallyhateirc it says "stops forceloading the position pos" but it probably doesn't mean the block is instantly unloaded after that 13:59 cheapie Yeah, it's still wrong 13:59 cheapie It *doesn't* necessarily stop forceloading it, it decrements the (undocumented?) reference count and stops forceloading if and only if the count reaches 0 14:00 ireallyhateirc you should probably make a bug repor then 14:00 ireallyhateirc report* 14:00 cheapie I could have sworn I did like 6 or 7 years ago, I might have to see if I can find it sometime 14:01 ireallyhateirc maybe that appeared to you in a dream 14:02 cheapie Also it does appear that technic should probably be using core.load_area() instead of a VM in the first place (for the other part) 14:03 cheapie The odd part is that it *does* elsewhere 20:33 cheapie I've been looking into how to mitigate #15633 on the server side - clouds seem easy enough (someone even wrote a mod that adds a workaround already), but on the other hand I can't find a way to disable digging particles from the server side. Am I just using the wrong search terms? 20:33 ShadowBot https://github.com/minetest/minetest/issues/15633 -- Remove or restrict some client settings by sfan5 20:33 sfan5 there's no way to do this 20:34 cheapie Another thing to file a bug/feature request for when I get home, I guess :/ 20:36 sfan5 you want them disabled per-player or per-node? and why even? 20:36 cheapie Per-player, I find them to be a particularly annoying effect. Traditionally they've been one of the first things I make sure is off, alongside "always fly fast" 20:37 cheapie They're not /as/ bad as clouds, at least - but those have the ability to be turned off via mods 20:39 sfan5 I can't see per-player controls being added, if anything per-node makes sense 20:41 ireallyhateirc per-node or globally would be also good 20:41 ireallyhateirc speaking of, is there a way to disable/replace the digging texture? 20:42 ireallyhateirc the digging overlay looks terrible on meshes 20:42 sfan5 you can replace the texture globally 20:43 ireallyhateirc how? 20:43 cheapie If per-node control was added I'd probably see about what the other players on the server want, could be worthwhile to throw together a quick mod that just overrides all nodes to have it turned off if that's what they end up wanting. 20:44 sfan5 ireallyhateirc: provide a crack_anylength.png with your game 20:44 sfan5 see doc/texture_packs.md 20:44 ireallyhateirc ok, thanks 20:48 cheapie In the meantime I guess I'll just patch it out - would be nice to be able to do something for users that aren't compiling their own, but *shrug* 21:06 cheapie Thinking more about it, this might be an excuse for me to learn some C++ and create a PR to make multiple attributes of digging particles configurable by mods - I haven't studied the existing code so I don't know how many of these make sense, but things like number, size, behavior, etc., with number being able to go all the way to 0 if the mod so desires. 21:07 cheapie This would require me to A) figure out a sane way to implement it, and B) learn enough C++ to do, both of which are pretty questionable but not necessarily impossible :P 21:07 cheapie to do so* 21:07 ireallyhateirc what subset/dialect of C++ does Luanti use? 21:07 ireallyhateirc I heard that one can't learn the whole language before dying 21:13 cheapie And yes, I am trying to come up with ways to make it *not* a "revert X out of spite" PR and instead something useful. Trying. I've done those before (years ago) and they predictably never get merged :P 21:53 MTDiscord c++17 iirc? idk, should be in the readme or somewhere 21:57 ireallyhateirc I was partially joking about C++ being so swollen 22:03 cheapie ireallyhateirc: I hope I'm supposed to parse this as "there's too much C++ to learn it all in time" and not "learning C++ is deadly" :P 22:10 ireallyhateirc C++ is like drinking water, everyone who does it dies :D 22:16 MTDiscord ireallyhateirc: obviously we only use the good parts 22:19 ireallyhateirc can't tel if you're serious or joking :P 22:19 ireallyhateirc though I'd enjoy to know the major features Luanti uses 22:19 ireallyhateirc tell* 22:34 MTDiscord i am joking 22:35 MTDiscord it's hard to tell what exactly we use, it just sort of emerges as an implicit consensus of what we find sane and will allow to pass in review 22:37 ireallyhateirc I find it double hard to understand any of Luanti's C++ code because 1. don't know the language well 2. functions often don't have a single comment describing what they do 22:37 MTDiscord we should probably comment more in cases where things aren't obvious 22:38 ireallyhateirc I'm aware that forcing devs to document code is hard, because I have a hard time forcing myself 22:38 MTDiscord it's just sadly one of those chores that isn't as satisfying as, say, fixing a bug, or implementing a nice feature 22:39 MTDiscord refactoring is still more satisfying than documenting code 22:39 ireallyhateirc I started documenting code only because I often do underslept/"drunk" coding and forget what something does quickly 23:35 cheapie Random thoughts about those particle controls (I don't see myself having time to try anything until Friday at the earliest, so just thinking for now) - weather mods are the main use case I can think of and would need per-player because players aren't usually all in the same weather at the same time. I could see them wanting control over a few things - perhaps having humidity (both by location and recent rain and such) lead to fewer, larger 23:35 cheapie particles that fall faster and disappear sooner, while dry areas might be more "dusty" with more, smaller particles that fall slower and stick around longer. Wind (as implemented by said weather mod) causing digging particles to move in the direction of the wind would probably be seen as a "nice to have" as well. 23:36 cheapie Of course once there's control over number of particles (however it's implemented - I haven't even dug into the existing code to see how it works yet), I would expect it to be easy enough to just have the range of valid values extend down to 0.