I originally typed this up as a reply to a different thread, but decided not to hijack it with a tangent.

I've been trying to avoid having to make my own block class to change the bee anger mechanics and it looks like I can accomplish that by creating an event handler?

Specifically, making an event handler class for `RightClickBlock`, do my own check, and then effectively override the `onBlockActivation` method by passing DENY to setUseBlock, ALLOW to setUseItem, and run my own code on the BlockState? Because this all sounds good, except I can't figure out how to get the target BlockState from the event. Is there something I can do with `getPos()` to pull the blockstate at that position, or is there attached information on the event that I'm missing?

1 minute ago, diesieben07 said:

World#getBlockState with a position.

There it is!! Thanks so much!

edit: Ahh, never mind, I found the answer elsewhere, I need to call the methods on an instance.

Edited July 1, 20214 yr by InspectorCaracal
Got it!

I've hit a bit of an additional road block on this particular quest. Several, in fact, which is making me start to question if this is doable. >.>

First: the only way to get the associated block from the BlockState appears to be getBlock() which returns an instance of Block. But I need to know if the associated block is specifically a BeehiveBlock and if so, be able to access the BeehiveBlock methods on the block instance, not have it cast to Block.

Second: The onBlockActivated method usually returns back an ActionResultType. Where does that usually go? I assume I'll need to either handle the effects that would normally happen when the event got the result back from the method, or pass the result on to wherever it's supposed to go, for the faux-override code.

If either of these aren't doable then I suppose I'm back to the drawing board.

if(blockstate.getBlock() instanceof BeehiveBlock)

22 minutes ago, Draco18s said:

if(blockstate.getBlock() instanceof BeehiveBlock)

 

Right, I actually went and tried this and I don't know if it's just Eclipse complaining about something that would work in practice, but at least according to it, this won't do what I need.

I need to run a method off of an instance. In order to get the instance, I need a variable to put the results of getBlock into. If I declare that variable as anything besides a Block type, Eclipse informs me that it's an error

The method call in question is `.takeHoney(worldIn, hive_state, pos)`

If I call it as BeehiveBlock.takeHoney I get the static/non-static mismatch; if I call it as hive_state.getBlock().takeHoney then I get a message that Block doesn't have a takeHoney method AND the static/non-static mismatch; if I try to do `BeehiveBlock hive = hive_state.getBlock()` then I get a type mismatch message.

Edited July 1, 20214 yr by InspectorCaracal
adding more specifics

Aaagh, I just found an entire place it redundantly checks if bees should be angry which is again hardcoded to lit campfires, which means this idea isn't going to work for my end goal anyway.

14 hours ago, InspectorCaracal said:

If I call it as BeehiveBlock.takeHoney I get the static/non-static mismatch; if I call it as hive_state.getBlock().takeHoney then I get a message that Block doesn't have a takeHoney method AND the static/non-static mismatch; if I try to do `BeehiveBlock hive = hive_state.getBlock()` then I get a type mismatch message.

This is basic java. It's called "type casting."

4 hours ago, Draco18s said:

This is basic java. It's called "type casting."

I'm familiar with type casting, thank you. 😜 See: "not have it cast to Block"

I suppose I will thank you for reminding me to look up the explicit typecasting syntax for Java, since that was a useful side-effect.

I admit I started this thread in the hopes of discussing the general concept and implementation of a block activation method override done via an event handler, not for basic Java or debugging, but oh well.

Anyway! Based on my own attempt, the original topic doesn't seem like a very useful way to replace the onUseActivation method, because bypassing the entire use chain is rather more of a pain in the butt than it's worth. It's definitely a solid way to add an additional check beforehand, though, which I wish was good enough for what I'm doing (it should be!) but oof. The bee code has everything hardcoded in like three different places, it's really annoying. I'm going to have to just extend the classes with my own versions after all.