| 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 |
| 00:11 |
|
proller joined #minetest-dev |
| 00:22 |
|
proller joined #minetest-dev |
| 00:40 |
|
Alias2 joined #minetest-dev |
| 02:41 |
|
Toothless joined #minetest-dev |
| 03:00 |
|
v-rob joined #minetest-dev |
| 03:29 |
|
queria^clone joined #minetest-dev |
| 03:34 |
|
queria^clone joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 07:52 |
|
jordan4ibanez joined #minetest-dev |
| 09:14 |
MTDiscord |
<savilli> squash on merge is a good strategy to make it based |
| 09:16 |
MTDiscord |
<luatic> 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 |
<savilli> how is it less code lel? |
| 09:29 |
MTDiscord |
<luatic> you're effectly reimplementing part of a ray-box-intersection with your odd max extent calculations |
| 09:31 |
MTDiscord |
<savilli> then you need to put my "odd" max extent calculations into boxLineCollision |
| 09:33 |
MTDiscord |
<luatic> no |
| 09:33 |
|
tekakutli joined #minetest-dev |
| 09:33 |
MTDiscord |
<luatic> 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 |
<savilli> don't be stupid |
| 09:34 |
MTDiscord |
<savilli> you need to find the nearest collision, not just any |
| 09:34 |
MTDiscord |
<luatic> and that's exactly what it does! |
| 09:35 |
MTDiscord |
<luatic> first of all, if the point is inside map bounds, it will simply be returned as "collision point" - fully as expected |
| 09:35 |
MTDiscord |
<savilli> and if not? |
| 09:35 |
MTDiscord |
<luatic> hmmm, let me have a closer look |
| 09:36 |
MTDiscord |
<luatic> but the raycast surely does return the closest intersection point |
| 09:36 |
MTDiscord |
<luatic> pretty sure it does find the closest intersection point actually |
| 09:37 |
MTDiscord |
<luatic> it basically ignores "backfaces" in it's current form, and a ray can only intersect a single frontface |
| 09:53 |
MTDiscord |
<savilli> it does the exact opposite |
| 09:54 |
MTDiscord |
<luatic> you're wrong |
| 09:54 |
MTDiscord |
<savilli> no u |
| 09:55 |
MTDiscord |
<savilli> look which boxes it intersects https://github.com/minetest/minetest/blob/c4371f50621f2ce81a5f5f0869955989610ef5c6/src/environment.cpp#L253 |
| 09:55 |
MTDiscord |
<luatic> Reasons why I am right and you are wrong: 1. The code literally says it 2. That's how raycasts behave |
| 09:55 |
MTDiscord |
<luatic> savilli: that's completely irrelevant |
| 09:55 |
MTDiscord |
<savilli> ofc it's |
| 09:55 |
MTDiscord |
<luatic> we only want to use it to find an intersection with a single box |
| 09:56 |
MTDiscord |
<luatic> 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 |
<savilli> yes, the nearest position for all the boxes |
| 09:57 |
MTDiscord |
<savilli> that's irrelevant |
| 09:57 |
MTDiscord |
<luatic> 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 |
<luatic> yes, as I was saying |
| 09:58 |
MTDiscord |
<luatic> so just use boxLineCollision to determine intersection point and exit point |
| 09:58 |
MTDiscord |
<savilli> you definitely don't hear me |
| 09:59 |
MTDiscord |
<savilli> ok, let's follow the code |
| 09:59 |
MTDiscord |
<luatic> you seem to be misunderstanding mer |
| 10:00 |
MTDiscord |
<luatic> you initially implemented simple clamping |
| 10:00 |
MTDiscord |
<luatic> the problem with that was that it changed the ray direction |
| 10:00 |
MTDiscord |
<luatic> so now, if the start is out of bounds, you simply abort the ray |
| 10:01 |
MTDiscord |
<luatic> if it is within bounds, you calculate the max extent and properly clamp the ray, not changing it's direction |
| 10:01 |
MTDiscord |
<luatic> 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 |
<savilli> i'm not arguing with that |
| 10:02 |
|
x2048 joined #minetest-dev |
| 10:02 |
MTDiscord |
<luatic> To achieve this, we need to obtain the line segment that intersects the map boundaries. |
| 10:02 |
MTDiscord |
<savilli> start point also can be clamped |
| 10:02 |
MTDiscord |
<savilli> i'm arguing that boxLineCollision doesn't work that way |
| 10:02 |
MTDiscord |
<luatic> But it does |
| 10:03 |
MTDiscord |
<savilli> how if it serves different purpose |
| 10:03 |
MTDiscord |
<luatic> It returns the "first" (nearest and only frontface) intersection of a line with the given box |
| 10:03 |
MTDiscord |
<luatic> it doesn't serve a different purpose |
| 10:03 |
MTDiscord |
<savilli> do i need to draw that? |
| 10:05 |
MTDiscord |
<luatic> 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 |
<luatic> You still haven't explained what it does differently according to you. |
| 10:05 |
MTDiscord |
<savilli> it finds the wrong point |
| 10:06 |
MTDiscord |
<savilli> ok i give up |
| 10:06 |
MTDiscord |
<savilli> let's wait for sfan5 to judge |
| 10:06 |
MTDiscord |
<luatic> it finds the right point, otherwise raycasts wouldn't work |
| 10:06 |
MTDiscord |
<savilli> he wanted to do smth with the pr anyways |
| 10:06 |
MTDiscord |
<luatic> what is the "wrong point" according to you? the point on the backface? |
| 10:07 |
MTDiscord |
<savilli> yeah |
| 10:07 |
MTDiscord |
<luatic> dewit this shall go into modlib |
| 10:07 |
MTDiscord |
<savilli> if we understand backface equally |
| 10:08 |
MTDiscord |
<luatic> backface from the perspective of the ray |
| 10:08 |
MTDiscord |
<savilli> the ray has a start point and a direction right? |
| 10:09 |
MTDiscord |
<luatic> that is, dot product of face normal and ray normal / direction is more than zero |
| 10:09 |
MTDiscord |
<luatic> (in other words, face normal and ray normal point in roughly the same direction) |
| 10:10 |
MTDiscord |
<savilli> we don't need that |
| 10:10 |
MTDiscord |
<luatic> let's use the intersection with the planes with constant Z (XY planes) |
| 10:11 |
MTDiscord |
<luatic> if dir.Z > 0, it uses the min edge, which is the front face: it's normal must be negative |
| 10:12 |
MTDiscord |
<luatic> if it's normal was positive, it would point towards the max edge |
| 10:13 |
MTDiscord |
<savilli> oh i find my mistake |
| 10:13 |
MTDiscord |
<savilli> yeah it works |
| 10:14 |
MTDiscord |
<savilli> the trick is inverted direction |
| 10:15 |
MTDiscord |
<luatic> I had already started drawing lol |
| 10:15 |
MTDiscord |
<savilli> that makes a little less code |
| 10:16 |
MTDiscord |
<savilli> we still need https://github.com/minetest/minetest/pull/11831/files#diff-590af414910265f626360ae9f5d46f534f75a56082a1cdc8a4921ccdbc05804eR157 unfortunately |
| 10:16 |
MTDiscord |
<savilli> for start point as well then |
| 10:17 |
MTDiscord |
<luatic> ah yes, those pesky rounding errors... |
| 10:19 |
MTDiscord |
<savilli> i think VoxelLineIterator doesn't even need floats |
| 10:19 |
MTDiscord |
<savilli> it iterates over blocks anyways |
| 10:19 |
MTDiscord |
<luatic> don't round though, that might slightly change the direction of the ray |
| 10:20 |
MTDiscord |
<savilli> can it? |
| 10:20 |
MTDiscord |
<savilli> i think we would "touch" the same blocks |
| 10:21 |
MTDiscord |
<luatic> well, the question is: at which point do you round? |
| 10:22 |
MTDiscord |
<luatic> you may not round start or end pos, but you must round calculated poses on the ray |
| 10:23 |
MTDiscord |
<savilli> actually more interesting question |
| 10:24 |
MTDiscord |
<savilli> what to do if raycast doesn't even intersect with map limit box |
| 10:24 |
MTDiscord |
<savilli> we will still silently abort |
| 10:24 |
MTDiscord |
<luatic> yes, and we should |
| 10:25 |
MTDiscord |
<luatic> IMO that's 100% reasonable: outside of map means no intersections |
| 10:25 |
MTDiscord |
<luatic> basically, treat everything outside of the map as nothingness/void/whatever |
| 10:25 |
MTDiscord |
<savilli> lel you edited that |
| 10:26 |
MTDiscord |
<savilli> very fast hand |
| 10:32 |
|
erlehmann joined #minetest-dev |
| 10:33 |
|
Fixer joined #minetest-dev |
| 10:44 |
|
nemo42 joined #minetest-dev |
| 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 |
<savilli> 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 |
<savilli> we can fix the problematic for, but how to make sure it's the only place with the problem? |
| 10:58 |
MTDiscord |
<savilli> for example this https://github.com/minetest/minetest/blob/a106bfd456509b676ccba0ac9bef75c214819028/src/voxelalgorithms.h#L145 looks sus |
| 10:58 |
MTDiscord |
<luatic> 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 |
<savilli> sure hackers will wait until i turn on ubsan on the server |
| 10:59 |
erlehmann |
you misunderstand |
| 11:00 |
MTDiscord |
<luatic> 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 |
<savilli> 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 |
<savilli> 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 |
<savilli> 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 |
<savilli> how are you sure? |
| 11:03 |
sfan5 |
I am not |
| 11:04 |
MTDiscord |
<savilli> 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 |
<savilli> 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 |
<savilli> looks like we don't have many options |
| 11:14 |
MTDiscord |
<savilli> if we want a working raycast, we have to clamp somewhere |
| 11:14 |
MTDiscord |
<savilli> it can be VoxelLineIterator, but i don't think it's important |
| 11:16 |
MTDiscord |
<savilli> just casually found s16 overflow, there https://github.com/minetest/minetest/blob/f66ed2c27fa0f351ffb458224af74f3371d6f4ac/src/voxelalgorithms.cpp#L1324 should be s32 |
| 11:16 |
|
appguru joined #minetest-dev |
| 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:23 |
|
calcul0n joined #minetest-dev |
| 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 |
<savilli> 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? |
| 12:59 |
|
HuguesRoss joined #minetest-dev |
| 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 |
<savilli> sfan5: so what does stop you from approving 11831? |
| 13:12 |
MTDiscord |
<savilli> 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 |
<savilli> raycast wouldn't freeze, but wouldn't work either |
| 13:18 |
MTDiscord |
<savilli> no way to fix raycast that points out of the map without clamping |
| 13:20 |
MTDiscord |
<savilli> 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 |
<savilli> and we can reuse boxLineCollision to remove some wheel reinvention |
| 13:22 |
MTDiscord |
<savilli> 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 |
<savilli> are you going to look, or what's your plan? |
| 13:41 |
MTDiscord |
<savilli> 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 |
<savilli> okii, will wait then |
| 14:09 |
MTDiscord |
<savilli> time passes quickly :D |
| 14:32 |
MTDiscord |
<exe_virus> A lot* happens in 7 days haha |
| 14:36 |
|
x2048 joined #minetest-dev |
| 14:47 |
|
olliy joined #minetest-dev |
| 15:07 |
|
x2048 joined #minetest-dev |
| 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 |
| 15:47 |
|
x2048 left #minetest-dev |
| 15:47 |
|
x2048 joined #minetest-dev |
| 17:33 |
|
x2048 joined #minetest-dev |
| 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 |
|
lhofhansl joined #minetest-dev |
| 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 |
<Warr1024> 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? |
| 18:46 |
|
proller joined #minetest-dev |
| 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 |
|
proller joined #minetest-dev |
| 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 |
<x2048> 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:55 |
|
v-rob joined #minetest-dev |
| 19:57 |
MTDiscord |
<x2048> I want to change the API to player:set_lighting({shadows={intensity=0.5}, ambient_light={color="#ff8080", brightness=0.08}}) |
| 19:58 |
MTDiscord |
<x2048> 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 |
| 20:59 |
|
tekakutli joined #minetest-dev |
| 21:56 |
|
nemo42 joined #minetest-dev |
| 22:07 |
|
proller joined #minetest-dev |
| 22:49 |
|
appguru joined #minetest-dev |
| 23:25 |
|
m42uko_ joined #minetest-dev |
| 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 |
