The check for whether an item is allowed or not only occurs at the moment when new items are put into the container. Therefore it's possible to make a container hold forbidden items (if you are its owner) by at first allowing the item, placing it in the container, and then forbidding the item after that. Forbidden items already in the container don't magically "pop" out of the container. They stay in.
DOUBLE-CHESTS To make a double-wide chest into a DedicatedContainer, you should only use the /dedicate next ... command when placing one of the two halves of the chest, not when placing both. Both halves of the chest will take on the characteristics of the one half of it that you made dedicated. Also a dedicated double-wide chest shares the same configuration for both halves of the chest, but if you break one half of the chest, the remaining half will revert to being undedicated (even if it was the one that was originally dedicated).
HOPPERS: If a hopper is causing items to move from one container to another container, and the next item in the source container is a type of item that the target container does not allow inside itself, the following method is used to try to get some other valid item to move (rather than allowing the entire mechanism to become jammed because of one single disallowed item): Within a few clock ticks, the entire inventory of the source container will rotate one step to the left, with the leftmost item wrapping around to the rightmost slot. This way a new item stack becomes the "next" item the hopper will attempt to move. If it also is disallowed, then another rotation will happen, and so on, until an allowed item is in the leftmost slot so it will start moving. In this way you can be guaranteed that the mechanism will only become jammed if EVERY item in the source container is disallowed in the target container. As long as at least one item in the source is allowed in the destination, it will eventually end up circling around to the front of the queue and be taken. (Once a successful item movement happens, the rotations stop, so the remainder of that stack will get moved.) One strange effect of this is that if the source container contains nothing but items the target container disallows, the source container will rotate its inventory in circles forever. This may look like a bug but it is not. This is expected and harmless behavior. Note that this circular rotation of items does slow down on purpose (to an eventual delay of 1.5 seconds between item shifts) when no items are found that are acceptable to move into the destination container. This is so that it doesn't pointlessly overload the server with fast item rotations..
SMELTING AND BREWING: If a furnace or brewing stand allows the source items in it but NOT the output item (for example, you have a furnace that allows iron ore and coal but not iron ingots) then the operation will still be permitted even though the target item could not have been placed into the container manually by a player. This is a deliberate decision and not a bug. If the operation were disallowed, the source material would still have been consumed but the output material wouldn't appear. To deny a particular recipe, you have to deny the source materials going into the device, not the output materials.
CRAFTING TABLES: This plugin does not work with crafting tables. A crafting table might *appear* to be a container of sorts because its interface looks like an inventory transfer screen, with the table having 9 slots in a 3x3 grid. But this is a 'faked' inventory that only exists on the GUI screen and cannot be stored in the table itself. Contrast this with furnaces and brewing stands, which do have a "real" inventory. (Which is why you can drop a bunch of coal and iron ore in a furnace and walk away but you can't leave items behind in a crafting table like that and walk away - they pop out.)
ENDER CHESTS: NO. JUST... NO. I tried thinking of how to make this plugin work with ender chests and the case is so messy in the end I decided to just say "This plugin does not support making Ender Chests into DedicatedChests." (For one thing the location of the chest is the key used to store its configuration information. Should different ender chests have different settings even though they have the same inventory? Another problem is that the inventory inside an ender chest is different per player, so does a chest have to have a different setting per player then? While a lot of very cool strange things could be done with this, I'm worried about the potential for exploits so I'm not implementing it for Ender Chests.
Comments
To post a comment, please login or register a new account.
Comments