Draco18s

Convert it to a string..toString()

new ModelResourceLocation(item.getRegistryName(), ...

This will crash the dedicated server. The ModelRegistryEvent is client side only. You should set your unlocalized name to your registry name; Problematic Code #10 . There is no reason for this to be in the Item class, all items need models and you can make that call externally just fine: HanksMod.proxy.registerItemRenderer(ModItems.copperIngot, 0, copperIngot.getRegistryName())

Problematic Code #2

1) You do not need the display tags if you use item/generated (or item/handheld for tools) instead of builtin/generated 2) Show your log 3) Show where you register your item models

1) Do not include completely empty lines in your recipe. Those spaces force the slab to be made in the bottom row of the crafting grid, not "anywhere it fits" as all vanilla recipes do. 2) Post the log, there might be an error in it.

item is a local variable. So no, your code there won't work.

Because of static initializers. In order for your BlockBase class to add its ItemBlock to ModItems.ITEMS, all your other static fields have to be initialized. But it can't, and there's no line number because of how static initializers are constructed.

Rather than get(0), there is a method that will get an item stack based on its equipment type. Use that.

Uh. You're looking at it. "src" means "source" it is not itself a class or package.

Cough. EnumHelper, supplied by Forge. Cough. Also, if this is your own class, why the hell do you need reflection to do this?

In addition, registry names (and therefor, by extension, unlocalized names) should be all lower case, as you should be using item.setUnlocalizedName(item.getRegistryName()) so that your mod ID is part of your item's unlocalized name.

item.setUnlocalizedName(item.getRegistryName().toString());

Also, don't set the registry name to the unlocalized name. Set the unlocaled name to the registry name. Unlocalized names should be used for displaying the item's name only. Problematic Code #7

"parent": "em:block/bottom_ruby_refined_slab" ?

...code? Also, 1.8 is ancient. If you want to use 1.8, at least use 1.8.9

Here's an example of an IItemHandler that does not allow extraction. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/internal/inventory/OutputItemStackHandler.java

Yes, that is asking an external device to reply to you.

No, a computational device only knows it's local IP address. It don't know the external IP address of every router and other system it sits behind. In fact, it can't know its public IP without asking an external source, "Hey, what IP did this message come from?" And even then, if the external source is not properly chosen (e.g. another device on the same internal network), it still doesn't know its "public" IP.

Get the player's equipped items Check them against your armor types

You need to take the model from the target block and combine it with a model that has the overlay, then bake and return that.

Why are you doing this and not implementing an Energy Capability? Capabilities are the solution to the stacks of mod-supplied interfaces.

Show your EntityTable class. Try pixels, measured from the top left.

Option a: have your machines call onUpdate() on their stacks Option b: have your machines give the stacks the NBT No That's false. /** * Called when item is crafted/smelted. Used only by maps so far. */ public void onCreated(ItemStack stack, World worldIn, EntityPlayer playerIn) { }