Draco18s

If that's the entire error, I'm not sure. It could be that your blockstate is fine, but the model is not.

Banner at the top of every page:

You need to include all the variant properties. When using Forge states you can list each property separately and it will do the combinations for you: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/resources/assets/harderores/blockstates/axel.json#L10-L34 Notice how there is both a axel_orientation variant and a facing variant.

Not sure, but why is your mcmod.info file inside your item models folder? https://github.com/IAmwYvern/bettercombatmod/tree/master/src/main/resources/asstes/bettercombatmod/models/item Additionally, your repo is incomplete. You are missing all of the gradle files that make your repo a compilable project. Eg, all of this: https://github.com/Draco18s/ReasonableRealism/ Third, Update to at least 1.14 to receive support:

BTW, make your modID longer. You have 64 characters of length, use them. "pme" is not unique enough.

Show your code

No, use Forge states. https://mcforge.readthedocs.io/en/1.13.x/models/blockstates/forgeBlockstates/ Eh, that's more or less how it works. Furnaces handle it in AbstractFurnaceBlock in a method called getStateForPlacement().

Check your logs.

Those values are in order: count, bottomOffset, topOffset, and maximum This call to nextInt must pass a value > 0: int j = p_212852_1_.nextInt(p_212852_2_.maximum - p_212852_2_.topOffset) + p_212852_2_.bottomOffset;

Your incubator only has 1 slot: https://github.com/SrAranha/ChicksCanGrown1.14.4/blob/master/src/main/java/com/aranha/chickscangrown/blocks/IncubatorTile.java#L59

((ServerWorld)world).getSaveHandler().getWorldDirectory();

You're right. It should.

You may need to write your own ILootCondition. They aren't difficult (mostly "copy paste an existing class that's pretty close and change the trigger, then fix all the errors working backwards").

So, a couple things here. Call getCapability once and do all of the add-slot calls inside a single ifPresent. Unless you have different actual slots, in which case you need to change the getCap call to include a Facing (Direction) parameter to distinguish between them (however in this context, you want a combined wrapper anyway). Two, you're adding a basic SlotItemHandler which does not know and does not care about your slot insertion restrictions. You didn't include your TileEntity code, so I can't be sure that the IItemHandlers it uses know or care about your slot insertion restrictions either. Note these: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/inventory/SifterContainer.java#L27-L29 (Note that inven is coming from the server side here while the client side gets a dummy object from the other constructor). And this class: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/inventory/SlotDust.java#L17 And the related stack handler: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/capability/SiftableItemsHandler.java#L15 (You can ignore the on-changed method; that was just there to make the usage of my entity play nice: it has two slots and does a simple crafting action turning 8 tiny dust into 1 large dust, all that method is there for is so that it doesn't get jammed with two stacks of the same item with fewer than 8 in each stack, so it combines them resulting in a free slot)

Well, such things have to be listed in the imports, but its not, which means its in the same package. Oh, so it is. https://github.com/kwpugh/gobber/tree/1.15/src/main/java/com/kwpugh/gobber2/world

Use the data directory in resources. Here's a sample loot table. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/resources/data/harderores/loot_tables/blocks/millstone.json

It doesn't save blocks, it doesn't generate blocks, it doesn't care about any data in it (it will always check what's there first, and if its what it wants, it uses it, if not it replaces it).

No, check if world.isRemote. If the event doesn't give you a world, get it from the player.

Your best bet will, probably, be a fake world (you will need to use a dimension). You'll have to clone the item stacks in the player's hands as well to avoid inadvertent modification (e.g. barrel blocks that get right clicked with an item to store items) and may have to use a fake player as well (this class already exists; FakePlayer). Feel free to examine my mod for how I use my Filter Dimension to check to see if items can be inserted into TileEntities or not. https://github.com/Draco18s/ReasonableRealism/tree/1.14.4/src/main/java/com/draco18s/industry

Yes. Once from the client Once from the server

Have you tried contacting the author?

There aren't any resources because 1.15 is so new most modders haven't had a chance to poke around yet.

Your block also needs to have a blockstate property that matches the json file. The json file isn't magic.

No. Its a vanilla thing. The net.minecraft.entity.ai package contains various AI tasks, such as ZombieAttackGoal, MoveThroughVillageGoal, and NearestAttackableTargetGoal. If you were to look at any given entity and the method applyEntityAI(), you'd find these. Previously these were stored in an array list type structure called tasks (its now called goals or goalSelector). You can. But there's no need if all you're doing is changing the entity goals. You can just alter their goals (goalSelector is public and has both add and remove methods), rather than replicating their entire class's code just to give it different goals. I don't see why, the code already checks for ladders and does appropriate things. The only thing you should have to do is give mobs a different pathfinder so that the pathfinder knows about ladders.