the only reason to use getCollidingEntities() instead of getNearbyEntities() is if you have an entity that may or may not be collidable depending on certain conditions.
Really, I don't think this logic belongs in World at all, but for now it has to stay, because some other stuff depends on it.
these two methods are very misleadingly named, but they do almost exactly the same thing - the only difference is that getCollidingEntities() does a couple of additional checks.
we can't have landed on it unless it actually has a collision box - otherwise, we only landed _in_ it.
This assumes, of course, that no blocks have bounding boxes >= 2 blocks tall, which currently none do.
instead, just ungate this and allow the provider to decide what to do.
Any chunk that contains entities or tiles is already always considered dirty, so the only thing the flags are good for is flagging chunks that previously had tiles and/or entities but no longer do.
In those cases, it's just removing keys from LevelDB anyway, so it's already very cheap.
Avoiding these redundant deletions is not worth the extra complexity and fragility of relying on flags to track this stuff.
this was using json before, which is horribly inefficient.
This saved about 200 KB of memory on initial startup (which isn't much, but for more complex recipes, it might have been significantly worse.
the use case for this is basically zero, since the community prefers implementing their own subcommand systems instead (which are much more flexible).
In addition, allowing spaces in command names makes it extra complicated to display helpful information to the user, such as the command that was actually accepted by the command map (which would be useful for identifying accidental invisible characters / control characters when sending commands).
This event is currently fired for tree and bamboo growth. Its intended use is for any plant growth that affects multiple blocks at once.
TODO: We could explore using this for cacti and sugarcane?
