Draco18s

IIRC the example is bad and won't actually compile. This worked, and should still be mostly valid for 1.16: https://github.com/Draco18s/ReasonableRealism/blob/033da26f8ba4bcd25b0911aa9775764f12d7dbbe/src/main/java/com/draco18s/harderores/HarderOres.java#L106

Fabric also doesn't do as much. In fact it leaves a lot of things up to modders to figure out, fuck compatibility.

ItemStackHandler#insert and ItemStackHandler#Extract

There are better ways of handling multiple properties now instead of listing them all out. https://minecraft.fandom.com/wiki/Model#Block_states https://mcforge.readthedocs.io/en/latest/models/blockstates/introduction/ { "when": { "east": "true" }, "apply": { "model": "oak_fence_side", "y": 90, "uvlock": true } }

There's only two units when dealing with rotations: - Degrees - Radians Three, if you want to count degrees(-180,180) and degrees(0,360) as different.

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 Bl

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.