Okay, so I have this set of locations, and I iterate through it and:
Set the block type
Add it to a list
An event listener will cancel any block changes if the block is in said list. Now, my problem is that the event listener is cancelling the block type set (#1 above). This is, of course, expected, as change block is fired in bundles, but I need to get around this hurdle. What I’d really like to know is if there is some unique cause to programmatic setting of a block, or even better, a way to specify the cause used. If not, I need some help coming up with possible solutions, as this has got me stumped.
I believe what you’re looking for is #setBlock(…Cause) where plugins can bypass cause tracking, provided they satisfy the requirements of that method, and any appropriate block changes will take into effect. Likewise, the provided cause is used in the events thrown from using this method.
In the cause refactor branch (implementation only, no API changes with this), it’s going to be a bit “smarter” about tracking who is doing what, and more importantly, appropriately associating causes for events thrown by event listeners while reacting to other events.
To give a little bit of a better explanation:
Player places a sign
Player completes sign change
Plugin listens for this sign update through an event
Plugin changes the sign or starts a mass block placement
CauseTracker successfully associates the plugin’s listener to changing blocks, while also associating the player (for obvious reasons)
CauseTracker gets block changes in bulk until plugin listener is done, throws any events necessary
Other plugins listen to new block change events cancel if necessary (since the causes will be structured similarly, but including the ever so important plugin as a source (up for debate))
Plugins finish listening to plugin cause block changes
Plugins likewise finish listening to the original block change event the player threw by finishing editing the sign
All block changes have successfully completed.
In short, I’m still working on the larger part of associating plugin listeners to causes, having to get the basics working first. If you’d like to discuss this, please continue it on the cause tracking pr.