[SPIGOT-3109] Material.IRON_DOOR_BLOCK Update re-triggers PlayerInteractEvent Created: 07/Mar/17  Updated: 08/Mar/17  Resolved: 08/Mar/17

Status: Resolved
Project: Spigot
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Phillip Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: 1.11.2, Class, Door, bug
Environment:

CraftBukkit version git-Spigot-d4f98a3-cb61ac0 (MC: 1.11.2) (Implementing API version 1.11.2-R0.1-SNAPSHOT)

I am not aware of any existing plugin which uses the Doors class without deprecated code.

Custom plugin development utilizing the new Door class without deprecated code..


Attachments: File GtzDoors.jar     Java Source File GtzDoors.java    
Plugin: Custom code attached

 Description   

The events work normally when used for class Door of all types, except IRON_DOOR_BLOCK

Where I have proved that the PlayerInteractEvent is retriggered upon...

referenceState.setData((MaterialData)referenceData);

referenceState.update();

Basically I am flipping the Door isOpen() Boolean,

Under the fault condition of Door = IRON_DOOR_BLOCK, the end result will always be NOT changed.



 Comments   
Comment by Phillip [ 08/Mar/17 ]

Thank you. I will look into this new requirement.

Comment by md_5 [ 08/Mar/17 ]

No, I'm saying your code is broken because it isn't accounting for the two interacts with different hands - main and off

Comment by Phillip [ 08/Mar/17 ]

Oh, erm, which hand does the right-click? I have never come across anything like that before!

Anyway I can't see any problem relating to that. The issue I have is with the Door block.

I am trying very hard to avoid any methods which may get deprecated. But I will investigate the reflections options.

You appear to be confirming that the Spigot Door state.update()  for Iron Doors is pointless for the setData().isOpen() property?

Comment by md_5 [ 08/Mar/17 ]

You're not checking which hand the player interacts with the door.

Once again my bet (use ReflectionToStringBuilder.toString(event)) is that the two events are not the same, and the second event is with the second hand.
Why? Because opening an iron door isn't a native thing, so the client will attempt to interact twice.

Comment by Phillip [ 08/Mar/17 ]

There is no question of the block being invalid as all the checks have been validated before any action is taken.

OK here is the code made more basic. GtzDoors.jar

  1. The code works perfectly for wooden doors.
  2. When an Iron door is involved the PlayerInteractEvent is re-triggered (it runs twice)

Note that when a Wooden Door is right clicked - Minecraft handles the door event first and then the PlayerInteractEvent is triggered. Hence my test code will show the wooden door flips open for a moment.

Note that when an Iron Door is right clicked - Minecraft does not open the Iron Door and the PlayerInteractEvent is processed, when the state.update() is processed the PlayerInteractEvent occurs twice!

Problem = When an Iron Door is clicked the PlayerInteractEvent retriggers before a visual change of state can be perceived, this does not happen with Wooden Doors

    private void changeDoor(Block blockBottom, Player player) {
        BlockState changeState = blockBottom.getState();
        Door doorData = (Door)changeState.getData();
        final boolean open = doorData.isOpen();
        if (open) {
            doorData.setOpen(false);
        }
        if (!open) {
            doorData.setOpen(true);
        }
        changeState.setData((MaterialData)doorData);
        changeState.update();
        player.sendMessage("The updated door has been set as " + (doorData.isOpen() ? "opened" : "closed"));
    }

The expected outcome is that for each right-click on an Iron Door should flip the door state.

You will see for each click on a wooden door 1 message.
You will see that for each click on an Iron door 2 messages!

Comment by md_5 [ 08/Mar/17 ]

Not clear what the issue is based on this ticket or code. If you're gonna include code it needs to be minimal reproduction.
Likely the events are not 100% and the second one for example may be air, this is a client limitation.

Generated at Tue Apr 15 11:10:39 UTC 2025 using Jira 10.3.3#10030003-sha1:d220e3fefc8dfc6d47f522d3b9a20c1455e12b7b.