This alters the behaviour of the ``getInventoryHolderLocation`` and ``getInventoryHolderType`` methods in a way which should have identical behaviour for double chests but which should also not raise an exception if there are triple (or larger) chests. The type will be correct; the location will at least return *something* which is the location of one of the chests involved, but it'll probably be semi-arbitrary what coordinates are returned.
Fixes#563 - note issue #533 which this does **not** address
- Update PR to use Actor system
- Amend actorFromProjectileSource to choose a friendly name when a block is the source of a projectile
- Added util method to try to suggest an appropriate item as the "weapon" in a projectile kill
Closes#442Fixes#470Fixes#471
These commits replace all checks of the form type == someInventoryBlockId || type = anotherOne
with a call to getContainerBlocks().contains(Material.getMaterial(type))
This was done by searching the code for 54 which is the chest ID.
Remaining explicit mentions of id 54 are in regards to special-casing for double chests -
the code there has been expanded to also consider id 146, the trapped chest.
I didn't think it worth making a collection for double-block inventories, but if more are
added it should be considered - looking forward, this might be necessary when the mod API
comes in, assuming we have a way of figuring out what double inventories are anyway.
This fixes many blocks not having inventories logged when destroyed due to explosions,
or not being rollbackable, and tools not querying both sides of double trapped chests.
Rolling back e.g. a furnace is glitchy - the fuel, raw material and product do not get
placed in the correct slots.
- Update list of container blocks
- Make tool treat trapped chests as potential double chests
- Replace explicit id checks with a call to getContainerBlocks()
This change involves refactoring many instances of "byte" to "short and altering a few ItemStack calls to use the int,int,short form instead of int,int,0,byte
Significantly it also involves altering the MaterialName system to allow shorts instead of bytes, and altering the rawdata() function to return the durability of an ItemStack rather than the data value of its Material.
One side effect of this is that tool durability is now logged, which will make for more accurate rollbacks.
Make a decison on whether or not to return chest access data based on the
BlockChangeType (ALL or CHESTACCESS) rather than partly on the block parameter
as these are the only two query types that don't enforce type != replaced
This is helpful because the list of blocks to request chest access for was
outdated and is duplicated in 3 different places, whereas the new method
will return whatever results have been logged regardless of type.
In addition, if the query type is CHESTACCESS (but not ALL), we can use
an alternate query that is vastly more efficient. In tests (26 million
row log table, 400,000 row chest table) the query time for all chest results
was reduced from 30 seconds to 3.
Allows the chestaccess parameter to return data from the following inventory types:
- Brewing stand
- Trapped chest (fixes#483)
- Dropper
- Hopper
- Beacon
Note that this only affects lookup of logged items; the logging process has not
been touched, so #433 and similar have not been addressed
Also, update the list of valid container types, which will improve logging of
broken containers.
frymaster
Ammar Askar
Dark Arc
Ammar Askar
md_5