plugins might be using this method, or the item may have been dropped involuntarily due to server-side logic. Therefore it should be handled when the transaction is received and not when the item is dropped into the world.
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
It's only now used in the Durable class, so it does not make sense to keep it in Item anymore. This is a leftover from the days where Durable did not exist.
So this came from a bugfix (795d6c8ddf1148dfe6de8ff5ef38a96aee6124fe) which fixed a memory leak related to entities getting kill()ed on chunk unload.
HOWEVER, me2016 did NOT realize that this code is actually entirely pointless and causes unexpected behaviour.
removeEntity() is used in 2 places in the core code:
1. in Entity->close() (so close() doesn't need to be called again, obviously)
2. in Entity->switchLevel() (which then causes the entirely unexpected behaviour of close()ing the entity on level change.
Conclusion: This code is pointless. This fixes the bugfix.
Invalid characters in plugin names are no longer stripped. They always result in a load error.
The behaviour of replacing spaces with underscores is not changed.
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.
Fixes#1903Closes#1906, which, while a pretty solution, is very inefficient (see PR discussion). This is an optimization of microscopic proportions, but the point still stands.
First working enchantment on master. Hooray for 3 years late.
This works out of the box (the code checking for this enchantment already exists in Human->doAirSupplyTick()).
Remove MCPE-network specific stuff from BinaryStream, added NetworkBinaryStream
This removes dependencies of BinaryStream on core code, while providing some consolidation of network handling code.
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.
This used to cause problems in earlier versions of pthreads if PTHREADS_INHERIT_CLASSES was not used. This is no longer a problem in pthreads v3, because pthreads v3 copies passed threaded object classes under the hood, so there is no need to manually include them anymore.
Additionally, the files in these paths don't exist anymore.
