this was causing unexpected behaviour particularly on burning trees, whereby fire would be unconditionally extinguished if the block below it was removed.
This happened when a block was set into the world with a direct update, when an entry for that block was already present in the changedBlocks map. This fixes the bug by removing the entry from the changedBlocks map to avoid sending outdated block updates in batches.
Chunks were used by tiles for a couple of things:
- 1. for coordinates - which can be gotten using bitshifts
- 2. setChanged() - which is unnecessary as seen in the previous commit
Removing this circular dependency was actually remarkably easy to do.
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.
save() calls saveChunks() which saves any chunks found to be modified. But chunk unloading does this anyway, so it's better to unload first and then trigger the save mechanism, to avoid saving chunks twice.
This now removes logging from the level providers (for the most part) and replaces it with exception throws and catches. The implementation using the providers should catch these exceptions if they are thrown.
So this came from a bugfix (795d6c8ddf) 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.
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.
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 is annoying and it requires that the server must match this precisely to not cause bugs. Additionally, this code shits its pants when the client hits a spot of network lag.
This can be implemented easily as a plugin. There is no reason whatsoever for this to be in the core.
Since chunks are unloaded before changed blocks are processed, there is a small chance that a block might get changed in a chunk, and then get unloaded due to not being in use, before the updates are broadcasted.
This is unlikely to ever happen since chunks usually don't get unloaded unless they don't have loaders anyway, but it could happen (?) if a chunk is forcefully unloaded.
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.
