Draco18s

or super.drawGuiContainerBackgroundLayer(...)

Those ones are used by Forge to determine the load order. Not putting that may lead to your mod loading before your dependency, which would be bad.

Yes, both use the modid where I put the ellipses and would be equivalent to required-after. The mcmod.info file is not actually used by Forge for the most part, but is supposed to contain the same info as the @mod header so that websites like Curse can read the information.

You can't exceed 1x1.5x1, that's effectively a hard limit imposed by Minecraft, any larger and you will get unexpected behavior.

Only if you want to either: a) test in the development environment b) using an exposed API You need to add dependencies = "required-after:..." or dependencies = "after:..." depending on hard or soft dependencies ("after" just loads your mod later, "required-after" means that the other mod MUST be present or your mod can't load). Technically, nothing, but you should add a "dependencies": ["..."] for any hard dependencies If your not using an exposed API, nothing. Otherwise find and follow the directions in the dependencies block. The former uses if(Loader.isModLoaded(...)) to control logic (e.g. recipes) of itself. The latter uses API calls. For example: this. See above The @Optional annotation can allow you to move a hard-dependency to a soft-dependency. The only example I have is from 1.7.10 and I think the package changed.

Do you see this line? https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/EasyRegistry.java#L72 Do you have that line in your own code?

My mistake, I looked at my own code and saw I was doing it on both sides and didn't investigate further. And it was midnight.

https://github.com/DragonFerocity/expandedaesthetics/blob/master/src/main/java/com/DragonFerocity/expanded/blocks/ModAlloyFurnace.java#L172 That has to be called client-side too Also, this will always be true because of this line.

Why do you need these events? What is your goal (describe it as what the player observes)

If your code doesn't change (the java files) then Eclipse doesn't (always) check to see if the resources have changed.

That if-statement will never be true, you're comparing an Item with an ItemStack which are completely different types.

Well. Yes. All blocks behave that way.

There's a ! there. if (!canHarvestBlock(state.getBlock(), player, world, pos))

You do know that your shaped recipe requires the input sand to be in the center of the 3x3 grid, right? And only that space.

You're unlikely to accomplish this. You would need to store every block position when a block is placed and the location is water, then check that list every time a block is broken, storing the data in per-world storage. It won't be easy.

Metadata in 1.9+ is blockstates. Metadata is just the underlying integer representation. http://mcforge.readthedocs.io/en/latest/blockstates/states/ You will want to combine blocks that have similar functionality (e.g. all colors of wool in Minecraft Vanilla are the same block, but with different metadata) but separated by some "TYPE" aspect (color, material, etc)

You still need to attach the capability to the entity

If you want your item to open a GUI, why are you checking to see if a TileEntity exists in the world?

LivingHurtEvent is fired when an entity takes damage and includes the source.

Try without the ToString() https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L82

Container items aren't part of the recipe itself, they're handled by the crafting grid.

Are you using ItemBlock? That's your problem. ItemBlock always places meta-0. You need ItemMultiTexture or your own ItemBlock class. Not sure about the textures off-hand.

Caused by: java.io.FileNotFoundException: expanded:models/item/campfire.json

You haven't registered your proxy as an event handler class.

ModelRegistryEvent is still a client-side event: import net.minecraftforge.client.event.ModelRegistryEvent; Just because it isn't called on the server doesn't mean that the class even exists. Ditto with the ModelLoader class.