#Detecting Torch Broken by Adjacent Block Break
sudden thistle
making this a thread
I've looked pretty hard into this and I'm not sure its possible without a hacky workaround like checking if adjacent blocks are a specific type when a block breaks
manic cave
Can't you just check the block break event's block's adjacent blocks by iterating all 6 block-faces and check whether that block depends on the broken block? Just an idea, not 100% sure of the exact implementation right now myself.
sudden thistle
I'm not sure how I can check whether a block "depends" on another
And its not really a great soultion due to the sheer number of cases I'd have to handle
Cacti, Paintings, Signs, Saplings, Torches, Banners(?)
probably more
sugar cane, rails, pressure plates
I'm looking into adding a new event to the Bukkit API but I'm not familiar enough with the project to really know how to do it
Looking at decompiled MC source, the blocks that have the functionality of being dependent on other blocks dont share a common interface or class
Which means I'd have to patch a LOT of MC files to make a new event for it
I feel I can do it, but I can think of at least a few different of approaches, and I'm not sure which would fit best into the Minimal Diff Policy
manic cave
Cacti, Paintings, Signs, Saplings, Torches, Banners(?)
I think these all have something in common tho. Like you can detect two connected chests by something on their block-state. I forgot what exactly that was tho.
I can take a look at this myself real quick, as it seems interesting and useful, if you don't mind waiting a bit on an answer.
sudden thistle
Ty
Thinking about this more, I think checking adjacent blocks still wouldnt work
Say you have vines on a block of stone, then theres a line of 4 vines below
You break the stone, find the vines below, but you dont get the other vines
manic cave
You break the stone, find the vines below, but you dont get the other vines
If you know that one vine is affected, you'd have to recursively expand from there, by going into the growth direction which makes sense ingame. So for vines, probably only downwards.
sudden thistle
I don’t really consider that a good solution. Currently the only option I have to see if other blocks are being broken is to check if the block being broken is adjacent to 80 different things. If it is, I have to check if it’s vines , then recursively check all of the blocks around the adjacent vine block
It would potentially WORK, but it would be a real pain in the ass to code, and be pretty inneficient
manic cave
I'm well aware of the fact that this approach is a bit invasive, but I'm currently not aware of any other solutions. Still having a look at it, but didn't come up with much. There just seem to be so many different cases.
sudden thistle
Yeah exactly
I don’t think its good programming to have to check it whether 6 blocks are instances of like, 80 classes
And to potentially have to recurse if they are
I think it’s something that needs to be implemented in Spigot/Bukkit/CraftBukkiy
manic cave
I think the BlockPhysicsEvent is actually what we're after. If I cancel that, vines stay, torches stay, itemframes don't despawn, etc.
Now the question of how to detect different physics causes arises, xD.
sudden thistle
Yeah, BlockPhysicsEvent literally triggers thousands of times per second lmao
Making comparisons every time it triggers is not feasible
manic cave
Maybe there are other, more detailed events triggered right there, gonna have to look through the source a bit more.
Funny how something so simple is such a pain to figure out
sudden thistle
Yeah I looked around that updateNeighborShapes method, it ends up just calling the updateShape method on every neighboring block
The updateShape method is declared in Block.java, but overridden 94 times
Most of the overridden methods call a canExist method that checks if the block has the conditions to exist
I remember specifically for Cactus’s canExist method it checks for sand, and water
They are basically all different
sudden thistle
Might have figured it out
I just need to call BlockData.isSupported() on the surrounding blocks
Still have the recursing problem though
sudden thistle
Nope, that doesn't work
I think since I'm calling isSupported while the BlockBreakEvent is firing that it is calling the underlieing method assuming the block being broken is still there
manic cave
Yeah, that's the problem. Since you can cancel the break event, the block is still there. If you wait a tick, you loose the ability to cancel. Maybe the block is gone in the physics event, as they call the methods which eventually lead to canSurvive right after.