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.
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 makes translation usage much more statically analysable.
The only places this isn't used are:
- places that prefix translations with colours (those are still a problem)
- places where server/client translations don't match (e.g. gameMode.changed accepts different parameters in vanilla than in PM)
the intent of these hacks was to break cyclic references to avoid having objects lingering in memory. However, all of the stuff that's being removed in this commit no longer has any effect anyway, due to the fact that these things don't circularly reference each other anymore. Notably, Tile inventories now keep Position instead of a Tile ref.
this makes more sense overall from a reader's perspective.
and also provide a rug-jerk for any idiots using World->close() when they aren't supposed to? ....
since we write these into a transaction instead of actually modifying the world directly, we can use the transaction to verify that the placement location is OK before setting the blocks.
closes#4248
when a chunk population is ordered, its only chunk loader is the one that the World installed to keep the chunk loaded while it was generated. So, when the resolver removes its chunk loader from the chunk, it triggers the chunk unloading mechanism, which causes the promise to directly be rejected.
closes#3461
literally every other particle/sound has the subject first, followed by the (optional) verb, and finally Particle (or Sound).
In addition, we refer to breaking blocks as 'break' everywhere except here, where we refer to it as 'destroy'.
