2 Bugs/exploits
SaadArdati opened this issue · 9 comments
- You can place a chest next to a locked chest, that will convert it to a double chest and the freshly placed side can be opened as normal.
- You can place hoppers/any form of item transport to extract items from locked chests
You can place a chest next to a locked chest, that will convert it to a double chest and the freshly placed side can be opened as normal.
This isn't a bug, but rather a side effect of how the mod functions. I'm not sure of a good way to fix this other than hard coding the behavior for every single chest from every mod which is not a good idea.
You can place hoppers/any form of item transport to extract items from locked chests
Also not strictly a bug as I've never tried to prevent this, but I will try to fix this kind of behavior.
Please submit another issue rather than cramping two issues into one.
You can listen to the block place event, if it is an inventory container, check it's neighbors. Start with vanilla chests and add support for quark and you've prevented 90% of the cases.
It's not that simple. What if the placed inventory container is not a chest or not something (even a chest) the player wants to lock at all? And what if the locked area is rather large? I'd have to expand the area's bounds also locking other blocks next to the placed block.
This is from BlockChest
private boolean isDoubleChest(World worldIn, BlockPos pos)
{
if (worldIn.getBlockState(pos).getBlock() != this)
{
return false;
}
else
{
for (EnumFacing enumfacing : EnumFacing.Plane.HORIZONTAL)
{
if (worldIn.getBlockState(pos.offset(enumfacing)).getBlock() == this)
{
return true;
}
}
return false;
}
}
It's private so reimplement it.
In the block place event, get the snapshot (previous) block, check for surrounding chests on EnumFacing.HORIZONTAL. If a chest is found, check if it is a double chest with the code above. If it is not and the block being placed CAN be placed (with the code below), then update the box but don't lock anything in the expanded bound, only lock the whitelisted new chest.
This code is to check if the chest can be placed. This method is public in BlockChest
public boolean canPlaceBlockAt(World worldIn, BlockPos pos)
{
int i = 0;
BlockPos blockpos = pos.west();
BlockPos blockpos1 = pos.east();
BlockPos blockpos2 = pos.north();
BlockPos blockpos3 = pos.south();
if (worldIn.getBlockState(blockpos).getBlock() == this)
{
if (this.isDoubleChest(worldIn, blockpos))
{
return false;
}
++i;
}
if (worldIn.getBlockState(blockpos1).getBlock() == this)
{
if (this.isDoubleChest(worldIn, blockpos1))
{
return false;
}
++i;
}
if (worldIn.getBlockState(blockpos2).getBlock() == this)
{
if (this.isDoubleChest(worldIn, blockpos2))
{
return false;
}
++i;
}
if (worldIn.getBlockState(blockpos3).getBlock() == this)
{
if (this.isDoubleChest(worldIn, blockpos3))
{
return false;
}
++i;
}
return i <= 1;
}
I never asked for any help with code. And I can't simply add a block to the bounds of a locked area, it has to be a cuboid. So the previous two points I mentioned still stand. There's no real good way of accomplishing this.
There's no good way, yes. When the cuboid needs to be expanded due to a double chest placement you can do one of two things:
1- Add a secondary cuboid that contains the lock with the double chest. Locks would need to hold a list of cuboids potentially.
2- Add a whitelist for lockables inside cuboids. All blocks in a cuboid's creation are whitelisted. If it requires expansion, instead of expanding, only the block that is demanding the expansion would be added to the whitelist and nothing else.
What if the placed inventory container is not a chest or not something (even a chest) the player wants to lock at all
We're talking about vanilla (quark chests I just found- extend BlockChest so behavior is inherited). These solutions cover vanilla chests and that is enough for the majority of cases. When a chest is turned into a double chest, the expected behavior is for the lock to adapt to the double chest. We don't care if a player wants to lock an adjacent chest outside the cuboid or anything adjacent that doesn't directly interact with what is inside a cuboid.
Ok let’s say I hardcode (which I'm really not a fan of) this feature specifically for tile entities that extend TileEntityChest or blocks that extend BlockChest. Then I’d still need to rewrite the whole system for storing locks to store individual block positions instead which is just not viable. I’ve thought of this way before and it introduces too many issues.