Closed FxMorin closed 1 year ago
Rounding types:
Current effect on splash bounds:
The splash potion hitbox should be taller, although this shows what im doing well enough
Thanks for the great visuals! Your latest commit (d03a478e1cc07f9973b6c4410cbde001d820ca5a) makes the converted area uneven again, being 1 larger in the Positive directions. It both ceils the high bound and includes the high bound of the loop.
In that version, a splash potion bounding box from -8.5 to -4.5, for example, will iterate from -9 -> -4 even though the block at -4 (which encompasses -4.0 to -3.0) isn't low enough to reach the -4.5 upper bound. I believe the version pre the latest commit is more correct (at 1648c8f2aa4737d49802b1275e87b43270dd13de).
But that still has some inconsistency. The position of the potion on impact is the location that it was at the beginning of the tick in which it would hit. This means that once you start having faster potion velocities (say drop from 30+ blocks), there may be only a 1 deep area converted instead of 2 deep etc. However, this is how regular splash potions work, so maybe it's OK. But those operate on entities, so a little inconsistency is expected.
It would be simple enough to use the actual raytraced collision point as the base of the calculation (just use hitResult.getPos()
when hitResult.getType() == Block
) and would make the results much more repeatable, but it would also add inconsistency with where an entity would actually get hit by a potion.
The consistency with entities getting splashed doesn't matter though except for lore. I think the reliable conversion is more important. Also, this is also how splash water bottles work to extinguish fires, so it's what I think I'll implement.
Fix the
renewableDeepslateFromSplash
rule being slightly larger in the positive axis's. Also fixes the bounding box being shorter due to casting negative valuesThis is untested!