Leaderboard

A stack of size 0 (but still with some other item) won't == ItemStack.EMPTY but it will still resolve .isEmpty() as true.

Do you check if you're on the client or server side? Also, I don't think you should create a new SoundEvent, rather use an existing one

Mods needs to tell Forge they can be disabled, however, most of them can’t due to the way they work, anything that is just visual and client-sided should be able to be disabled (eg minimap mod, NEI-like menu) but anything that is required on server and client will not be able to be disabled

You can always get a list of available events by looking at the Type Hierarchy for the Event class. Just make sure you open up the subclasses as well because some events have useful sub-events. It is worth going through regularly as new events are added fairly often, plus familiarity usually is helpful when you come up with new modding ideas you already know there are events to hook into. I think you're right that there probably isn't an event specific to what you want. By the way, for things that might be generally interesting that you want added to Forge you can go to the github MinecraftForge project and create an Issue, or even better you can create a Pull Request that fixes the issue. One thing you might be able to do is hook into the block's NeighborNotifyEvent and figure out what caused it. The worst case is just use a tick event and iterate through all the entities in the world (or using the living update event and process that entity) and see what they're standing on. You'd probably find some useful code in the Entity#move() method as it checks thing like whether it can walk on things.

Yeah, that's the only thing you can't do with the raytrace method, dodging. I guess it depends on what the player wants. Either way, you raise some fair points. Also, does the bow actually do less damage when you hit from afar? I thought it based it on the charge time. It'd be a lot easier to just implement the ticksexisted time and then base damage on the reverse of that. I imagine you woudln't want gravity for a flamethrower, or even reverse the gravity, then setDead() if ticks existed goes too high.

I was talking about using it for the physics logic as it makes sense that there would be a falloff point, unlike the ghast fireballs. It would also need to be dodgeable, would it not? You won't be able to avoid spawning in more entities with something like this, limiting the number of mobs which use it that spawn in at any given point would be a better choice anyway. Another place to check would be Mekanism's flame thrower for the best example of the mechanisms involved. Mekanism has issues, but the flamethrower worked well and used a "spawning in a bunch of entities" method.

Have you tried EntityItemPickupEvent? it has the EntityItem, from which you could get the item information you'd need.

I'm not that good to explain it, but take a look at this post and all the answers, you will find what you need here:

One of the dumbest ways might be checking if there are entities in front of the attacker, and deal damage to these entities, while spawning fire particles. The tricky thing might be making the particles flow in the correct direction, because you will have to use trigonometry for that.

To debug this sort of issue you should just trace the execution. In your print statement you should also print out the value of the x1, y1, and z1. If those look correct, then you should use the debugger and set breakpoints in the path navigator and run the debugger. In particular there are several reasons that it may return a null path. For example, the PathFinder#findPath() method is @Nullable. It will return null if the entity is already at the x, y, z location you specify -- in other words no path needed since it is already at the destination. The PathNavigator#getPathToPos() method is allso @Nullable (which makes sense because it calls the method above). It will return null if the navigator's canNavigate() method is false. That can happen if the entity is off the ground, if it cannot swim but is in liquid, or if the entity is riding another entity. So there are many reasons the path might be null, you just need to check to see which one is happening in your case. So print out your x1, y1, z1 and then set breakpoints in the methods I just described and see how it executes.

I don't have time to look at the code, but I think I remember that off-hand is only called if the main hand is empty. Remember this method/event isn't checking the hands, but rather acting on what is in the hands. So if there is something in the main hand it will act on that. So I expect you'll only see main hand, off hand, or nothing at all depending on what is being held in each hand. Note too that it depends on the type of thing in each hand, if I recall. So if you're holding something in the main hand that doesn't interact with blocks I think it may go to off hand. Everything I just said is pretty easy to check in code or test.

And even if it did (and somehow enforced it), IBlockState implementations are still allowed to call it.