This supports vanilla placement of paintings, with overlap and collision checking.
Paintings are removed when a block is placed inside them or if any of their supporting blocks are removed.
As per vanilla, a random painting is chosen from the largest subset that will fit into the given space.
* Revert "Revert bad duct-tape fix that broke lots of other things"
This reverts commit 4a4900e5e7ea1fd7b897b025b4b666fd2050f80a.
Player: Perform respawn actions when joining while dead
This fixes exploits related to #1567 by calling respawn logic on join when the player has zero health.
This is a shitty fix and doesn't solve the actual issues described in #1567, but it's a simple solution for the exploits related to it.
TAG_String has a UTF-8 payload, which makes it more expensive to work with. Also, skins can contain bytes which are not valid UTF-8 characters and will therefore be treated as corrupted by external tools.
Additionally a TAG_String can only hold 32767 bytes, which might become a problem in the future.
A TAG_ByteArray can hold up to 2GB of data, and there is no character encoding restrictions on it.
This was a bug in older versions, fixed by 890f72dbf23a77f294169b79590770470041adc4. However since ALPHA10 this has been moved to the new, strict-ified CompoundTag API, which shits its pants when it encounters a tag of the wrong type.
Closesjojoe77777/Slapper#119
This makes #1567 less exploitable. Now, players who attempt to exploit this bug will get stuck - they won't be able to move or do anything. Not ideal, because they won't be able to respawn either - but it's better than nothing.
Try setting a fire at z = -204, then stand on the edge between -205 and -206.
The coordinates that a BB's corners are encapsulated in are always the floor()ed coordinates
If you stand at -205.0, your BB min is -205.3 and your BB max is -204.7, which then incorrectly tells you that the BB intersects with block -204
because ceil(-204.7) == -204
when you actually are only intersecting with -205 and -206
this is as bad as using (int) to floor integers :kms:
This includes several other changes, including:
- SLOT data properties now accept items directly
- POS data properties now accept floored Vector3s (in future this will be block positions) or null for 0,0,0
- VECTOR3F data properties now accept Vector3s or null for 0,0,0
