Add ExplodeEvent and Improvement in Spigot Explode events

[Doc94]

This PR is a "copy" from a 2 years old PR in Spigot related to explosion, when this start the issue is how the gamerule for avoid mob griefing make the explosion event not being called, with recent changes now CraftBukkit pass the explosion behavior for make the user know what is the behaviour of this explosion.. with this in mind this PR takes that for well.. call the event for that also handle a issue where "explosions" created by Wind Burst call the block explosion with not data.

This PR implement a new "generic" event for any explosion generated by the server, this brings the same behaviour of the Spigot explode events (block,entity) this this event is intented for being called for all the explosions.. affects or not the environment.

[Doc94]

PS: Very new with the new contribution system.. currently the ExplosionServer has unused CB imports but if remove that the fixupSourcePatches just fails

[lynxplay]

Alright, thank you for the PR!
We have reviewed it but are a bit (a bit too) hesitant to call these events when their javadocs do define them to not be called in these exact spots.

We could fire them pre-cancelled, but block break related events are obviously rather important for plugin data, and I'd rather avoid plugins dying/duping because they did not correctly check cancelled here.

Instead, Machine and I think it'd be best to use this API downside to finally create a better version of the "SomethingExplodeEvent" (better name pending) that covers both entities, blocks and nothing (like in the mace's case). Such an event can be called for these cases, specifying that no blocks will be broken etc.
The current events types could then be marked as Obsolete and the new event would be called after to allow people to take priority with the new API.

If you are up for implementing such a change yourself, feel free to just use this API, otherwise we can close it and open a feature request issue 👍

[Doc94]

Then you mean a new event "ExplodeEvent" for handle all the explosions, like a merge of the current entity and block not?
This require send a canceled state of this new event?
PD in teory just need call this new event in the sane place but later of the bukkit?

[Doc94]

Ok based in the comments here and in discord i rework this PR for keep the changes but also the new calls just being called in the new event called...
i dont like "duplicate" the CB code for the paper event but dont wanna mess with strange behaviours for use the same method for call the paper event and make changes...

[Doc94]

Exposed the DamageSource used in the explosion to the event... i feel this can help if consider the damage source can have many behaviours based in how datapacks can use the explode effect.

[Lulu13022002]

This pr break fire explosion done via world.createExplosion(location, 3, true, false) by filtering empty blocks i guess. Ideally should only affect the event but it's tricky cause block list is mutable

[Doc94]

This pr break fire explosion done via world.createExplosion(location, 3, true, false) by filtering empty blocks i guess. Ideally should only affect the event but it's tricky cause block list is mutable

not sure how handle this.. i mean still being the "normal" behaviour with or not this PR i think...

[Lulu13022002]

With your PR that fire explosion doesn't spread fire on the ground which is an unintended side effect

[Doc94]

With your PR that fire explosion doesn't spread fire on the ground which is an unintended side effect

i see the issue... not sure when i broke maybe the change from getType.isAir to isEmpty... i make a change for allow the empty things for the fire and looks is working. if its not a good "fix" can just revert the thing for the empty check

also i remove the shuffle in the KEEP behaviour because just make changes not related to the vanilla behaviour...

[Lulu13022002]

That change is completely irrelevant, i have already explained the cause of that issue in the original message. It's not only affect your new event but regular ones as well. So i will open a new issue about that (the fix you commited is a workaround). And you broke spigot further with your equivalent commit.

[Doc94]

That change is completely irrelevant, i have already explained the cause of that issue in the original message. It's not only affect your new event but regular ones as well. So i will open a new issue about that (the fix you commited is a workaround). And you broke spigot further with your equivalent commit.

Yeah for the not explosion is handled by the keep maybe and how im now calm the event in that place the filter take all... Currently not sure why even need filter that... That block is in the list maybe just send all blocks and if user wanna they can filter that... Based in the first commit.
Or not sure if you have another suggest for this thing

[Lulu13022002]

The yield shouldn't be needed there no blocks explode anyway

[Doc94]

yeah but not make "damage" keep that.

[Doc94]

about resolve #11999 now the filter is gone for allow the event show the same blocks (from positions) used in vanilla and avoid the mess with reduction of the fire.

[Lulu13022002]

You can't remove the filter for the old events without updating the javadocs which is kinda a breaking change so not sure but the new one can hold empty blocks fine.
Cancelling the events still spread fire it seems mainly because you removed the filter.

[Doc94]

You can't remove the filter for the old events without updating the javadocs which is kinda a breaking change so not sure but the new one can hold empty blocks fine. Cancelling the events still spread fire it seems mainly because you removed the filter.

well already can consider a "breaking" change the thing about how now spigot fire the events for the keep behaviour and paper not (not in that events but yes in the new) but i make the rollback with the patch for the bukkit events.

the fire thing is maybe because just check the cancel for the keep behaviour and not in the main condition.. i move that for cover all calls.

[Doc94]

this is intended?