Is your feature request related to a problem?
During the implementation of a custom explosion, where I wanted more control over the blocks actually involved in the explosion, I came across a lack of API. Basically, you are currently only able to explode manually using boolean World#createExplosion(...) and its many many overloads. You cannot actually retrieve the blocks that would be broken by a theoretical explosion, and perform your own logic, so not exploding certain blocks, or running some sort of operation on them instead of just removing them.
Describe the solution you'd like.
I'd like a new collection of methods, List<Block> World#getExplodedBlocks(...), which run the underlying ServerExplosion#explode() logic until the this.calculateExplodedPositions() part, and then returns. Perhaps instead of it being a List<Block>, it could be more versatile and instead be a record class, which also contains data for stuff like potential fire locations (if fire is enable) and the damage done to entities. But I am down to discuss the specifics.
Describe alternatives you've considered.
There are basically three alternatives that I could think of, when I encountered this problem:
- Just do a very simple, basic calculation, which just takes all blocks from a radius and calls it a day. No extra logic.
- Run the
World#createExplosion method and listen for BlockExplodeEvents (probably the most sane variant atm)
- Use NMS + reflection to get access to the
ServerExplosion#calculateExplodedPositions, ServerExplosion#hurtEntities, and ServerExplosion#createFire methods (the one I went with)
Other
None 🚀
Is your feature request related to a problem?
During the implementation of a custom explosion, where I wanted more control over the blocks actually involved in the explosion, I came across a lack of API. Basically, you are currently only able to explode manually using
boolean World#createExplosion(...)and its many many overloads. You cannot actually retrieve the blocks that would be broken by a theoretical explosion, and perform your own logic, so not exploding certain blocks, or running some sort of operation on them instead of just removing them.Describe the solution you'd like.
I'd like a new collection of methods,
List<Block> World#getExplodedBlocks(...), which run the underlyingServerExplosion#explode()logic until thethis.calculateExplodedPositions()part, and then returns. Perhaps instead of it being aList<Block>, it could be more versatile and instead be a record class, which also contains data for stuff like potential fire locations (if fire is enable) and the damage done to entities. But I am down to discuss the specifics.Describe alternatives you've considered.
There are basically three alternatives that I could think of, when I encountered this problem:
World#createExplosionmethod and listen forBlockExplodeEvents (probably the most sane variant atm)ServerExplosion#calculateExplodedPositions,ServerExplosion#hurtEntities, andServerExplosion#createFiremethods (the one I went with)Other
None 🚀