Draco18s

I wonder how vanilla handles this with doors, pressure plates, and torches...

Generally speaking the way to handle this is to catch the ItemEntity spawn (EntityJoinedWorldEvent) and substitute a custom entity class (cancel the event, spawn your own item entity).

What are you trying to do? This code: if (getItem().onEntityItemUpdate(this)) return; Calls the onEntityItemUpdate method on the Item. You don't subscribe to it, it's not an event, it's a method you override in your item class.

My point was, you don't make random items on the client, you only do it on the server. If you are not on the server, do nothing, if you ARE on the server, do what D7 said.

Through the magic of network packets. That said, I don't see why you'd need it here.

If you're not on the server, do nothing. The client has no say here.

Ooh. Yeah, good point. Nothing exists right now that would do that, but that sounds like how it could be done. I had to do the loot modifier system because no one else had, so you might need to do the same.

Or store them in your own list.

PlayerEvent.BreakSpeed

Knowing for a fact that it exists, and that it calls ForgeHooks.modifyLoot(...), I'm going to tell you to look harder.

I wonder how Blocks (being harvested) calls loot to be dropped. It's gotta call some code somewhere...

You need to set the block's render layer. There are dozens of posts on this forum about this problem.

Yes. Block states. Which are defined in the log class.

You could try setting the original damage value to 0 and not cancelling it. Not 100% sure this'll work. Or you could leaves the original damage alone and subtract off that amount from your desired amount and deal a second instance of damage.

Try the blockstate json files

The image wouldn't work, unless it was a url, as then other players wouldn't see it. 2 and 3 are controllable with vanilla NBT I think, but you can do it with capabilities too.

Also, you should use Capabilities. And key your NBT tags with your mod ID.

It's javadoc notation, it means that the method is an instance method, not a static method. You still use a . when calling it.

BlockPos#offset(direction, distance) Level#setBlockState(pos, state)

Blocks cannot be larger than 1x1x1. If you need it to fill more space, you need more blocks.

Basically yes. You're probably going to have to do some poking around and testing on your own, but the Java side of a GlobalLootModifier is code like any other class, which means it has access to the vanilla loot functions. Just implement the doApply function and you're set. If you're clever enough you can make your modifier parse the desired loot function and do a lookup (via the existing registry), rather than only do one thing. The only reason that loot functions aren't parsed and handled for you (the way conditions are) is because generally a modifier is a loot function (that is, performing the same role), so there wasn't an explicit need.

The fuck? Why not just compare the return value to something useful? Like, I don't know, getEffect() == null? Cool you stored whether or not the player has the absorption effect in a local variable. Which you then never use.

Cough.

"Not easily." There's no prebuilt solution to draw blocks (or block outlines) through walls. I did something like this using particles, however.

Why does your custom condition live in the vanilla namespace?