[SOLVED] [1.10.2] Event in between BreakEvent and HarvestDropsEvent?

[Daeruin]

I have some block physics functionality that needs to be triggered by a block being broken, but it requires the block to actually be gone. BreakEvent fires when the block will be broken, but right before it's actually deleted, so it's too early for me. The blocks above the broken one won't be able to fall if the block isn't gone yet. HarvestDropsEvent fires after the block is broken, but it only fires if the block is being harvested—so it won't fire if you break a block without a tool of the proper harvest level. It seems like I need something in between the two.

 

I've considered using BreakEvent and just deleting the block myself, but this preempts the block from being harvested. That might be OK. You could imagine the block's drops being crushed by the blocks above it falling. It's probably the better of the two choices. Do you have any other clever ideas, or am I overlooking something?

Edited January 18, 2018 by Daeruin
Marking as solved

[Draco18s]

Wait, what?

Why aren't you just overriding onNeighborChanged and checking to see if the block below has Material.AIR?

[Daeruin]

I failed to mention I'm dealing with vanilla blocks.

[Daeruin]

So, yeah. I can't override onNeighborChanged in a vanilla block...

[Animefan8888]

25 minutes ago, Daeruin said:

So, yeah. I can't override onNeighborChanged in a vanilla block...

Very true, instead you should use the NeighborNotifyEvent.

[Daeruin]

I've tried using NeighborNotifyEvent. What I'm doing here is implementing gravity on a wider selection of blocks. But because I'm dealing with vanilla blocks, the functionality I need is in my custom methods. So notifying the block's neighbors does nothing for me on its own. I still have to manually check each neighboring block to see if they should fall. And as soon as one falls (the original block gets deleted and turned into a falling entity), it triggers another NeighborNotifyEvent where I check all its neighbors again, and I get into nasty infinite loops that cause stack overflows. At least, I think that's what's happening. It's why I moved back to messing with BreakEvent or HarvestDropsEvent.

[jabelar]

Maybe your original assumption  about needing the original breaking block to be gone is wrong. All these events are still fired in the same game tick. So why can't you go ahead and turn all the blocks above into falling blocks even if the block in the break event isn't actually converted yet? And if that is really a problem, then in the break event just create a "list" of BlockPos that should be checked later during the tick?

Edited January 17, 2018 by jabelar

[Daeruin]

Jabelar, you prompted me to review my whole system. You're right. I had forgotten that my method for determining whether a block has sufficient support is based on the assumption that the original block is gone. But I've now changed it so I'm passing in a parameter that includes a list of all blocks that have already been identified as unsuitable for support, including the original. This allows me to use BreakEvent, even though the original block isn't broken yet, which is better because HarvestDropsEvent might miss some blocks.

 

So, thanks for the advice and sorry it ended up not being related to Forge.

[jabelar]

Cool

21 hours ago, Daeruin said:

So, thanks for the advice and sorry it ended up not being related to Forge.

Actually this is the type of question that the forum is intended for. You had done your research, hit an issue, and needed advice. As long as people have made a credible attempt at doing something, everyone here is happy to help. And it is "related to Forge" since it is regarding how to make use of the events Forge provided. 

 

But yeah, in general if you hit the end of the road with a given approach, it is often best to go back and rethink things a bit. Glad it worked out.