Open mibby opened 4 years ago
I have looked into a similar issue a while ago, but I couldn't find a way to I improve it. I suppose I won't be able to do something here either.
Everytime a hopper or hopper minecart interacts with a chest, it is checked whether the chest is a shop, so the item movement can be cancelled. Since a hopper (and minecart I suppose) do that every single tick, it might be too much for the server to handle in that short amount of time.
If it's a minecart hopper that constantly spams checks, what about adding aggressive protection by forcing removal of the entity for the nearby hopper interacting with the specific ShopChest chest spamming events if it doesn't stop after so many times? That way you don't have a hopper cart sitting who knows where tanking performance for no reason.
We don't want hoppers to be able to take items out of protected chests anyways so I think it would be fine to permanently remove connected hoppers / kill connected minecart entities that are trying to do so.
Does ShopChest do anything differently to check for hoppers compared to LWC or ChestShop? I don't recall hoppers being that heavy of a check task with those plugins. It could just be minecarts being the issue I suppose.
Would it be possible to look into and optimize ChestProtectListener? Seems to be a bit heavy, event was under Minecraft::tickEntity - nms.EntityMinecartHopper so perhaps is caused by someone having a hopper cart near a shop?
Using ShopChest dev 88 (https://github.com/EpicEricEE/ShopChest/commit/1faac3854e9bc8d77d05e40b0adc92146cdb7561)