it's now the World's responsibility to manage adding/removing entities from appropriate chunks. Entities no longer know or care that chunks exist.
Entity->checkChunks() remains as-is for backwards compatibility - now it just calls the world to sync its position.
previously this created an empty chunk for the entity to hang around in until the terrain was generated, but that's problematic for several reasons, most importantly the fact that non-generated chunks are not saved.
The motivation for this is to prevent passing a dynamic argument to cancellation, which in almost all cases is a bug in user code. This same mistake also appears in a few places in the PM core (as seen in this commit), but in those cases the mistakes were mostly harmless since they were taking place before the event was actually called.
closes#3836
this fixes TNT spawning multiple entities when lit by flaming arrows.
The problem here is a bit more complex (entities aren't immediately notified when local block updates happen, so they cache stuff that becomes unusable). The simplest option would be to just lose the cache, but that would have some impacts on performance.
Barring a rethink of the block updating mechanism, this solution seems usable for now.
Various bugs existed for a while with stuff using chunk managers instead of worlds when interacting with terrain due to a behavioural inconsistency between World::getChunk() (return from cache or load from disk), and SimpleChunkManager::getChunk() (return from cache only). This change brings the two in line.
World::getOrLoadChunk() has been added as a replacement, which has the same behaviour as the old getChunk() and also makes it more obvious that there is an issue with code using it during refactoring.
the expectation is that eventually this will receive arbitrary internal runtime IDs instead of static id/meta, and RuntimeBlockMapping doesn't really care about this crap anyway.
since the removal of EntityFactory::create() this isn't needed anymore, since these creation functions are only used for creating entities loaded from disk.
in pretty much every case, these usages really wanted to read the tag's contents anyway, which can be combined with a getTag() and instanceof call for more concise and static analysis friendly code.
In the few cases where the tag contents wasn't needed, it still wanted to check the type, which, again, can be done in a more static analysis friendly way by just using getTag() and instanceof.
I wonder if there's a way to generalise item consuming beyond just eating/drinking. Stuff like lava bucket in a furnace needs the same kind of "leftover" logic.
this fixes crashes and various bugs with death logic executing during the creation of entities, as well as an age-old Player crash after quitting the server when dying.
