Solved SignChangeEvent behaviour

All right I am continuing with my Bukkit bug fixing spree...is it expected behaviour that placing signs is not cancelled when the SignChangeEvent is cancelled? Placing certain signs requires a permission (this is common), but the sign is still placed properly in my case, even after cancelling the event.

If breaking the sign block is up to a plugin to handle, and it is not default behaviour, I will add that. If the sign is supposed to be broken whenever signchangeevent is cancelled, I'll add automatic destroy behaviour in BKCommonLib to fix this bug globally.

tldr;

What I see is that, when I cancel the event, the sign is still placed with the text emptied. This makes cancelling a SignChangeEvent pointless regarding the actual placement. Bug or no bug? Should I set the block to air myself? Should Bukkit do this?

 

Seems normal to me, you are just cancelling SignChangeEvent and not BlockPlaceEvent.

 

I wouldn't go as far as claiming it to be a bug. You can probably see it from different perspectives, but I agree with the way it is handled right now (no automatic deletion of the sign on SignChangeEvent).

As you are most likely aware, "sign placed by player" and "sign text changed by player" happen at different moments and are technically pretty separated from each other.
Even though, in normal minecraft gameplay, they usually happen in succession to each other, that doesn't necessarily need to be case.
For example, one of the many "edit existing sign with command" or similar plugins can (IMHO in an optimal environment) fire a SignChangeEvent on a sign that was already existant.
How and why exactly would you break the sign now?

Also, "break on cancel" differs from a "cancelled BlockPlaceEvent" because the sign item was already removed from the player's inventory and is physically in the world. Now, you couldn't simply make it "stay" in the player's inventory, you would have to actually break it and make it drop as an item entity - which you can do as a plugin.

I wouldn't want bukkit to do that automatically if I were to block some sign texts related to my plugin. If it were automatic, I can't decide to prevent the text change without breaking the sign without a work-around.

That's just my two cents on that, as I said previously, there might be other perspectives

 

Bone008
Yeah that is what I thought too. I'll make this sign breaking logic part of TrainCarts alone then, it's not a good idea to do it globally if it's not going to be 'fixed' any time soon.