When the BlockState's block type was changed, #update may have removed
the TileEntity, causing #isApplicable to fail with a NPE.
By: blablubbabc <lukas@wirsindwir.de>
* CraftBlockState#getWorldHandle() would previously run into a NPE when being invoked for a non-placed BlockState. It now returns null in this case.
* CraftChest#getInventory() would previously encounter this NPE when being called for a non-placed BlockState. It will now automatically forward the call to #getBlockInventory() when it is being called for either a non-placed BlockState, or during world generation.
* CraftStructureBlock#applyTo was able to run into a NPE when being called for non-placed BlockStates (this is for example called by #getSnapshotNBT()).
* Replaced all no-world-generation preconditions with a general 'ensureNoWorldGeneration' method.
* Removed a few superfluous #isPlaced() calls. If getWorldHandle() reutrns a World, this already implies that the BlockState is placed.
By: blablubbabc <lukas@wirsindwir.de>
During block destruction, the type of the block may already have been set to AIR while the TileEntity has not yet been removed.
Also, TileEntity#getOwner() skips the whole BlockState construction now if the block is of type AIR.
This removes the previous workaround again of returning a dummy CraftBlockEntityState in this case.
By: blablubbabc <lukas@wirsindwir.de>
- SPIGOT-5732: Fix issue with spawning leash hitches and painting, by using the right block faces
- SPIGOT-6387: Allow hanging entities to be spawned mid air
- Use randomize parameter to determine if a random painting should be chosen or not
- Return BlockFace self by leash hitches entity
- Throw a standardised exception when trying to set a BlockFace to a hanging entity which the entity does not support, instead of using BlockFace south or throwing a null pointer
By: DerFrZocker <derrieple@gmail.com>
The current implementation of World#spawn or World#spawnEntity
respectively, always prepares/finalizes the spawn of every entity
spawned through the API. While this is great to simulate natural
spawning of entities in the world through the API, it fails at
reliably creating default entities for purposes other than vanilla
gameplay.
While the caller of the API could attempt to undo all of the
customization that is applied in the prepare/finalization step, they are
numerous (reaching from sheep colour to equipment) and in some cases,
such as the chicken jockey, even spawn in other entities.
Hence this commit introduces a new overload to the World#spawn and
World#spawnEntity methods that accepts the 'randomizeData' parameter
that, when set to false, skips the prior mentioned
preparation/finalization step.
By: Bjarne Koll <lynxplay101@gmail.com>
