Our hooks to allow tile entity based air have been around for a long time.
However, they were created in an age where we were limited to 4 bits for metadata.
A time where blocks themselves were limited to 256/4096. But now that both of those restrictions are removed I think it's time to align our hooks and modders more with vanilla's design.
As it sits, we require 50 patches for this one feature as is. Combined with another 130 that could be needed to deal with vanilla edge cases. This is very costly maintenance wise for a feature I am not sure anyone uses anymore.
So I'm proposing in 1.17, that we remove the positional arguments to isAir and use the state based system like most other block properties. Unless we get a valuable argument from this that isn't statistical fear mongering then it'll be headed for removal in 1.17.
Update: As people seem confused, this is only asking people who OVERRIDE this function. It won't effect people who call this function. As callers do not need to know implementation of the isAir function.
One minor complaint: As of right now, both BlockState#isAir() and BlockState#isAir(IBlockReader world, BlockPos pos) are marked as @Deprecated. Both essentially pointing to the other and saying "use that one instead".
Given the positional one is being queue'd for removal, would it be possible to un-deprecate the non-positional one instead? As it stands, it's not really clear (imo) which one should be used, from a caller stand point.
Unfortunately, for 1.16's life, modders should call the positional one.
In 1.17 it'll disappear, and thus become a compiler error. This is the best we can do for now.
Most helpful comment
One minor complaint: As of right now, both
BlockState#isAir()andBlockState#isAir(IBlockReader world, BlockPos pos)are marked as@Deprecated. Both essentially pointing to the other and saying "use that one instead".Given the positional one is being queue'd for removal, would it be possible to un-deprecate the non-positional one instead? As it stands, it's not really clear (imo) which one should be used, from a caller stand point.