| Time |
Nick |
Message |
| 00:02 |
|
AlexiosTheSixth joined #minetest |
| 00:05 |
|
Eragon joined #minetest |
| 00:48 |
|
cryne7 joined #minetest |
| 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:31 |
|
Kimapr_ joined #minetest |
| 01:34 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> We should fix those bugs, but then add a core.request_segfault() API 😄 |
| 01:50 |
MTDiscord |
<warr1024> (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"? |
| 02:22 |
|
SwissalpS joined #minetest |
| 02:44 |
|
Can0xfBows joined #minetest |
| 03:20 |
|
chilledfrogs joined #minetest |
| 04:11 |
|
Verticen joined #minetest |
| 04:43 |
|
erle joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:10 |
|
sparky4 joined #minetest |
| 05:43 |
|
Meli joined #minetest |
| 09:34 |
sfan5 |
cheapie: yes. the engine should throw an error rather than crashing |
| 09:44 |
|
PoochInquisitor joined #minetest |
| 09:58 |
MinetestBot |
[git] appgurueu -> minetest/minetest: Silence failing raycast unit test (#15644) 7f13162 https://github.com/minetest/minetest/commit/7f1316236bafef9dae1a80aa6de6df4482942cd9 (2025-01-08T09:56:05Z) |
| 09:58 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Fix reduced bloom at 10 bits 41f7031 https://github.com/minetest/minetest/commit/41f7031e49adfb4accd8df2986dd68ece44711f6 (2025-01-08T09:56:28Z) |
| 09:58 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Remove or restrict some client settings (#15633) e5542e5 https://github.com/minetest/minetest/commit/e5542e5b024719bc5f1b111fb2e3eded3fbffca6 (2025-01-08T09:56:45Z) |
| 10:11 |
|
Desour joined #minetest |
| 10:29 |
|
gregon joined #minetest |
| 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 |
|
tarsovbak joined #minetest |
| 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? |
| 11:22 |
|
Oblomov joined #minetest |
| 11:48 |
|
ireallyhateirc joined #minetest |
| 12:22 |
|
pgimeno_ joined #minetest |
| 12:51 |
|
ll0lll0 joined #minetest |
| 13:01 |
|
Glaedr joined #minetest |
| 13:14 |
MTDiscord |
<mistere_123> Warr1024: insert this update breaks my workflow xkcd |
| 13:15 |
MTDiscord |
<wsor4035> 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 |
<mistere_123> In an hour and a half, my Minigame server, "Oasis Minigames" is launching. IP: sever.oasisminigames.xyz Port: 30000 |
| 13:29 |
MTDiscord |
<mistere_123> 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 |
| 14:16 |
|
PoochInquisitor joined #minetest |
| 14:25 |
|
SpaceManiac joined #minetest |
| 14:32 |
|
Desour joined #minetest |
| 14:34 |
|
jaca122 joined #minetest |
| 15:08 |
|
jluc joined #minetest |
| 16:03 |
|
citrons joined #minetest |
| 16:55 |
|
mrkubax10 joined #minetest |
| 17:29 |
|
est31 joined #minetest |
| 18:13 |
|
Verticen joined #minetest |
| 18:18 |
|
mrkubax10 joined #minetest |
| 18:19 |
|
Talkless joined #minetest |
| 18:19 |
|
mrkubax10 joined #minetest |
| 18:30 |
|
frostsnow joined #minetest |
| 18:38 |
|
jaca122 joined #minetest |
| 19:25 |
|
___nick___ joined #minetest |
| 19:28 |
|
___nick___ joined #minetest |
| 20:00 |
|
nopjmp joined #minetest |
| 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 |
<wsor4035> 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 |
<luatic> 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:20 |
|
Thermoriax joined #minetest |
| 22:33 |
|
Meli joined #minetest |
| 22:34 |
MTDiscord |
<luatic> i am joking |
| 22:35 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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:11 |
|
diceLibrarian2 joined #minetest |
| 23:12 |
|
bodiccea_ joined #minetest |
| 23:27 |
|
YuGiOhJCJ joined #minetest |
| 23:33 |
|
panwolfram joined #minetest |
| 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. |
| 23:56 |
|
Verticen joined #minetest |
