The id->name block identification scheme change in Minecraft was reflected in the latest version of OpenInv: the block type, used for checking chest linking is no longer identified as the numerical ID of the block in question, but instead as a BlockChest type variable, which is always got as Block.getByName("chest"). This behavior ignored Trapped Chests in the check, and so linked both ordinary and trapped chests with ordinary ones. This caused a problem: if a trapped chest stands between two ordinary ones, it links with both of them, so the player gets a corrupt inventory view, reflecting contents of both three chests.
To fix this, BlockChest variable actually needs to reflect the type of the chest in question, so that it will appropriately link chest types.
The problem can easily be illustrated with the following screenshots:
1) Initial appearance of chest views (reflecting possible link situations):
The id->name block identification scheme change in Minecraft was reflected in the latest version of OpenInv: the block type, used for checking chest linking is no longer identified as the numerical ID of the block in question, but instead as a BlockChest type variable, which is always got as Block.getByName("chest"). This behavior ignored Trapped Chests in the check, and so linked both ordinary and trapped chests with ordinary ones. This caused a problem: if a trapped chest stands between two ordinary ones, it links with both of them, so the player gets a corrupt inventory view, reflecting contents of both three chests. To fix this, BlockChest variable actually needs to reflect the type of the chest in question, so that it will appropriately link chest types. The problem can easily be illustrated with the following screenshots: 1) Initial appearance of chest views (reflecting possible link situations):
2) Same chest views as of this commit:
