Improving protection check for bucket usage#4887
Conversation
There was a problem hiding this comment.
Pull request overview
This PR tightens PlotSquared’s bucket protection checks to prevent players from bypassing plot build restrictions by using buckets on blocks permitted by the use flag (e.g., levers), while still allowing intended bucket-based interactions for cauldrons.
Changes:
- Restricts
use-flag-based bucket allowances to cauldron interactions only (to prevent waterlogging/flooding via interactable blocks). - Adjusts the
PlayerBucketFillEventcheck to useevent.getBlock()(the block considered for the protection query).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (type == BlockTypes.CAULDRON || type == BlockTypes.WATER_CAULDRON || type == BlockTypes.LAVA_CAULDRON) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
I used a different spelling; see the next commit.
| if (type == BlockTypes.CAULDRON || type == BlockTypes.WATER_CAULDRON || type == BlockTypes.LAVA_CAULDRON) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
I used a different spelling; see the next commit.
|
In theory, we should also allow |
Overview
Fixes #4851
The code change adds a specific block-filter to include only blocks that contain the "use" flag result in combination with "normal" bucket interactions. No waterlogging, no flooding allowed here, if it's not a plot-owner / member.
Description
Improving protection check
We've had a bug with bucket handling in the past. This was fixed by removing the "use" flag request. Then we get a bug report for the "use" flag and dordsor re-added a similar "use" flag check in PR 4673.
Checking the "use" flag makes sense. However, there are blocks that are interactive(!), and waterloggable, or that drop when water is placed into the hitbox(!). We need to prevent that from happening.
Example:
leverwater(lever drops), only if you have build permissionsSince this interaction only involves CAULDRON types, I don't currently see a need for a separate flag to define the blocks.
Change of requested block
In addition, I've adjusted the query here to target the block that was modified, which in this event is usually the same as the block being interacted with (the clicked block). It seems more logical to me to check here which block contains the final change.
getClicketBLock= the interactiongetBlock= the block for the final block change by bucket interaction (may be different for thePlayerBucketEmptyEventand mostly the same for thePlayerBucketFillEvent)Submitter Checklist
@since TODO.