| Time |
Nick |
Message |
| 00:03 |
|
v-rob joined #minetest |
| 00:11 |
erlehmann |
sfan5 i think it is lame if you mute me from #minetest-dev if you are the only person fed up with me, you can as well just use /ignore – it is different if multiple people are annoyed by me though, then it is legit ig |
| 00:12 |
erlehmann |
also i think most ppl here aren't *that* interested in engine discussions, but whatever |
| 00:15 |
sfan5 |
I didn't say I wouldn't remove it eventually |
| 00:22 |
|
Verticen joined #minetest |
| 00:22 |
MTDiscord |
<MisterE> Idk if its my place to comment, but from what I've seen here, id say, sfan5, please try to work with this guy cause he seems useful to the project and well-intentioned |
| 00:24 |
MTDiscord |
<Jonathon> >useful looks at a lack of PR's |
| 00:24 |
MTDiscord |
<MisterE> Reporting actual vulnerabilities seems useful to me.. |
| 00:25 |
MTDiscord |
<Jonathon> > most people do in fact not care that putting in obviously invalid input makes the game freeze or run out of memory > nor do they try that, except by accident |
| 00:28 |
MTDiscord |
<MisterE> they start to care when the bad intentioned players log on. With minetest at the scale it is now, for the most part, yeah its not an issue. But if one wanted to make a larger scale server then you start to care about these vulnerabilities. Better, imo to know your programs weaknesses and that way be able to fix it later if it becomes important in the future |
| 00:29 |
MTDiscord |
<MisterE> Whatever, not here to argue |
| 00:29 |
|
kamdard joined #minetest |
| 00:31 |
|
AliasAlreadyTake joined #minetest |
| 00:31 |
MTDiscord |
<savilli> did you even look at their issues? |
| 00:31 |
MTDiscord |
<savilli> none of them are actual security vulnerabilities |
| 00:32 |
MTDiscord |
<savilli> they don't allow to crash a server no matter how large it is |
| 00:33 |
sfan5 |
issues reported to github do get looked at regardless |
| 00:35 |
MTDiscord |
<savilli> okay #11822 is a security vulnerability, but it allows to crash the client, and honestly I don't think it's an issue for online game |
| 00:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/11822 -- Crash on texture modifier with too much crack |
| 00:37 |
MTDiscord |
<MisterE> No I didn't. My comment is entirely based on what I've read here. So yeah take it with salt to taste :P |
| 00:40 |
MTDiscord |
<savilli> don't let to fool yourself XD |
| 00:41 |
erlehmann |
> none of them are actual security vulnerabilities |
| 00:41 |
erlehmann |
the tp to out of bounds is a denial of service |
| 00:42 |
MTDiscord |
<savilli> what issue is that? |
| 00:43 |
erlehmann |
the one where i continue to claim that sfan5 fixed it in the wrong way: https://github.com/minetest/minetest/issues/11769 |
| 00:44 |
erlehmann |
(just the limit is wrong the rest of the patch seems ok) |
| 00:45 |
erlehmann |
savilli what exactly would you expect if someone tried to poke the network code like i poke settings or lua API? i think the result would be that minetest would fall over and die pretty quickly. |
| 00:46 |
erlehmann |
savilli the actual issue is btw that dynamic content on the server will be created by players |
| 00:47 |
erlehmann |
so let's assume we have a hang when minetest gets too many texture modifiers (we do) and a mod allows users to append texture modifiers … bad ppl exploit that |
| 00:47 |
erlehmann |
eventually |
| 00:48 |
erlehmann |
savilli from your very few bug reports i gather you either run a server that deals with cheaters or you develop a game that deals with cheaters or you are a cheater. which is it? |
| 00:48 |
MTDiscord |
<savilli> i'm a server admin |
| 00:48 |
erlehmann |
then you know the length that motivated attackers will go to i guess |
| 00:50 |
erlehmann |
i assist cora who runs the oysterity server |
| 00:50 |
MTDiscord |
<savilli> Don't allow players to apply texture modifiers? Who would expect that api to be secure? |
| 00:50 |
erlehmann |
most of the bad actors are script kiddies who run cheat clients |
| 00:50 |
erlehmann |
i made a proposal in the bug report how to fix the issue |
| 00:50 |
erlehmann |
namely, divorcing parsing texture modifiers from processing them |
| 00:51 |
erlehmann |
doing full recognition of the string before processing |
| 00:51 |
erlehmann |
thereby getting rid of all of these shotgun parser bugs |
| 00:52 |
erlehmann |
savilli the issue i have is that if you want me to prove that every single thing where no bounds checking or verification occurs is actually exploitable, you are wasting both of our time. most times it is easier to fix it. |
| 00:52 |
|
Extex joined #minetest |
| 00:53 |
erlehmann |
IMO the whole “let's not fix overflows properly” stance of the dev team makes no sense long-term |
| 00:53 |
|
kamdard joined #minetest |
| 00:53 |
erlehmann |
it *needs* to change |
| 00:53 |
erlehmann |
Jonathon what do you expect me to do, fix every bug i find? even when i post a patch in the issue half of the times it is not taken seriously. |
| 00:54 |
erlehmann |
and i do write lua workarounds |
| 00:54 |
erlehmann |
for mineclonia |
| 00:54 |
erlehmann |
in fact, cora offered that exact workaround for minetest_game and it was not wanted |
| 00:57 |
erlehmann |
MisterE i think most of the annoyance comes bc i look through at the code from the lens of a) someone attacking a server or client b) a user who sets all values to everything possible … and then devs are like “but who would actually do that” or “but our code without any games is not exploitable” or “i have no idea how that could happen” and disregard the bug report. |
| 00:58 |
erlehmann |
i'd rather file those bugs in case it becomes relevant in the future |
| 00:58 |
|
SuperMiner joined #minetest |
| 01:00 |
erlehmann |
Jonathon btw i told you before that i am not a C++ app developer. i know good architecture and how to break things, but not how to fix them as well as other ppl do. |
| 01:00 |
erlehmann |
like i can tell you the method, but most of the time someone else will be better at writing the actual C++ code |
| 01:00 |
erlehmann |
bc i have no routine |
| 01:00 |
erlehmann |
and too little understanding compared to many others |
| 01:01 |
erlehmann |
and i'd rather avoid proposing a solution that i am not sure will be correct in a language where i am not confident at all |
| 01:02 |
MTDiscord |
<savilli> if you're confident enough to make an issue, then you can fix it |
| 01:03 |
erlehmann |
savilli what exactly you would think would happen if i propose a fix to https://github.com/minetest/minetest/issues/11828 that aligns the limits with s16 bounds? |
| 01:03 |
erlehmann |
i expect it to be discarded |
| 01:03 |
MTDiscord |
<savilli> if you expose insecure api to clients, you shouldn't expect anybody to make it secure fro you |
| 01:03 |
MTDiscord |
<savilli> *for you |
| 01:04 |
erlehmann |
savilli should i try making a patch for that and we see how it plays out? |
| 01:04 |
MTDiscord |
<savilli> i think we can predict that |
| 01:04 |
erlehmann |
yeah what do you think will happen |
| 01:06 |
erlehmann |
if you agree with me that it will probably be rejected then i don't see why i should make even the tiniest of patches if it's a waste of both my and the reviewers time |
| 01:06 |
MTDiscord |
<savilli> core devs will propose a change, you will be stubborn and won't correct anything with ridiculous excuses, and pr will be discarded |
| 01:07 |
erlehmann |
what change would it be? |
| 01:07 |
erlehmann |
as said before, i'd only want to align minetest.find_nodes_in_area() with the limits of the map storage to avoid future bugs |
| 01:08 |
sfan5 |
well what are the limits of map storage? |
| 01:09 |
erlehmann |
whatever data type the mapblock format uses, so i'd say s16 bounds |
| 01:09 |
erlehmann |
if you had a proper type here that did typechecking etc. that would not be an issue, but you have not |
| 01:09 |
MTDiscord |
<Warr1024> I ran into the fact that things past the mapgen limit sort of do and sort of don't actually exist and ... I ended up just assuming it was my responsibility and added my own checks in the game code :-| |
| 01:09 |
MTDiscord |
<Warr1024> Given that, I would not be surprised if this class of issue doesn't triage very highly. |
| 01:11 |
erlehmann |
the thing is, this entire category of bugs can be properly fixed by doing a few things: 1. set MAX_MAPGEN_LIMIT or how its called to >32768 in debug builds 2. compile the debug build with ubsan 3. collect the dozen or so signed integer overflows 4. fix every single one of them |
| 01:11 |
erlehmann |
that makes the weird zone between ±31000 and s16 bounds (-32768,32767 or so?) vanish completely |
| 01:12 |
erlehmann |
and thus gets rid of all bugs in that zone |
| 01:12 |
erlehmann |
it would also fix a bunch of issues that are currently rare to encounter |
| 01:13 |
erlehmann |
before anyone accuses me of being lazy: i actually did that, except for the “fix every single one of them” bit |
| 01:13 |
MTDiscord |
<Warr1024> Sure, but the "fix every single one of them" part sounds KIND of important... |
| 01:13 |
erlehmann |
and stopped pretty quickly when sfan5 pointed out that there is a comment in the code that signed integer overflow shall not be fixed, better stay away from the boundaries |
| 01:13 |
MTDiscord |
<savilli> and how many issues did you collect? |
| 01:14 |
erlehmann |
i did not file issues for that stuff |
| 01:15 |
erlehmann |
because the predictable response from ppl who do not know how to get nodes out of bounds is “oh but mapgen stops at 31000” (which is not exactly true, but whatever) |
| 01:15 |
MTDiscord |
<savilli> but you did collect them |
| 01:15 |
MTDiscord |
<savilli> so how many? |
| 01:15 |
erlehmann |
i remember less than a dozen, but i'd have to run it again with current code |
| 01:15 |
erlehmann |
also that was only mapgen-triggered stuff |
| 01:15 |
erlehmann |
so there are more |
| 01:15 |
erlehmann |
the thing is, without actually triggering them, they lurk in the code forever |
| 01:16 |
MTDiscord |
<Warr1024> If you discover a whole class of bugs that you would presumably try to fix all in one PR (given the overhead cost of getting one merged) I wouldn't file separate issues for each instance, if that's what you meant... |
| 01:17 |
MTDiscord |
<savilli> you definitely were lazy, i would expect at least > 100 |
| 01:17 |
erlehmann |
Warr1024 the class of bug is “every time devs encounter a signed integer overflow with functions taking s16 coordinates or their float equivalent, they try to tie it to MAX_MAPGEN_LIMIT, which is 31000 and not the actual boundary”. it's a social problem. |
| 01:17 |
MTDiscord |
<Warr1024> Heh, it kind of reminds me of Pareto Creep |
| 01:18 |
erlehmann |
what's that? |
| 01:18 |
erlehmann |
savilli i only tested minetest_game with v7 mapgen, it doesn't exactly do much. ofc you get more if you test mcl2 or so. |
| 01:18 |
erlehmann |
quick place a dispenser out of bounds! :D |
| 01:18 |
MTDiscord |
<Warr1024> Basically you reason that "99% of people don't need this" so you don't care about a fringe case. But then now since you're discounting that 1%, the goalposts are now moved and next time you say "do 99% of people not care" it's 99% of a smaller population. |
| 01:19 |
erlehmann |
oh yeah |
| 01:19 |
MTDiscord |
<Warr1024> Obviously over time if you just assume that boundary regions are discardable, then those boundaries will creep inward. |
| 01:19 |
erlehmann |
in this case, moving the limits closer to where the actual visible map is, the boundary already overlaps with it |
| 01:19 |
MTDiscord |
<Warr1024> I could easily tell you "if all the engine's stuff stops behaving around 31000, then just make your limits 30000" but you can only get away with that like 29 times more before it becomes everybody's problem :-) |
| 01:19 |
erlehmann |
as the screenshot in https://github.com/minetest/minetest/issues/11828 shows https://gcdn.pbrd.co/images/oWIFZN2KTOK6.jpg?o=1 |
| 01:20 |
erlehmann |
i am standing there at about 31000,2,0 in vanilla minetest |
| 01:20 |
erlehmann |
obviously in a visible map block |
| 01:20 |
erlehmann |
and i can place nodes in the stone part of the map to the left and dig them |
| 01:20 |
MTDiscord |
<Warr1024> But if coredevs are not willing to fix something you COULD work around by just setting limits to 30000, I also kind of understand that. Personally I usually don't worry about "is this becoming a pattern" until I see it about to happen a 3rd time. |
| 01:21 |
erlehmann |
but minetest.find_nodes_in_area() will not find them |
| 01:21 |
erlehmann |
i already saw it happening in games |
| 01:21 |
erlehmann |
some months ago mcl2 had the crashbutton issue |
| 01:21 |
erlehmann |
basically in mcl2 0.71 and earlier, depowering mesecons at the visible world (x=30927 or so) border crashes the game |
| 01:22 |
erlehmann |
because hey, someone assumed that's where the world ends |
| 01:22 |
erlehmann |
so a button at the edge of the world crashes the game |
| 01:22 |
erlehmann |
a jumping mob with a pressure plate … |
| 01:22 |
erlehmann |
you see where this is going |
| 01:22 |
MTDiscord |
<Warr1024> As of right now, as I understand it, it might be a "modder problem", i.e. that modders are expected to account for weirdness near the map boundaries. I mean the fact that there's a 1768-wide margin zone does suggest that somebody has already sort of punted on that. |
| 01:23 |
erlehmann |
punted? |
| 01:23 |
erlehmann |
the raycast thing is actually the third time i encounter this |
| 01:23 |
erlehmann |
and i already told ppl i'll stop reporting coordinate boundary bugs unless i have a fix ready |
| 01:23 |
erlehmann |
bc they'll always do the wrong thing in response |
| 01:25 |
MTDiscord |
<Warr1024> I guess if this is really a serious engine bug it seems weird that I don't run into it a lot even though I tend to use very small mapgen_limits on all my servers, so players can run from boundary to boundary in a few minutes. |
| 01:25 |
erlehmann |
Warr1024 the problem i have with that zone is that a bunch of API functions work perfectly in it and others don't. and it kinda makes sense. after all, your mapgen might stop at 31000, but what if someone makes a village at the map border? the mod code may stray out of bounds. |
| 01:25 |
MTDiscord |
<Warr1024> I've definitely run into SOME issues, especially with the world bottom boundary where entities want to try to fall in |
| 01:26 |
erlehmann |
the thing is, it's serious in case of high impact, but not serious if you think about if it happens a lot |
| 01:27 |
erlehmann |
like come on, everyone involved in the boundary discussion could write a short script to bring down all mt 5.4.1 and earlier servers |
| 01:27 |
erlehmann |
from my POV that does not change a thing |
| 01:27 |
erlehmann |
like, idc if the script exists |
| 01:27 |
erlehmann |
maybe others do? |
| 01:28 |
erlehmann |
a tangent: i think anarchy servers act as a sponge for assholes that want to have fun at others expense |
| 01:28 |
erlehmann |
and that's also why some servers have a lot of these issues |
| 01:28 |
erlehmann |
and others don't |
| 01:29 |
MTDiscord |
<Warr1024> Heh, I guess in my case I wonder whether the server stays down. If it's just a crash and doesn't persist after a restart unless manually done again from the outside, then I guess it's a lot less concerning than if it would corrupt a world and require manual fixing each time. |
| 01:29 |
erlehmann |
i.e. shut down anarchy servers and those clowns bring down catlandia |
| 01:29 |
MTDiscord |
<Warr1024> Hmm, so a honeypot hypothesis then? |
| 01:29 |
erlehmann |
nah, it's better to put them all in one room and let them fight it out |
| 01:30 |
erlehmann |
also i kinda like playing in an adversarial environment like that |
| 01:30 |
MTDiscord |
<Warr1024> Seems like if you run a major server you'd have an incentive to want to run your own separate anarchy server, or pool into some collective to manage some. |
| 01:30 |
erlehmann |
it makes creative solutions necessary |
| 01:30 |
erlehmann |
like there was one player who continued spawnkilling noobs |
| 01:30 |
erlehmann |
i made a client join with random input |
| 01:30 |
erlehmann |
and respawn a lot |
| 01:30 |
erlehmann |
after more than 20 minutes the spawnkiller complained about RSI :D |
| 01:31 |
erlehmann |
apparently other ppl just quit after being killed 10 times |
| 01:31 |
erlehmann |
my bot client obv ran for hours |
| 01:31 |
MTDiscord |
<Warr1024> Heh, you're definitely playing some kind of game, but I'm not sure whether it's a "minetest" one per se at that point |
| 01:32 |
erlehmann |
or also recently fleckenstein helped mineclonia to tie down the ender chest inventory |
| 01:32 |
erlehmann |
so that you can't access it without being near an echest |
| 01:32 |
erlehmann |
it's funny to know ppl are going into combat and respawning without the ability to pull out more TNT from thin air |
| 01:33 |
erlehmann |
i am working on a way to ruin commonly known teleportation cheats too |
| 01:33 |
MTDiscord |
<Warr1024> Heh, I make a game with virtually no combat, and even figuring out how to add combat to it is considered a Hard Problem, so I don't know much about that world. |
| 01:33 |
erlehmann |
well, just join oysterity and try to stay alive if you are that curious |
| 01:34 |
erlehmann |
it's definitely an interesting wild west thing |
| 01:34 |
erlehmann |
like if you encounter a stranger |
| 01:35 |
erlehmann |
i once had a player straight up to /kill bc i was following them around and they did not want to leak their teams base location |
| 01:35 |
erlehmann |
so they suicided their character and gave me all those items to keep the location secret |
| 01:35 |
erlehmann |
(respawning in their bed ofc) |
| 01:38 |
erlehmann |
Warr1024 savilli btw i am always willing to collaborate on lua workarounds, those aren't held up by engine dev opinions |
| 01:39 |
MTDiscord |
<Warr1024> Yeah, though general workarounds are challenging too. |
| 01:39 |
MTDiscord |
<Warr1024> Like, I mostly just test my mod content against all sorts of boundary conditions and corner cases, wherever I can find them, and a lot of the time I end up with only fixes for very specific issues. |
| 01:39 |
MTDiscord |
<Warr1024> They don't necessarily evolve into general polyfill sorts of things. Though sometimes they do. |
| 01:40 |
erlehmann |
well, with the coordinate bullshit i just overwrite the engine thing with something that checks the input against s16 boundaries |
| 01:40 |
erlehmann |
like in mineclonia we straight up replaced minetest.find_nodes_in_area() with a wrapper |
| 01:40 |
erlehmann |
that calls the real function |
| 01:41 |
erlehmann |
also ppl already thought of implementing it with other functions if the engine stays broken, but that's work |
| 01:42 |
MTDiscord |
<Warr1024> Heh, another workaround is to pull the limit in a mapchunk or so, but using mapgen_limit for it, using lua mapgen to fill the boundary area with actual nodes that behave like ignores. There are some neat things you can do with that (like controlling the appearance or how light propagates) though obviously if you decide to change the limit later, you have to manually fix the map first. |
| 01:43 |
erlehmann |
i see, you are another person who actually knows how to get oob nodes :D |
| 01:44 |
erlehmann |
seriously, the “but mapgen can't go that far” thing is what annoys me the most about boundary conversations. i have yet to see a test case that proves it can't, ppl just thing the code is alright that way. |
| 01:44 |
erlehmann |
think |
| 01:45 |
erlehmann |
Warr1024 wanna tell me about those light tricks? |
| 01:48 |
erlehmann |
savilli btw if you want to find more s16 overflows, just use ubsan |
| 01:48 |
erlehmann |
set it to segfaulting with a message if you want to live admin life on hard mode |
| 01:51 |
MTDiscord |
<savilli> i know about sanitizers |
| 01:51 |
MTDiscord |
<savilli> but in my case simple running the server with ubsan doesn't show anything |
| 01:52 |
MTDiscord |
<savilli> need some malicious players whose try to get oob |
| 01:54 |
erlehmann |
savilli what server? i can try to goad some scum on oysterity into paying you a visit, by claiming that one is easy to crash. they are super gullible! |
| 01:54 |
MTDiscord |
<Warr1024> The only real light trick I used was making my world boundary nodes sunlight_propagates=true, which standard ignores don't do. It causes deep underground caves near the borders to get some extra light sources, which makes them a more interesting place to be and might drive up property values there. |
| 01:55 |
erlehmann |
> drive up property values |
| 01:55 |
erlehmann |
gentrification, deep underground |
| 01:55 |
erlehmann |
lol |
| 01:55 |
MTDiscord |
<Warr1024> Ha, well, there'd have to be a "market" for that to really work :-) |
| 01:55 |
erlehmann |
make the world smaller ig |
| 01:56 |
MTDiscord |
<Warr1024> I run a mod that does background lighting recalcs all the time, so I'm not concerned if I have to manually hack on the map to move the boundaries and it causes light to be wrong. |
| 01:57 |
MTDiscord |
<Warr1024> In a way, that might really be indicative of one of the most annoying "issue themes" I routinely run into: MT is designed to encourage people to do things on an "event-driven" basis, but then there are too many ways that events can be lost, leaving the world in an inconsistent state. |
| 01:58 |
MTDiscord |
<Warr1024> The only reliable workaround I've found for that is using globalsteps and ABMs to do background rechecks so that things can at least be eventually consistent. |
| 01:59 |
erlehmann |
> I run a mod that does background lighting recalcs all the time |
| 01:59 |
erlehmann |
enjoy your lag machines i guess |
| 02:00 |
MTDiscord |
<Warr1024> The only lag machine I've got so far is the way the engine processes ABMs |
| 02:00 |
MTDiscord |
<Warr1024> lighting calcs are weirdly cheap, actually |
| 02:00 |
erlehmann |
i believe 2b2t once had light based lag machines. a big sheet of nodes, then holes in them that you open and close with redstone. |
| 02:02 |
erlehmann |
savilli did you check out cheat clients? if not, try out waspsaliva. easy to get oob with it. |
| 02:03 |
MTDiscord |
<Warr1024> I've never seen one in the wild but actually just during this past day I removed the ability to toggle lights at 12Hz, now limited to 1 pulse every 2s |
| 02:04 |
erlehmann |
i have accidentally made lag machines |
| 02:04 |
erlehmann |
there is also the “remove any block if you can lag the server enough” thing, which i have not fully understood |
| 02:05 |
erlehmann |
but i believe it may be similar difficult in timing to my “i can remove mapgen blocks before they are converted to actual blocks by the game” trick |
| 02:06 |
erlehmann |
the problem is that if anything of that is possible, ppl have an incentive to lag the game |
| 02:07 |
erlehmann |
“if you lag a server hard enough, players remove anything even if it is forbidden” is kinda a motivation for evil ppl to lag stuff |
| 02:07 |
MTDiscord |
<Warr1024> how do you define a lag machine btw? Like being able to get an arbitrarily high lag within a single step, or do you just mean bogging down in general? |
| 02:07 |
erlehmann |
an ingame contraption that slows down server processing |
| 02:08 |
erlehmann |
not anymore specific |
| 02:08 |
MTDiscord |
<Warr1024> ah, okay. I've never seen lag machines in nodecore, but there are probably lag areas at least. |
| 02:09 |
erlehmann |
well sometimes ppl just figure out that you have to put in a lot of nodes of one type |
| 02:09 |
erlehmann |
like |
| 02:09 |
MTDiscord |
<Warr1024> At least it's possible to get the server step time up from 0.05 to about 0.25, if you play in one area and develop it long enough. I think a lot of that is due to ABM shittiness but I haven't been able to dig out exactly how to fix it. |
| 02:09 |
erlehmann |
take a node that makes entities or particle effects |
| 02:09 |
erlehmann |
if you want to see shitty abms, go to jungle in mcl2/mcl5/mcla |
| 02:10 |
erlehmann |
the vine growing abm is abysmal |
| 02:10 |
MTDiscord |
<Warr1024> In my case the problem isn't so much the abms being bad so much as that there are just a ton of them because pretty much everything in the game evolves over time in node form |
| 02:11 |
MTDiscord |
<Warr1024> I guess grass growing and leaf decay ones are probably pretty bad across most games, but I've probably got the worst possible cases |
| 02:22 |
erlehmann |
Warr1024 why are yours so bad? |
| 02:27 |
|
TempestMancer joined #minetest |
| 02:39 |
|
Extex joined #minetest |
| 02:46 |
MTDiscord |
<Warr1024> I dunno, but one thing I've discovered is that neighbors = { ... } is pretty painful, can increase an ABM's cost like 7x. |
| 02:56 |
erlehmann |
i thought it was supposed to make it cheaper lol |
| 03:28 |
|
queria^clone joined #minetest |
| 03:33 |
|
queria^clone joined #minetest |
| 03:38 |
MTDiscord |
<Warr1024> I think it's probably cheaper to do the neighbor check in C++ than it is to fire on every node and then do the check by hand in Lua. Only I'm not 100% sure about that, especially assuming LuaJIT, i.e. if the number of neighbors is small and you're very likely to have a match. |
| 03:43 |
|
Verticen joined #minetest |
| 03:46 |
|
v-rob joined #minetest |
| 04:03 |
erlehmann |
Warr1024 as always, benchmark it |
| 04:07 |
|
frostsnow joined #minetest |
| 04:32 |
|
frostsnow joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:00 |
ghoti |
Is there a way to remove a registered recipe that a mod has added? Sort of like I can `minetest.unregister_item()` in my own mod to remove other stuff, but I only want to take out the recipe and crafting guide entry. |
| 05:07 |
MTDiscord |
<Jonathon> if just crafting guide add not_in_creative_inventory = 1 in groups |
| 05:07 |
MTDiscord |
<Jonathon> otherwise minetest.clear_craft |
| 05:12 |
ghoti |
Thanks. |
| 05:18 |
|
frostsnow joined #minetest |
| 05:56 |
|
specing_ joined #minetest |
| 06:01 |
|
riff-IRC joined #minetest |
| 06:02 |
|
olliy joined #minetest |
| 06:55 |
|
norkle joined #minetest |
| 07:02 |
|
jvalleroy joined #minetest |
| 07:22 |
|
v-rob joined #minetest |
| 07:23 |
|
definitelya joined #minetest |
| 07:28 |
|
erlehmann joined #minetest |
| 07:35 |
|
v-rob joined #minetest |
| 07:43 |
erlehmann |
haha |
| 07:43 |
erlehmann |
i have found multiple crashes that occur because 31000 is too close to where users can be |
| 07:44 |
erlehmann |
figure this out for yourself lol |
| 07:45 |
definitelya |
Hi erle |
| 07:45 |
erlehmann |
hi |
| 07:46 |
definitelya |
Even though you like to play in environments that keep an adversarial stance, there's no need to antagonize the core devs... |
| 07:46 |
definitelya |
I understand it's frustrating for you, but you either apply to become core dev eventually, or leave them be a bit, you feel me? |
| 07:46 |
erlehmann |
i said “if you do not fix the signed integer overflow, bugs will happen”, i am just exploring the new bug space between 31000 and 32767 or so |
| 07:47 |
erlehmann |
look i want a game that does not crash |
| 07:47 |
definitelya |
Yes I just look out for contributors that's all... |
| 07:47 |
definitelya |
like you |
| 07:47 |
erlehmann |
if i can find crashes, so can ppl who are way more annoying than i am |
| 07:47 |
definitelya |
No need to be silenced forever if you have things to contribute. |
| 07:49 |
erlehmann |
definitelya look i decided to only reporting boundary bugs anymore if i have a working fix for them. |
| 07:50 |
definitelya |
ok good idea |
| 07:50 |
erlehmann |
i mean in this case i may still decide to report it anyway |
| 07:50 |
erlehmann |
because it is deliciously ironic |
| 07:51 |
erlehmann |
then again i have reported https://github.com/minetest/minetest/issues/11828 already |
| 07:51 |
erlehmann |
but that's not a crash |
| 07:51 |
definitelya |
Careful with being too ironic on a serious project though. |
| 07:53 |
erlehmann |
ok how about i report it without telling how to trigger it |
| 07:53 |
erlehmann |
i think that's a good idea to make ppl fix the actual problem |
| 07:54 |
definitelya |
dunno sorry, I hope you see eye to eye I guess. |
| 07:54 |
erlehmann |
wdym |
| 07:55 |
definitelya |
I'm no core dev ahah. |
| 07:55 |
definitelya |
or dev |
| 07:55 |
erlehmann |
fine, i make a bug report! |
| 08:07 |
|
CWz_ joined #minetest |
| 08:28 |
|
appguru joined #minetest |
| 08:35 |
|
v-rob joined #minetest |
| 09:04 |
erlehmann |
definitelya here! https://github.com/minetest/minetest/issues/11835 |
| 09:23 |
definitelya |
ok |
| 09:26 |
|
tech_exorcist joined #minetest |
| 09:32 |
|
calcul0n joined #minetest |
| 09:40 |
|
tech_exorcist joined #minetest |
| 09:41 |
|
Fleckenstein joined #minetest |
| 10:02 |
|
YuGiOhJCJ joined #minetest |
| 10:04 |
|
Talkless joined #minetest |
| 11:04 |
|
GNUHacker joined #minetest |
| 11:27 |
|
tech_exorcist joined #minetest |
| 11:33 |
|
Fleckenstein joined #minetest |
| 11:48 |
|
AristotIe joined #minetest |
| 12:01 |
|
olliy joined #minetest |
| 12:16 |
|
Fixer joined #minetest |
| 12:20 |
|
MTDiscord joined #minetest |
| 12:27 |
|
TempestMancer joined #minetest |
| 12:31 |
|
jadzia joined #minetest |
| 13:34 |
MinetestBot |
[git] richyliu -> minetest/minetest: Fix wireshark packet dissector wrong coordinates (#11826) 7a043b3 https://git.io/JMFeF (2021-12-05T13:34:40Z) |
| 13:35 |
|
GNUHacker left #minetest |
| 13:42 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Fix various code & correctness issues (#11815) ff934d5 https://git.io/JMFfc (2021-12-05T13:40:30Z) |
| 14:15 |
|
SuperMiner joined #minetest |
| 15:30 |
|
hook54321 joined #minetest |
| 15:32 |
Swift110-mobile |
oh someone posted the podcast before me. cool Yeah I listened to it and liked the honest comments that came from it |
| 15:32 |
|
tech_exorcist joined #minetest |
| 15:34 |
|
tech_exorcist joined #minetest |
| 15:49 |
|
kamdard joined #minetest |
| 15:50 |
|
specing joined #minetest |
| 16:41 |
|
Verticen joined #minetest |
| 16:48 |
|
TempestMancer joined #minetest |
| 17:00 |
|
Sven_vB_ joined #minetest |
| 17:04 |
|
est31 joined #minetest |
| 17:08 |
|
Extex joined #minetest |
| 17:24 |
|
Extex joined #minetest |
| 17:29 |
|
calcul0n joined #minetest |
| 17:31 |
|
calcul0n joined #minetest |
| 17:41 |
|
olliy joined #minetest |
| 17:44 |
|
dabbill joined #minetest |
| 17:58 |
|
specing joined #minetest |
| 17:59 |
|
v-rob joined #minetest |
| 18:21 |
|
garywhite joined #minetest |
| 18:21 |
|
garywhite joined #minetest |
| 18:24 |
|
v-rob joined #minetest |
| 18:43 |
|
Taoki joined #minetest |
| 19:10 |
|
MTDiscord joined #minetest |
| 19:36 |
|
Taoki joined #minetest |
| 19:50 |
|
v-rob joined #minetest |
| 19:53 |
|
_Fleckenstein_ joined #minetest |
| 19:56 |
|
_Fleckenstein_ joined #minetest |
| 19:57 |
|
EliasFleckenstei joined #minetest |
| 19:58 |
|
Fleckenstein joined #minetest |
| 20:11 |
|
Extex joined #minetest |
| 21:12 |
erlehmann |
can we talk about https://github.com/minetest/minetest/issues/11839 please? |
| 21:12 |
erlehmann |
this is serious |
| 21:13 |
erlehmann |
if any admin has this condition in their logs i'd be interested |
| 21:14 |
MTDiscord |
<Sublayer plank> I mean... default configured minetest also logs every single node change made by players to debug.txt iirc |
| 21:15 |
erlehmann |
but does it complain >18000 times about every single thing? |
| 21:15 |
erlehmann |
the disk filling thing is not the main problem |
| 21:15 |
erlehmann |
> More seriously, the server being occupied with logging stuff seems to lag it so hard that in minetest_game sand does not even fall down anymore and the map generator seems to stop working (though that may have been due to the disk filling up). |
| 21:16 |
MTDiscord |
<Sublayer plank> yikes, that sounds way worse |
| 21:16 |
erlehmann |
well, not a security issue, right? ;) |
| 21:16 |
erlehmann |
juuuuuut a denial of service |
| 21:17 |
erlehmann |
ironically, i would not have been able to easily trigger this if entities were legal at that position |
| 21:18 |
erlehmann |
my advice (that will probabl be disregarded) is to let the entity be there, if it's too far out it won't be saved in a mapblock anyway (bc you don't have a mapblock) |
| 21:19 |
erlehmann |
for the case of x>31000.0 unfortunately it is entirely possible to have a mapblock there |
| 21:20 |
erlehmann |
as i said before: the zone in which stuff stops working should ideally be *far* away from the zone where mapgen stops working |
| 21:20 |
erlehmann |
otherwise you have a new funny boundary that is worse than the old |
| 21:20 |
erlehmann |
(and players can get close to it and do stupid shit) |
| 21:27 |
|
Taoki joined #minetest |
| 21:31 |
erlehmann |
celeron55 https://github.com/minetest/minetest/issues/11837#issuecomment-986303933 |
| 21:52 |
|
v-rob joined #minetest |
| 22:11 |
|
Wikiwide_ joined #minetest |
| 22:31 |
|
calcul0n joined #minetest |
| 23:00 |
|
Sven_vB joined #minetest |
| 23:08 |
MTDiscord |
<luatic> erlehmann: according to google translate it roughly says "it's working fine now" - looks like a local megacommit a decade ago to me |
| 23:10 |
erlehmann |
oh |
| 23:10 |
erlehmann |
the question is what celeron55 wanted to achieve |
| 23:10 |
erlehmann |
if you tear down a fence, it is good to know why it was built (even if you disagree) |
| 23:17 |
celeron55 |
what |
| 23:18 |
celeron55 |
i don't see a 2 second delay in commit c707e00 |
| 23:19 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Fix get_bone_position() on unset bones modifying their position d9d2193 https://git.io/JMbu5 (2021-12-05T23:06:49Z) |
| 23:21 |
|
Verticen joined #minetest |
| 23:31 |
erlehmann |
celeron55 do: git show c707e00 |grep 'counter >= 2.0' -C8 |
| 23:31 |
erlehmann |
is counter >= 2.0 not 2 seconds? |
| 23:32 |
|
Fixer_ joined #minetest |
| 23:37 |
celeron55 |
well it's obviously a workaround to some condition in the threading system that happened and i couldn't figure out why |
| 23:38 |
celeron55 |
in that commit emergethread is triggered elsewhere without any delay |
| 23:38 |
celeron55 |
as you should have noticed already |
| 23:38 |
celeron55 |
which seems to be the way it's designed to work but not always does |
| 23:40 |
erlehmann |
celeron55 i see. have you ever compiled minetest with thread sanitizer or similar? |
| 23:40 |
celeron55 |
that part doesn't seem to exist in current master |
| 23:40 |
erlehmann |
what part? |
| 23:40 |
celeron55 |
the part where emergethread would be triggered without delay |
| 23:40 |
erlehmann |
ah |
| 23:41 |
celeron55 |
RemoteClient::GetNextBlocks |
| 23:41 |
celeron55 |
that's where it was then |
| 23:41 |
celeron55 |
i might be missing something though |
| 23:42 |
celeron55 |
what's currently done is emerge->enqueueBlockEmerge() is called, and that one calls thread->signal() |
| 23:43 |
celeron55 |
which probably should do the same thing as what server->m_emergethread.trigger() did back then |
| 23:43 |
erlehmann |
btw, i think it is unwise to put a lot of small bugfixes in a single commit like here: https://github.com/minetest/minetest/pull/11815/files – there is no description for each change and if even one of them turns out to be wrong you have no way to just revert the commit cleanly |
| 23:44 |
erlehmann |
celeron55 i have no idea how threading is supposed to work, i almost always write forkbombs when i deal with more than one strand of execution :D |
| 23:44 |
celeron55 |
thread->signal() probably doesn't work when the thread is dead for some reason and the intention currently seems to be that the thread would never die |
| 23:44 |
celeron55 |
but for some reason the thread ends |
| 23:44 |
celeron55 |
and then nobody other than the ancient workaround can create it again |
| 23:44 |
erlehmann |
that sounds unfortunate |
| 23:46 |
celeron55 |
someone needs to decide whether it should be allowed to end or not, and modify the calling code accordingly |
| 23:46 |
celeron55 |
or the thread |
| 23:46 |
erlehmann |
celeron55, query |
| 23:58 |
MTDiscord |
<luatic> the ancient workaround probably had such an intention, but wouldn't follow up on it as a flag is set after the first call (as I have outlaid in the issue) |
