Uploaded image for project: 'Spigot'
  1. Spigot
  2. SPIGOT-5282

PlayerBucketEmptyEvent reports wrong BlockFace when the event waterlogs a block

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
    • Environment:

      Windows 10 64 bit

    • Version:
      git-Spigot-798ea6a-2012f1e (MC: 1.14.4) (Implementing API version 1.14.4-R0.1-SNAPSHOT
    • Guidelines Read:
      Yes

      Description

      The getBlockFace() method of this event always returns the block face that the player clicked on. Before the waterlogging mechanic was introduced this behavior was correct, since water was always placed relative to the block being clicked and never replaced the block itself. But with waterlogging, if the clicked block is a type that can be waterlogged (a fence post, slab, etc), and the block isn't currently waterlogged, the event actually fills the block that was clicked, not the one relative to it. Currently the event still returns the relative BlockFace, but I think in this case it should return BlockFace.SELF, since that's where the fill is actually taking place. This is consistent with how the PlayerBucketFillEvent works.

      If the block is already waterlogged, water will be placed relative to the block, so the returned block face is correct in that case. It's only when clicking a block that would be waterlogged that the issue occurs.

      This is important for block protection plugins, because they need to know which block was actually changed in order to do a permissions check. With my proposed solution, event.getClickedBlock.getRelative(event.getBlockFace()) would always correctly return the block that was modified by the event. While it is possible to work around this, as shown in the attached file, I don't think the current behavior of the event is correct.

       

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            CraigParton Craig Parton
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: