Draco18s

https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/industry/entity/WoodenHopperTileEntity.java#L21 https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/api/internal/inventory/MaxSizeItemStackHandler.java#L5

You don't. That's the point in time when you are saying "THIS ITEM HAS A CAPABILITY!" and it gets called once on itemstack creation. The getCapability method that you need to check against is different.

Items can't be CapabilityProviders (unless you want all copies of your item to share that data). Item inventories belong to ItemStacks. Override initCapabilities.

You probably don't need the fullCube and the simplify. You could use VoxelShapes.EMPTY (or however it's named) or you could just do: protected static final VoxelShape SHAPE = VoxelShapes.or( makeCuboidShape(0.0D, 2.0D, 0.0D, 2.0D, 14.0D, 16.0D), makeCuboidShape(14.0D, 2.0D, 0.0D, 2.0D, 14.0D, 16.0D), makeCuboidShape(2.0D, 2.0D, 14.0D, 12.0D, 14.0D, 2.0D), makeCuboidShape(0.0D, 0.0D, 0.0D, 16.0D, 2.0D, 16.0D), INSIDE), IBooleanFunction.ONLY_FIRST);

HMM.

Yes. But you don't register LootModifiers.

No I meant custom recipe types. Custom recipe types register their serializers. Blocks register themselves. So while you're not wrong, it's missing the point. The way that that most people think about it is "recipes" because "recipes are data assets" and that "custom recipe types" need to have a serializer registered rather than registering the recipe itself whereas items and blocks are just registered "normally." There's a degree of indirection that is the same between "Recipes" and "Loot Modifiers" that isn't present for "Blocks" and "Items." (Unless there's a BlockSerializer implements ForgeRegistryEntry around that I'm unaware of...)

Closer to how custom recipe types are registered, but yes: Things need to be registered. the forge/loot_modifiers/global_loot_modifiers.json file is there for specifying processing order (obviously if you don't include it or don't reference a registered serializer, it won't be run at all, even if it's registered). It doesn't do the registration. It's purpose is to allow data pack folks to resolve conflicts.

Show more of your code.

Create your own tag.

Note that other things also implement IWorld that are not Worlds.

Drop the item, then set the slot to air?

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

And don't forget that Global Loot Modifiers are a Thing.

This is not possible.

if(blockstate.getBlock() instanceof BeehiveBlock)

This is how you create a new type of event, you want to handle an existing event type.

Sounds like you are wanting to mess with the camera's rendering matrix.

Also, why aren't you using a shapeless recipe? You're just turning 9 of something into one of something.

Or deny the enchantment on bows.

I don't know how a Forge dev or admin helps solve that problem. Your friend would be a better person to ask.

Not Found (#404) This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff.

Because that's how Silk Touch works. If you want to override this behavior, you need to use a Global Loot Modifier.

Show this, because the event does not contain the information you want.

There's probably better resources, but I skimmed that one, and it had some interactive graphics that explain what goes on.