BlockApiary incorrectly handling Block::getLightValue
covers1624 opened this issue ยท 2 comments
This one was a tricky one to track down and initially happend with TE's machines. See https://github.com/CoFH/Feedback/issues/780 and #253.
Basically it boils down to how getLightValue
works, forges lighting engine, vanilla's fluid model, and vanilla's model render all call getPackedLightmapCoords
is called on the block
with the position of itself and the blocks around it EnumFacing.values
, BlockApiary then proceeds to HasTE.getTE
, that then see's that the tile doesnt exist and replaces it with a new instance of the "correct" tile, when actually it just corrupts the tiles around the block.
Second glance, forge may have incorrectly patched their pos sensitive version in, regardless, the fact that gendustry attempts to "fix" its tile just causes more issues than it solves.
Edit traced the usage of getLightValue
in 1.7 and can confirm this is how it functions.
Hmm that's a really weird way it works. What am i even supposed to return for a block position that isn't actually my block...
Anyways i've added a check to prevent that in gendustry and some safety checks in HasTE to complain or throw an error if it's called on the wrong block.
Thanks for investigating this through and sorry for the trouble.