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 4a4900e5e7.
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 890f72dbf2. 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
MOP doesn't make any sense anyway.
RayTraceResult is a container which represents the point at which a line hits a bounding box. No dependence on blocks or entities is wanted or needed.
MovingObjectPosition has API changes to allow it to wrap RayTraceResult, but nothing uses MOP anymore anyway.
This would allow modularisation of the pocketmine\\math namespace.
at the expense of magma no longer working (which will need to be done better anyway).
This:
- reverts the +0.01 outset which hugely exacerbated the lava bug (fixes#1892)
- adds a 0.001 inset (PC-style) which prevents entities incorrectly intersecting with diagonally adjacent blocks at far-ish coordinates (lava at x=4000, z=4000 is a good way to test this).
PR #1880 does also solve this issue, but again at the expense of magma. Since the bugfix does not require a big bounding-box handling refactor, it has been separated out.
This is a rather larger commit than I'm happy with, but oh well.
This kills off the enormously overcomplicated BlockIterator and replaces it with a VoxelRayTrace class containing ray tracing generator functions. These functions are independent of any Level. They yield Vector3 objects with current ray trace positions to allow implementations to handle the intercepted blocks in their own ways.
Living->getLineOfSight() now uses VoxelRayTrace instead of BlockIterator.
