Choonster

Run the dedicated server from your IDE. You'll need to add the --username [email protected] --password YourPassword arguments to your client run configuration to log into the server.

Run the dedicated server from your IDE. You'll need to add the --username [email protected] --password YourPassword arguments to your client run configuration to log into the server.

Look for usages of Blocks.emerald_ore using your IDE.

It was deprecated in this commit to allow items to use models specified in blockstates files.

You didn't set the domain of your ModelResourceLocation s, so it defaulted to "minecraft" .

The super method does literally nothing, so there's no reason to call it. It doesn't actually break anything, though. Calling a method from itself unconditionally is infinite recursion. This will cause a stack overflow error.

That will work, but why are you calling the super method? It does literally nothing except return 0, which you're not even using. It will also give a constant amount of XP rather than the random amount you were trying to achieve before.

Use the registry name system ( setRegistryName and getRegistryName ). In 1.8.9, these are methods of Block and Item ; in 1.9+ they're methods of IForgeRegistryEntry (implemented by Block , Item and other singleton classes). Registry names are IDs and must not change, unlocalised names can change at any time. Unlocalised names are only designed to be used for translation/display purposes, they're not guaranteed to be unique or consistent. Set the registry name in the constructor, then use the overload of GameRegistry.registerBlock / registerItem (1.8.9) or GameRegistry.register (1.9+) without the name argument. If the registry and unlocalised names of a block/item are the same (which isn't always the case, e.g. records), set the unlocalised name to the full registry name ( setUnlocalizedName(getRegistryName()) ). This will include your mod ID in the unlocalised name, preventing conflicts with other mods. The default model loaded for every Item is the one with its registry name, so use this as the default location for your models. I use this method in most of my items to set the registry and unlocalised names. I register my items here. I register my models here.

Again, there's no method with that signature so your method doesn't override anything. Look at the source of Block class or use your IDE to auto-generate the override method.

Ah, I didn't pay enough attention to your post. I'm glad you got it working. The overload of EnumHelper.addEnum you were using is broken for ArmorMaterial just like EnumHelper.addArmorMaterial is (since that's what it uses). You need to supply the correct argument types yourself like I do in the code I linked. Side note: You should create a single ArmorMaterial per armour type, not one per slot.

EnumHelper.addArmorMaterial is currently broken (see this issue), you need to use EnumHelper.addEnum manually. You can see how I do this here.

It's hard to understand what you're talking about. Post a screenshot/video of the problem. Also upload your FML log (logs/fml-client-latest.log) to Gist and link it here.

That has nothing to do with the crash. The crash happened from the server thread, which never has an OpenGL context (because the server doesn't render anything).

Don't save the item using its unlocalised name, use its registry name ( IForgeRegistryEntry#getRegistryName , inherited by Item ). This is the name used by Item.getByNameOrId . Why not store the item as an ItemStack or a 1-slot IItemHandler ?

If your block always has a TileEntity , simply return true . If it depends on the state, use the IBlockState argument to determine the return value.

TileEntity data is now sent with the chunk, override TileEntity#getUpdateTag to return a compound tag of data to send to the client. Some syncing is still done through TileEntity#getUpdatePacket , which should use TileEntity#getUpdateTag to get the compound tag for the packet.

Override Block#hasTileEntity(IBlockState) , not the deprecated Block#hasTileEntity() .

Always specify the Minecraft version you're using in your thread title. In 1.8 and earlier, give the block a TileEntity that implements IInventory . In 1.8.9+, give the block a TileEntity with an IItemHandler field to store the inventory and expose it through the capability system. You can see my slightly over-complicated implementation of a chest using IItemHandler here. This includes the naming and loot generation features of vanilla chests, but not double chests or animated models.

Do you actually know Java? There's no method with that signature in the Block class, so you've created a new method that's never called from anywhere. Always annotate override methods with @Override so you get a compilation error if they don't override a super method. I told you to override Block#getExpDrop , not call it.

You need unlocalised names for translation/display purposes, but that's it.

You can use an OBJ model anywhere you'd use a JSON model. A blockstates file can define a single model shared between all variants, a separate model for each variant or anything in between. You should be able to define textures for your model using Forge's blockstates format.

I didn't say anything about changing which class you extend. Delete your override of Block#onBlockHarvested (i.e. the method that calls Block#dropXpOnBlockBreak ). To control how much XP your block drops, override Block#getExpDrop .

The solution to all three problems: Don't call Block#dropXpOnBlockBreak , Minecraft does that for you.

Models are client-only, as are model loaders. You should only reference them from your client proxy.

Item instantiation and registration should be in a single class, done at the same time. Model registration should be in a separate class only referenced from your client proxy. You can see how I register my mod's items here and models here. My code uses several Java 8 features that can't be used if you're targeting an earlier version (the default is Java 6). Registry names already include your mod ID, don't add it again when registering your models. Unlocalised names are used as translation keys. When Minecraft displays the name of an item, it looks up the unlocalised name in the lang file for the current locale.