Explosives rework

[IIHERO4]

ReImplement how explosives are treated overall, focusing on TNT bug https://github.com/andrei1058/BedWars1058/issues/292. IMPORTANT NOTES:

• This is completely untested, I didnt have anytime to test every version but it should work on theory
• 1.17 and 1.18 Version support is not implemented yet, so it needs some work from another person to copy the NMS implementation
• 1.17 and 1.18 calculateExplosionBlocks will throw an error (because its not implement ofc)
• when calculateExplosionBlocks is not implement in the BedWars.nms, it will use simple block detection methods such as isProtectedByGlass and Arena#isPlacedBlock (the acutal events will catch the error and perform alternatives)
• Event BlockExplodeEvent uses the same simple detection methods as stated above

This creates four new methods to VersionSupport and NMS support:

• public List<Block> calculateExplosionBlocks(IArena arena, Entity source, Location explosionLocation, float radius, boolean fire) [^1]
• public abstract List<Block> calculateExplosionBlocks(IArena arena, Entity source, Location explosionLocation, float radius, boolean fire, BiFunction<Location, Block, Boolean> callback) [^2]
• public boolean isGlass(Material type)
• public boolean isProtectedByGlass(Location pov, Block block) [^3]

Config Added explosion-settings.explosion-size, Possible Values: auto | {Any Number}

[^1]: Uses calculateExplosionBlocks(IArena arena, Entity source, Location explosionLocation, float radius, boolean fire, BiFunction<Location, Block, Boolean> callback) but with a predefined callback that is cached and made specifically for arenas [^2]: Mostly copied from its respective version Explosion NMS class, acts just like the vanilla one but with more control over the calculation of the exploded blocks [^3]: Performs a simple ray tracing to check whether the POV and the block have any glass block in between them

[IIHERO4]

needs testing and a look from an actual dev 💀

[IIHERO4]

New Issue has appeared (isProtectedGlass) particularly when iterating using BlockIterator some situations it doesnt work Example:

When placing the tnt instead of the green wool, the red wool gets destroyed when observing the path BlockIterator takes, it make sense:

As When plugging the parameters, the direction vector is (1, 0, -1) which generates this zigzag pattern

Really need some help on this one [SOLVED]

[LolFin2022]

Me nub.. So no help ;)

[IIHERO4]

Solved it by implementing actual and better ray tracing, By just keeping track of the difference of their vectors. its more accurate than BlockIterator.

I tested it with spamming tnts everywhere and it worked fine, i also played with it for a while and 0.3-0.25 as a step was the most accurate and not "heavy", 0.5 also worked fine on small/medium distances, it all comes down to how the delta vector it pointed to

Image illustrating the blocks that "Collides" with the ray

What is this doing

I call it the delta vector, dst - src will give that "delta" vector as delta + src = dst. Example:

|
|                   v2
|                 / 
|              /  (delta) 
|           /
|       v1
-----------------

in that case we start moving from v1 with "steps" to eventually to get to v2

[LolFin2022]

WIP it

[IIHERO4]

https://github.com/andrei1058/BedWars1058/pull/469/commits/1ff561ea2186c97778cd1f112d46e542cb5c46a1 idk might remove this if you want

[JT122406]

Have you implemented 1.17.1 or 1.18 support yet?

[IIHERO4]

Have you implemented 1.17.1 or 1.18 support yet?

at the moment, i dont have much time i gaveup bc somehow i dont have the world NMS class for that

[IIHERO4]

If someone wants to do it here is what you gonna need to do:

1. Look at the TNTPrimed explode method (if its not named, its usually where the ExplosionPrimeEvent is fired so look for that)
2. look at how world.createExplosion is made (params and etc)
3. then go to the createExplosion NMS method and see whats going on (try to link your thought with those "params")
4. after u get the hang of createExplosion try to do the same
5. Look into Explosion NMS class (look at V1_16_R if you want to know what that is)
6. just copy the explosion code from there and put it inside calculateExplosionBlocks

[IIHERO4]

@ajgeiss0702 is 1.18 & 1.17 support needed? I mean for those two version it will just detect glass better not recalculate it

[IIHERO4]

1.17 & 1.18 recalculation is not nessecary also alot harder bc of the new "feces"

[andrei1058]

This looks promising, I'll try to implement it in the update of january

[JT122406]

@IIHERO4 Can merge in upstream and handle conflicts?

[tomkeuper]

Is this still WIP or is it finished and only conflicts need to be resolved?

[tomkeuper]

Note that currently the only supported versions are: 1_8_R3, 1_12_R1, 1_16_R3, 1_17_R1, 1_18_R2 and 1_19_R2 Version support for other version could/should be removed

[andrei1058]

What's the impact on the main thread tho?

[IIHERO4]

I should note that In some cases this fails and over protect it as in the ray casting is too fat for example a block that is protected from one side and not the other will get protected because we check for the "components" of the ray (B = block, G = glass, A = air, T = tnt)

B G A T

ray checking: R x y (Since x hits G so its "protected")

I cant really work out a fix for this.

a second note is that i believe you could try to do it inside the NMS implementation itself instead of calling isProtected but i just didnt bother after couple of tries

[IIHERO4]

What's the impact on the main thread tho?

as far as im using it, it has close to none but you could tweak the "step" param to make less checks