fix Bug #4037

[eygwi]

Description

This PR addresses a critical item duplication exploit involving Explosive Tools (e.g., Explosive Pickaxe) and blocks that rely on a support block (e.g., Elevator Plates, Rails, Torches, Carpets).

The Issue:
Previously, when an Explosive Tool was used on a cluster of blocks, the order of destruction was not determined by height. If the tool destroyed the supporting block (floor) before the attached block (Elevator Plate):

1. The support block breaks.
2. Minecraft physics detects the attached block is floating and breaks it, dropping an item (Drop 1).
3. The Explosive Tool continues its iteration and tries to break the attached block again, dropping the item a second time (Drop 2).

This resulted in infinite duplication of Elevator Plates and similar items.

Proposed changes

Modified ExplosiveTool.java to implement a sorting mechanism for the destruction list.

1. Y-Level Sorting: The list of blocks to be destroyed (blocksToDestroy) is now sorted by Y-level in descending order (Top to Bottom).

   • Logic: blocksToDestroy.sort((b1, b2) -> Integer.compare(b2.getY(), b1.getY()));
   • This ensures that attached blocks (Top) are broken by the tool before their support blocks (Bottom) are removed.

2. Safety Check: Added a validation check if (block.getType() != Material.AIR) before breaking to ensure the tool does not attempt to break a block that has already been removed by other means/plugins.

This change completely resolves the duplication glitch while maintaining the intended behavior of the Explosive Tool.

Related Issues (if applicable)

Resolves #4037

Checklist

• I have fully tested the proposed changes and promise that they will not break everything into chaos.
• I have also tested the proposed changes in combination with various popular addons and can confirm my changes do not break them.
• I have made sure that the proposed changes do not break compatibility across the supported Minecraft versions (1.16.* - 1.20.*).
• I followed the existing code standards and didn't mess up the formatting.
• I did my best to add documentation to any public classes or methods I added.
• I have added Nonnull and Nullable annotations to my methods to indicate their behaviour for null values
• I added sufficient Unit Tests to cover my code.

[github-actions]

Pro Tip!
You can help us label your Pull Requests by using the following branch naming convention next time you create a pull request. ❤️

Branch naming convention	Label
feature/**	🎈 Feature
fix/**	✨ Fix
chore/**	🧹 Chores
api/**	🔧 API
performance/**	💡 Performance Optimization
compatibility/**	🤝 Compatibility

---

If your changes do not fall into any of these categories, don't worry. You can just ignore this message in that case! 👀