-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
Info
Luanti 5.15.0-dev-9c37b46e1 (Linux)
Summary
You can set nodes into blocks that aren't generated yet. This can affect the lighting situation in the resulting block.
E.g. one can create an enclosed space. Then when the mapgen blits back its nodes (and when these nodes are bright in the vmanip (this only happens if the block read by mapgen didn't yet contain the placed structure (race condition))), the resulting nodes can stay bright even though they are in an enclosed space.
I'd expect a lightfix somewhere in EmergeThread::finishGen().
I'm not sure if it is / should be guaranteed that light is fixed in this case, therefore marking as unconfirmed bug.
Note: A simple fix could potentially significantly affect performance negatively. Please test if you make a PR.
(Found here: https://codeberg.org/Pixelo789/ThinkingWithArrows/issues/14)
Reproduction
- Create a devtest world in with singlenode mapgen.
/lua local p = (here / 16):floor() * 16; core.delete_area(p, p); core.load_area(p); local n = {name = "basenodes:stone"}; local np = here:round(); for x=-1,1 do for y=-1,1 do for z=-1,1 do local n2 if x~=0 or y~=0 or z~=0 then n2 = n else n2 = {name="air"}end core.set_node(np:offset(x,y,z), n2); end end end
(Side note: In singlenode you don't have to set air for some reason, so this also works:/lua local p = (here / 16):floor() * 16; core.delete_area(p, p); core.load_area(p); local n = {name = "basenodes:stone"}; local np = here:round(); for x=-1,1 do for y=-1,1 do for z=-1,1 do if x~=0 or y~=0 or z~=0 then core.set_node(np:offset(x,y,z), n); end end end end)- Look inside.

- Node is bright. (Even though node is surrounded by stone.)