This allows the removal of lots of ugly code, and also exposes lots of similarities with how this update type was handled. This can be further improved in the future to more generically handle cases.
I realized in the process of changing this, that it might actually be simpler to treat to treat scheduled updates and neighbour updates as one and the same. They use the same mechanism for being saved on chunks (TileTicks),
and doing that would make updating only require one queue instead of two.
RedstoneOre: use onActivate() to trigger glowing
this is not technically correct behaviour, but this preserves the current behaviour.
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.
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
take fences as an example: say you have fence1 and fence2 next to each other, like this:
|==|
and they are joined together
then delete the fence on the right
the left fence will then look like this
|
but the server would still think its collision boxes were like this:
|=
so you wouldn't be able to shoot arrows through that space.
This commit clears pre-computed bounding boxes when a block is set using Level->setBlock() (in case the block was previously already set and has pre-calculated outdated AABB). However, because of weird blocks like fences, glass and walls, they must also be cleared on neighbour block update (since connection state isn't shown in the block data).
the count parameter is useless since Item ctor should now only be used for constructing item _types_, not actual items. All item creations for inventories etc, should go through the ItemFactory.
