Time Nick Message 00:00 erlehmann zughy removed the file here by means of commit, not by rebase https://github.com/minetest/minetest/pull/11922 00:02 erlehmann what i want to say: the PR is now cringe and needs to be rebased to be based. or you squash it on merge ig 09:14 MTDiscord squash on merge is a good strategy to make it based 09:16 MTDiscord sfan5: regarding the raycast PR - I don't like it. It seems to correctly clamp the end pos, but will simply return nothing for out-of-bounds start pos. I commented on how to implement this consistently and with way less code, without changing the ray direction or aborting. 09:22 MTDiscord how is it less code lel? 09:29 MTDiscord you're effectly reimplementing part of a ray-box-intersection with your odd max extent calculations 09:31 MTDiscord then you need to put my "odd" max extent calculations into boxLineCollision 09:33 MTDiscord no 09:33 MTDiscord I have already laid out how boxLineCollision is fully sufficient by intersecting the out-of-bounds raycast with the map boundary box 09:34 MTDiscord don't be stupid 09:34 MTDiscord you need to find the nearest collision, not just any 09:34 MTDiscord and that's exactly what it does! 09:35 MTDiscord first of all, if the point is inside map bounds, it will simply be returned as "collision point" - fully as expected 09:35 MTDiscord and if not? 09:35 MTDiscord hmmm, let me have a closer look 09:36 MTDiscord but the raycast surely does return the closest intersection point 09:36 MTDiscord pretty sure it does find the closest intersection point actually 09:37 MTDiscord it basically ignores "backfaces" in it's current form, and a ray can only intersect a single frontface 09:53 MTDiscord it does the exact opposite 09:54 MTDiscord you're wrong 09:54 MTDiscord no u 09:55 MTDiscord look which boxes it intersects https://github.com/minetest/minetest/blob/c4371f50621f2ce81a5f5f0869955989610ef5c6/src/environment.cpp#L253 09:55 MTDiscord Reasons why I am right and you are wrong: 1. The code literally says it 2. That's how raycasts behave 09:55 MTDiscord savilli: that's completely irrelevant 09:55 MTDiscord ofc it's 09:55 MTDiscord we only want to use it to find an intersection with a single box 09:56 MTDiscord also btw, there's additional code to ensure the nearest collision is picked: https://github.com/minetest/minetest/blob/c4371f50621f2ce81a5f5f0869955989610ef5c6/src/environment.cpp#L262-L270 09:57 MTDiscord yes, the nearest position for all the boxes 09:57 MTDiscord that's irrelevant 09:57 MTDiscord my point still stands: given a box and a line segment, boxLineCollision returns either the start pos if it is within the box, or the pos closest to the start pos on the ray and within the box (on the box boundary). 09:57 MTDiscord yes, as I was saying 09:58 MTDiscord so just use boxLineCollision to determine intersection point and exit point 09:58 MTDiscord you definitely don't hear me 09:59 MTDiscord ok, let's follow the code 09:59 MTDiscord you seem to be misunderstanding mer 10:00 MTDiscord you initially implemented simple clamping 10:00 MTDiscord the problem with that was that it changed the ray direction 10:00 MTDiscord so now, if the start is out of bounds, you simply abort the ray 10:01 MTDiscord if it is within bounds, you calculate the max extent and properly clamp the ray, not changing it's direction 10:01 MTDiscord I'm saying this should both start & end pos of the ray should be "clamped" in such a way that direction is preserved 10:02 MTDiscord i'm not arguing with that 10:02 MTDiscord To achieve this, we need to obtain the line segment that intersects the map boundaries. 10:02 MTDiscord start point also can be clamped 10:02 MTDiscord i'm arguing that boxLineCollision doesn't work that way 10:02 MTDiscord But it does 10:03 MTDiscord how if it serves different purpose 10:03 MTDiscord It returns the "first" (nearest and only frontface) intersection of a line with the given box 10:03 MTDiscord it doesn't serve a different purpose 10:03 MTDiscord do i need to draw that? 10:05 MTDiscord Look, even if you wanted to treat it as a black box, it's usage here https://github.com/minetest/minetest/blob/c4371f50621f2ce81a5f5f0869955989610ef5c6/src/environment.cpp#L253 is enough to infer what it does 10:05 MTDiscord You still haven't explained what it does differently according to you. 10:05 MTDiscord it finds the wrong point 10:06 MTDiscord ok i give up 10:06 MTDiscord let's wait for sfan5 to judge 10:06 MTDiscord it finds the right point, otherwise raycasts wouldn't work 10:06 MTDiscord he wanted to do smth with the pr anyways 10:06 MTDiscord what is the "wrong point" according to you? the point on the backface? 10:07 MTDiscord yeah 10:07 MTDiscord dewit this shall go into modlib 10:07 MTDiscord if we understand backface equally 10:08 MTDiscord backface from the perspective of the ray 10:08 MTDiscord the ray has a start point and a direction right? 10:09 MTDiscord that is, dot product of face normal and ray normal / direction is more than zero 10:09 MTDiscord (in other words, face normal and ray normal point in roughly the same direction) 10:10 MTDiscord we don't need that 10:10 MTDiscord let's use the intersection with the planes with constant Z (XY planes) 10:11 MTDiscord if dir.Z > 0, it uses the min edge, which is the front face: it's normal must be negative 10:12 MTDiscord if it's normal was positive, it would point towards the max edge 10:13 MTDiscord oh i find my mistake 10:13 MTDiscord yeah it works 10:14 MTDiscord the trick is inverted direction 10:15 MTDiscord I had already started drawing lol 10:15 MTDiscord that makes a little less code 10:16 MTDiscord we still need https://github.com/minetest/minetest/pull/11831/files#diff-590af414910265f626360ae9f5d46f534f75a56082a1cdc8a4921ccdbc05804eR157 unfortunately 10:16 MTDiscord for start point as well then 10:17 MTDiscord ah yes, those pesky rounding errors... 10:19 MTDiscord i think VoxelLineIterator doesn't even need floats 10:19 MTDiscord it iterates over blocks anyways 10:19 MTDiscord don't round though, that might slightly change the direction of the ray 10:20 MTDiscord can it? 10:20 MTDiscord i think we would "touch" the same blocks 10:21 MTDiscord well, the question is: at which point do you round? 10:22 MTDiscord you may not round start or end pos, but you must round calculated poses on the ray 10:23 MTDiscord actually more interesting question 10:24 MTDiscord what to do if raycast doesn't even intersect with map limit box 10:24 MTDiscord we will still silently abort 10:24 MTDiscord yes, and we should 10:25 MTDiscord IMO that's 100% reasonable: outside of map means no intersections 10:25 MTDiscord basically, treat everything outside of the map as nothingness/void/whatever 10:25 MTDiscord lel you edited that 10:26 MTDiscord very fast hand 10:53 sfan5 I was thinking it's easier to fix the number overflow in the raycast code than find the best way to clip the input ray 10:53 MTDiscord does erlehmann bite you? :D 10:54 sfan5 heh 10:56 erlehmann i have no idea what this idiom means 10:56 erlehmann i am in general in favor of fixing overflow opportunities though 10:57 erlehmann btw, does anyone of you have access to an aarch64 machine to test some minetest stuff? a friend borrowed my reform for development 10:57 erlehmann so i only have several x86 and one x64_86 machine (that is not mine) right now 10:57 MTDiscord we can fix the problematic for, but how to make sure it's the only place with the problem? 10:58 MTDiscord for example this https://github.com/minetest/minetest/blob/a106bfd456509b676ccba0ac9bef75c214819028/src/voxelalgorithms.h#L145 looks sus 10:58 MTDiscord erlehmann: I suppose the meaning of the idiom in this case is in the "transmission of overflow fixing disease" 10:58 erlehmann luatic like a vampire that turns its victims into people who want to fix signed int overflow! 10:59 erlehmann savilli the “how to make sure it is the only place with the problem” part is why i suggested to make the boundaries for every algorithm the boundaries of the underlying datatype. because then UBsan will help you. 10:59 MTDiscord sure hackers will wait until i turn on ubsan on the server 10:59 erlehmann you misunderstand 11:00 MTDiscord UBsan slows things down to a crawl, it's only for testing 11:00 erlehmann you can compile minetest with ubsan and run unit tests. or compile it with ubsan and abuse the code with afl. 11:00 erlehmann luatic actually, ubsan does not slow down things much, it is about as much as -fwrapv woud do – add checks at every opportunity. what it does, though, is blow the binary up to >100MB if you are not careful. 11:00 MTDiscord sfan5: how about we fix the for and call it ready for 5.5.0? 11:01 erlehmann i run minetest with ubsan by default on a thinkpad from 2006, so. 11:01 MTDiscord the big pr will wait for better times 11:02 erlehmann savili, there is a fast method for ubsan which turns every ub into a segfault. that is the only thing i would suggest for production from the ubsan stuff – and only for people who prefer a crashed server to a server in an undefined state. 11:02 erlehmann which honestly will not be many 11:03 MTDiscord my name is savilli, also i'm sure you would catch much 11:03 sfan5 @savilli if you fix the for loop a big PR shouldn't be needed 11:03 MTDiscord how are you sure? 11:03 sfan5 I am not 11:04 MTDiscord some ub stuff can be triggered only by hacked clients 11:05 sfan5 the primary concern is having out-of-bounds raycasts not freeze 11:05 erlehmann regarding the raycast thing, i am pretty sure that you do not need a hacked client for it. mineclone2 switched buckets to raycast. 11:05 sfan5 if you can trick a mod into doing a raycast with truly insane values that's more likely to be a mod bug (missing validation) 11:05 erlehmann since mineclone2 is *somewhat* popular, just point a bucket out of the map, poof! 11:07 MTDiscord well the freeze is the main concern for me 11:09 erlehmann also i think some mobs use line-of-sight calculations, sfan5 is spot-on with that tricking a mod into doing the dirty work for you is how most bullshit is achieved by griefers 11:13 MTDiscord looks like we don't have many options 11:14 MTDiscord if we want a working raycast, we have to clamp somewhere 11:14 MTDiscord it can be VoxelLineIterator, but i don't think it's important 11:16 MTDiscord just casually found s16 overflow, there https://github.com/minetest/minetest/blob/f66ed2c27fa0f351ffb458224af74f3371d6f4ac/src/voxelalgorithms.cpp#L1324 should be s32 11:18 erlehmann savilli there's a bunch of such stuff. check out #11752 for an example. 11:18 ShadowBot https://github.com/minetest/minetest/issues/11752 -- src/voxel.h getVolume() multiplies three signed 32-bit integers and claims that the result will fit into a signed 32-bit integer, too 11:19 erlehmann i maintain my position that the CI should compile and run the unit tests using UBsan on a purely advisory bases (i.e. not block merges bc of that) 11:19 erlehmann basis 11:27 sfan5 merging #11922 when I have rebooted 11:27 ShadowBot https://github.com/minetest/minetest/issues/11922 -- Allow resetting celestial vault elements by leaving its arguments empty by Zughy 11:42 sfan5 that is now 12:20 erlehmann https://git.minetest.land/MineClone2/MineClone2/pulls/1961 12:20 erlehmann > While the naming hack certainly is one of the more ugly parts of MineClone2, it does work and has done so consistently since it was introduced almost 4 years ago. While it relies on undocumented behavior I doubt the Minetest devs would do anything to break it. 12:21 erlehmann uh, what *exactly* should i tell them? 12:21 erlehmann (i'm pretty sure it will be broken some time) 12:35 sfan5 wasn't it you who complained that #11438 broke MCL2? 12:35 ShadowBot https://github.com/minetest/minetest/issues/11438 -- Mods: Improve mod loading priorities (2nd) by SmallJoker 12:36 erlehmann probably. but i was of the impression that there are plans to move forward with it. was i wrong? 12:37 erlehmann > There's an inherent problem with on_mods_loaded callbacks which is that if any of them modify any part of the global state, then that creates something like a race condition where the behaviour of the callbacks is dependent on the order in which they happen to be called. 12:37 erlehmann this race is what the leading underscore hack avoids 12:38 erlehmann > the reason for the _mcl_autogroups naming hack is that, to work correctly, the code in _mcl_autogroups needs to be run after all other mods have loaded, but before all on_mods_loaded callbacks defined by other mods 12:39 erlehmann to be clear, if anyone of you has any idea how to solve this cleanly, i am pretty sure mcl* games would take that solution 12:41 sfan5 have all your game mods call mcl_autogroups.do_whatever_is_needed() at the end of their body 12:42 MTDiscord table.insert(minetest.registered_on_mods_loaded, 1, ... in _mcl_autogroups? 12:42 erlehmann it modifies the dig times for all nodes and all tools, which makes it a bit hard to add that to … all minetest mods that add tools and nodes. 12:43 erlehmann thankfully it is obvious if it fails, because then digging nodes does not work at all 12:44 erlehmann this would all be easier if it did not have to work with non-mcl mods at all 12:45 sfan5 if this is so important why not redefine minetest.register_tool? 12:48 erlehmann uh, wouldn't this turn the problem into “how to ensure that a mod can redefine minetest.register_tool before any other mod loads”? 12:50 sfan5 I was assuming every mod that mattered could depend on mcl_autogroup 12:50 sfan5 but you could certainly make this work at any point in time by 1) modifying all tools thus far and 2) redefining register_tools for all tools to come 12:58 erlehmann how were those hyperlinks for s16 and s32 added there? this seems like a bug at best https://irc.minetest.net/minetest-dev/2022-01-22#i_5925795 12:58 erlehmann the s16 link goes to http://perlcabal.org/syn/S16.html … how is this even possible? 13:05 sfan5 ilbot was originally written for a perl community so it does seem possible that it'd contain utilities to link perl module docs 13:06 sfan5 first time I'm seeing this either, tho 13:06 sfan5 s/either/too/ 13:08 erlehmann site seems to have been squatted though 13:12 MTDiscord sfan5: so what does stop you from approving 11831? 13:12 MTDiscord do you agree that we need to clamp coords to make raycast work? 13:15 sfan5 like I said I think if the overflow issue is fixed we won't need this complicated clamping 13:17 MTDiscord raycast wouldn't freeze, but wouldn't work either 13:18 MTDiscord no way to fix raycast that points out of the map without clamping 13:20 MTDiscord raycast is complicated by itself, so no wonder that corner cases are complicated too 13:21 erlehmann going outside of the map is a literal edge cases hehe 13:22 MTDiscord and we can reuse boxLineCollision to remove some wheel reinvention 13:22 MTDiscord so what does bother you? 13:30 sfan5 I haven't looked at it in detail so I can only say that I'm hoping to find a simpler solution 13:40 MTDiscord are you going to look, or what's your plan? 13:41 MTDiscord as i see it blocks 5.5.0 release, so smth needs to be done 14:00 sfan5 of course I am going to look, there's still 7 days of time even 14:08 MTDiscord okii, will wait then 14:09 MTDiscord time passes quickly :D 14:32 MTDiscord A lot* happens in 7 days haha 15:47 HuguesRoss Merging #11983 in 130min, if no-one objects 15:47 ShadowBot https://github.com/minetest/minetest/issues/11983 -- Fix consistency of sky sun/moon texture behaviour by sfan5 15:47 HuguesRoss *30min 17:33 x2048 Merging #11984 in 10 min... 17:33 ShadowBot https://github.com/minetest/minetest/issues/11984 -- Make sure nightRatio is always greater than zero. by x2048 17:41 erlehmann x2048 what exactly triggers that? 17:45 x2048 erlehmann, having an AMD or Nvidia card and using shadows 17:46 erlehmann x2048 so this has nothing to do with, say, night vision or blindness mods that play with the night ratio? 17:47 erlehmann just wanna make sure those are considered 17:50 x2048 erlehmann, no, that's not _that_ nightRatio :) 17:52 x2048 And now it's done 17:54 erlehmann x2048 oh okay! 17:58 lhofhansl And now 11944 needs a rebase :( 18:02 x2048 erlehmann, poor choice of name it is, the variable carries the portion for artificial light in the fragment's color. 18:02 erlehmann x2048 can it not be renamed easily? 18:05 Pexin I had an instructor who insisted the hardest part of programming is decent names for vars and funcs 18:05 lhofhansl Caching and naming are the hardest problems in software engineering :) 18:06 x2048 lhofhansl, not anymore 18:08 x2048 I mean, 11944 is rebased now. Naming and proper caching are complex, yes. 18:09 lhofhansl How can we make 11944 be opt-out for games? I think that would satisfy all the concerns raised, and still allow user to enable shadows (as long as games do not care) 18:09 erlehmann there are two hard problems in software engineering: caching, naming things, and off-by-one-errors 18:10 lhofhansl Hehe. 18:10 lhofhansl Did you get a chance to try #11933? 18:10 ShadowBot https://github.com/minetest/minetest/issues/11933 -- A light_source should not override sunlight. by lhofhansl 18:10 erlehmann oh, i forgot 18:11 erlehmann i am actually debugging sunlight detectors right now, here: https://git.minetest.land/Mineclonia/Mineclonia/pulls/236 18:11 erlehmann so it fits 18:12 lhofhansl Cool 18:26 MTDiscord erlehmann: you multi forgot threading 18:27 erlehmann ^^ 18:34 erlehmann lhofhansl okay so if i understand it correctly, a torch above a node makes it have natural light level 13 now without your patch and light level 14 with your patch. am i correct? or do i need a lower light source, like, say, a mushroom in direct sunlight? (light level 1) 18:37 erlehmann i am going to test that anyway! 18:37 lhofhansl That would be unchanged, actually. 18:40 lhofhansl Wait no. The question is placing a torch in a sunlit place? 18:40 erlehmann yes. so what exactly can i place above a node so that get_natural_light() for that node returns a difference? 18:40 lhofhansl Any node that passes light and is a light source. 18:41 erlehmann do we have such a node in devtest? the various light sources look transparent enough, right? 18:41 lhofhansl (but not propagates_sunlight, that is for a different reason) 18:41 erlehmann devtest torch ig 18:41 erlehmann uh 18:41 lhofhansl I'd have to look. Should probably add one. 18:42 erlehmann if there isn't one, it would be a good idea. otherwise, please tell me. i have been debugging mesecons-derived daylight detection for the past hour or so. 18:42 erlehmann a LOT of people are confused about minetest.LIGHT_MAX and assume it is sunlight btw 18:42 erlehmann might make sense to expose minetest.LIGHT_SUN tbh 18:42 lhofhansl The main problem is that the lighting logic in MapNode and the light spreading logic in mapgen follow different rules. 18:43 erlehmann problem in what way? get_light will get you different stuff from what you see, i assume? 19:12 erlehmann lhofhansl just get back to me once you know how to reproduce the difference in devtest, okay? meanwhile i will play around, but i think it is really important to figure out if this actually affects anything like solar panels or daylight detector in a negative way. i will try to figure out if someone is already relying on that effect in some way. if so, they should probably update their mod, lol. 19:12 lhofhansl The water instructions won't work? (Need the default game) 19:13 erlehmann lhofhansl the water instructions do not help me much, because water flows downwards and i need to be able to see and point and diagnose the node below. 19:14 erlehmann just like i did right now 19:14 lhofhansl fair enough 19:14 erlehmann i already know that right now, in minetest 5.4.1, glass will have a light level of 15 in direct sunlight 19:14 erlehmann but a solid node will have a get_node_light() result of 14 19:14 erlehmann i have some snippets for the sunlight detection thing already 19:15 erlehmann so any node would help that is a) is in devtest b) does not spam water below it 19:15 erlehmann i bet devtest already has one, i just don't know which one it would be 19:18 erlehmann lhofhansl i would also propose to add a lua unit test to devtest. i can actually write one, if you want me to. 19:20 lhofhansl I'll take you up on that if that is OK. 19:22 erlehmann lhofhansl i offered it! 19:22 erlehmann lhofhansl also that test will be important for mods if the behaviour changes in any observable way. 19:25 lhofhansl Exactly. Thanks! 19:29 Pexin lhofhansl: could you clarify? did you mean "passes light" is not the same as propagates_sunlight ? 19:30 Pexin or did you mean that transparency has nothing to do with propagates_sunlight ? 19:33 lhofhansl Sorry I meant transparent. 19:34 Pexin ok thanks for making it clear (dohoho) 19:37 lhofhansl :) 19:52 MTDiscord lhofhansl, reg. 11944, the opt-out behavior diverts from our priority as a game platform/engine, and with a mod in contentdb even not-so-tech-savvy players will be able to enable shadows. 19:53 lhofhansl Alright :) 19:57 MTDiscord I want to change the API to player:set_lighting({shadows={intensity=0.5}, ambient_light={color="#ff8080", brightness=0.08}}) 19:58 MTDiscord To give space to future improvements outlined by erlehmann 20:00 lhofhansl Yep. I also think we should add fogstart and saturation to this (or similar API). That would make a wonderful atmospheric API. 20:01 lhofhansl (in the end, then, we'd also want to control settings light wave-height, waving-plants, etc, via an API, but that's a different discussion) 20:06 x2048 good, I'll give it a shot 23:29 sfan5 #11985 23:29 ShadowBot https://github.com/minetest/minetest/issues/11985 -- [NO SQUASH] FPS limiter / Windows fixes by sfan5 23:48 sfan5 merging #11982, #11980 soon 23:48 ShadowBot https://github.com/minetest/minetest/issues/11982 -- Cancel emerge callbacks on shutdown by TurkeyMcMac 23:48 ShadowBot https://github.com/minetest/minetest/issues/11980 -- Bump formspec version by v-rob