andi-makes
commented
2 months ago Thank you for reporting this issue!
Your hunch is kind-of correct. Sometimes there is a race condition with Lighty computing the Overlay even though the LightMap isn't generated for that chunk yet. Personally, I've only encountered this when loading newly generated chunks, but I guess the race condition makes itself known in different ways on different machines.
I don't necessarily know how to exactly fix it, as I haven't found a good way to query if LightMap information is available or not.
You are also right, that Lighty only recomputes the Overlay when there's a block update, but also (of course) on initial load of the overlay, and that's where the race condition can happen.
As a workaround without placing/changing blocks: You can try switching to a different LightyMode (for example CarpetMode), and then switch back to the original LightyMode you were on (for example, NumberMode). That should fix the overlay for the chunk, if it doesn't, please let me know, because then this is a very different bug and I'd need to look into it in more detail.
mk-pmb
A few days ago I had a surprise creeper in a closed room that should have been well lit. So I enable lighty and see 0/0 on the floor 2m below a wall torch. As soon as I flipped a nearby trapdoor, the light levels on the floor were green again. Seems like all that was required was any kind of update to the chunk. For days, I assumed it was Minecraft being buggy. Now I discovered that in another corner of the same chunk (stairs to my pig pen) the debug screen says block light is 10, while lighty shows 0. So maybe it is a bug in lighty instead, making the creeper an unexplained mystery again.
Screenshot
How do I even start to debug this? My hunch is that it is about deferred chunk rendering, that Lighty would need to wait a fraction of a second longer before querying the light values. If trapdoor-flipping causes lighty to query again, that would explain why that suddenly makes the numbers green and nonzero.