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.
This now removes the need for recursing around for structures comprised of multiple blocks. Instead, override getAffectedBlocks() to return all blocks that need to be deleted when the current block is deleted, and make sure that only one half of the block drops something. When a player breaks one of the blocks, all the blocks affected by that block will also be destroyed, creating particles and sounds where appropriate.
This fixes creative drops for double plants and beds.
* Removed broken EntityEatEvents - these don't fit the pattern since they only apply to Human entities anyway. PlayerItemConsumeEvent and PlayerInteractEvent can be used for cancellation purposes, and plugins can do custom stuff without mess.
* Restrict item consuming to Living entities only
* Added FoodSource->requiresHunger()
* Only items implementing the Consumable interface can now be consumed.
* The effects from consuming items are now generic-ized by way of the Living->consume() function. This is overridden in Human to allow applying food and hunger.
* Fixed the hardcoded mess for buckets
Seems that leaves are another special case - they technically speaking accept any tool to break, but only drop when shears are used. They don't REQUIRE shears because if they did the break time would be longer for non-shears tools.
getDrops() should now be overridden only for special cases. There are some non-trivial overrides left that are going to need some extra work to clean up.
The function name is a little long-winded, but that can always be refactored later if needed. This provides a way for blocks requiring specific tools to override drops with non-standard stuff without needing to worry about what tool type was used.
It's also possible that passing the Item used here is actually entirely redundant, but again that can be fixed later.
This name better describes it. "can be broken with" implies that items which this returns false for cannot destroy the block at all, which is incorrect. What this actually returns is whether the item is the best tool to use to break the block.
* Added Liquid->getLiquidLevelDecreasePerBlock()
* Fixed lava turning into cobblestone when flowing over water
* Cache liquid flow vectors for faster entity movement
* Removed a condition that made lava impossible to get rid of
In the PC code, the equivalent code makes the delay between scheduled ticks 4 times longer. Here, it just breaks the code. I don't know what the 4x stuff is about, but this code does not produce the expected behaviour and lava works fine regardless.
* Fixed strange behaviour with liquids trying to flow into other liquids
Liquids should consider other liquids as a path of least resistance. However, they should not actually flow into them. This fixes a variety of CPU leak issues with falling water in large water bodies such as oceans.
This also fixes the plus-shape effect that liquid is supposed to produce when a source is placed above ground.
* Removed a bad optimization making liquids flowing down slopes behave undesirably
* Optimize performance of slope searching by limiting recursion depth based on previous path lengths
If we already found a step down on a previous run after 2 blocks, it doesn't make sense to continue allowing checking 4 blocks because the results will just be ignored. This allows limiting the number of recursion steps, which significantly improves the performance when flowing down slopes.
However, this will still be just as bad for performance on flat terrain as it was to start with.
* Make some Liquid methods only accept Blocks as parameters
these are only ever passed blocks anyway, doesn't make sense to allow vectors.
* Moved some things to local variables
these are each only used in one function, so it doesn't make sense for them to be class members.
* Fixed water flow down slopes going everywhere, but degraded performance again
* Lava should only search 2 blocks for a slope
* Stop wasting CPU calculating optimal flow directions for liquids with too-high decay
It calculates the flow directions and THEN doesn't use them when it
realizes the flow decay is too high. This is completely pointless.
* Use a less hacky method to handle lava flowing into water
* Doubled flow performance on flat terrain
Since calculateFlowCost() usually ends up visiting the same blocks about 6 times when on flat terrain, it makes sense to cache some stuff for when blocks get revisited so expensive dumb checks don't need to keep on being done. On my machine this produces a 50-60% performance improvement when flowing on flat terrain.
* Fixed missing return values in Liquid->onUpdate()
these return values aren't used anywhere, but we should be consistent
* Don't allow flowing back in the same direction we just came from
This reduces the recursions by about 30%, providing about the same percentage performance improvement.
* Remove Liquid's temporalVector (it's not used anymore)
primitive types for the win!
* Move liquid collide to its own method
* add sound for lava/water mix
Most of these methods are called from onUpdate(). It's unreasonable to
assume that the level might be null during a tick (unless a plugin
messes with a block update event or something, but that's undefined
behaviour anyway). Using getLevel() simply wastes processing time by
constantly checking if the level is closed.
