Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double TrappedChest not recognized #223

Open
mikeboers opened this issue May 17, 2015 · 1 comment
Open

Double TrappedChest not recognized #223

mikeboers opened this issue May 17, 2015 · 1 comment

Comments

@mikeboers
Copy link

I'm writing a plugin with a focus on hoppers and chests, and it seems to me that the normal chest code does not seem to work appropriately for trapped chests.

This (heavily reduced) example always prints out "Chest is of size 27" for double trapped chests, but 54 for normal ones:

TileEntity target = hopperBlock.getWorld().getBlockAt(x, y, z).getTileEntity();

if (target instanceof Chest) {
    Chest chest = (Chest)target;
    Canary.log.info(String.format("Chest is of size %s", chest.getSize()));
}

Trying to explicitly grab the double chest (via getDoubleChest) sometimes throws an exception. I don't have a record of it, so I'll post it if I come across it again.

@mikeboers
Copy link
Author

It seems like trapped chest inventories are absorbing whatever chest (trapped or not) is beside it, with the priority order of N, S, E, and finally W.

This is my test setup (with a trapped chest in the center, and normal ones around it). I place a single item in each of the surrounding chests, and see which one appears to be in the trapped chest from the API's point of view.

2015-05-17_18 25 42

This appears to coincide with my understanding of how double chests work in the Canary API (specifically in CanaryChest.hasAttachedChest() and similar).

(Note that this does not happen if we invert the scenario, with a normal chest on the inside and trapped on the outside.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant