Choonster

To store multiple values in your metadata, you need to use bitwise operations to combine the values into a single integer. The problem here is that metadata is restricted to 4 bits, but the 10 possible values of EnumRailDirection require 4 bits to store and the 3 possible values of EnumPartType require 2 bits to store. This means that you can't store both values in the metadata, you may need to store the PART property in your TileEntity instead. You can still have it as a property of the BlockState (and thus decide the model based on its value), just override Block#getActualState to return an IBlockState with the PART property's value retrieved from the TileEntity at the provided location. Look at BlockFlowerPot for an example of an enum property stored in a TileEntity instead of the metadata. Edit: I didn't realise you were using separate instances. Either use separate instances or store the PART property in the TileEntity . Like GotoLink said, there's no need to do both.

Do you understand how the code works? You have an instance of your ItemQuinqueCase class stored in a static field of some class (e.g. TokyoGhoulMod or ModItems ), return a new ItemStack of this Item instance from ItemQuinqueDoujima#onItemRightClick . Do the same in ItemQuinqueCase#onItemRightClick , except return an ItemStack of the sword instead of the case. You don't need the ItemQuinqueCase field if the result of the swap is hardcoded, I just used that to demonstrate two items that use the same class swapping to each other.

If the model's shape is working, it's an issue with the texture being invalid or missing. If the block is appearing as a cube, it's an issue with the model being invalid or missing. Which is it? If you're using the vanilla blockstates format, you need to define the model for every possible combination of property values. The ones that are listed as missing are the ones you haven't defined a model for. You can also use Forge's blockstates format, which lets you specify how each value affects the model instead of defining the model for every combination of values.

Override Item#onItemRightClick to check if the player is sneaking ( Entity#isSneaking ). If they are, return an ItemStack of the other Item ; else return the result of the super method. You can see a basic example of this here.

There should be some errors in the log telling you what went wrong. The Grey Ghost has a guide to troubleshooting block and item rendering here.

Yes. I'd recommend creating a separate class each for your blocks and items and using those classes to instantiate, register and store your Block / Item instances. You can see an example of what I'm talking about here. You should keep the registration out of the constructor, that way you can more easily use the same class for multiple block/item types.

You've created a recipe for an ItemStack with a null Item . This is because you've registered your recipes before instantiating and registering your blocks. You should instantiate and register your items and blocks in preInit (don't instantiate them in field initialisers) and then add recipes in init.

Forge's Blockstates format can reduce the number of individual models you need to write.

RenderingRegistry.addNewArmourRendererPrefix is an alternative to overriding Item#getArmorTexture . You can call it with the prefix of your textures and pass the returned int to the ItemArmor constructor so it's assigned to the ItemArmor#renderIndex field, the prefix will then be used for your item's armour texture. Look at RenderBiped.getArmorResource to see how it's used. I didn't know about this beforehand, I just used my IDE to look at the source of RenderingRegistry.addNewArmourRendererPrefix and find usages of the array it populates. You're better off overriding Item#getArmorTexture instead of using RenderingRegistry.addNewArmourRendererPrefix , since the former allows you to specify the resource domain of your textures instead of requiring them to be in the minecraft domain.

You're calling a method ( RenderingRegistry.addNewArmourRendererPrefix ) that references a client-only class ( RenderBiped ) on the server. All rendering-related stuff should only be registered from your client proxy, that way it's only called on the client. In your base proxy type, create a method called something like init or registerRenderers (the name doesn't really matter) and then override it in your client proxy to call RenderingRegistry.addNewArmourRendererPrefix and any other client-only stuff that should be called in the same phase. Call this method on your proxy instance from your FMLInitializationEvent method (i.e. MainRegistry.load ).

To get the source code from a built mod, you'll have to use BON or BON2 to deobfuscate the mod and then use a Java decompiler to decompile it into source code. I list some decompilers and explain how to use BON in this thread. Keep in mind that most closed source licenses don't allow you to use the code in your own mod.

You've done something wrong. Post the latest versions of the ItemHSteelHelmet and HSteelArmor classes. Every item class must directly or indirectly extend Item . The inheritance chain for your armour classes should be something like ItemHSteelHelmet -> HSteelArmor -> ItemArmor -> Item (where -> means "extends from").

There are two types of events in Forge: Events that extend FMLEvent and are handled by a method with the @Mod.EventHandler annotation in your @Mod class (e.g. FMLPreInitializationEvent , FMLMissingMappingsEvent ) Events that extend Event and are handled by a method with the @SubscribeEvent annotation in a class registered on the appropriate event bus (e.g. BlockEvent.HarvestDropsEvent , PlayerEvent.ItemSmeltedEvent ) You're trying to handle an FMLEvent like it's an Event .

ItemHSteelHelmet , etc. should extend HSteelArmor instead of extending ItemArmor . This is what diesieben07 is telling you. If you look at line 236 of CraftingManager , you'll see that it's calling ItemStack#copy on the result of HashMap#get (the HashMap maps each character to its corresponding ingredient ItemStack ); get is returning null , causing the exception. This means that you passed null as an ingredient to GameRegistry.addRecipe on line 124 of MainRegistry . You should instantiate and register your items/blocks in preInit and add recipes in init. You shouldn't be doing anything in the constructor of your main class.

If you look at the usages of the playerLocation field you'll see it's only used for sleeping, it's not usually set to the player's current position. To get an Entity 's position as a BlockPos , use Entity#getPosition or the BlockPos(Entity) constructor.

setTextureName is the deobfuscated (MCP) name of the method, which is only used in the development environment. In the normal client, it has an obfuscated (SRG) name instead. You need to build your mod using the build Gradle task (either from the command line or IDEA's Gradle window), this compiles and reobfuscates the mod so it uses SRG names instead of MCP names. The built mod will be in the build/libs folder of your project.

Custom Main Menu is the mod causing the crash. Mods will usually say on their download page if they're client-only.

The blockstates JSON is parsed in BlockStateLoader.load .

Override Item#getContainerItem(ItemStack) to return the appropriate ItemStack (just return the argument if the item should remain unchanged) instead of calling Item#setContainerItem . By the way, use [ code ] [ /code ] tags (without the spaces) for code. You can also use a site like Gist or Pastebin to post code with syntax highlighting.

For a standard Block , using Material.water as the block's material will make it render with water around it while in water. I can't find the part of the rendering engine that handles this, so I'm not sure if it still applies to models rendered using TESR . You don't need to extend BlockContainer to have a TileEntity , just override Block#hasTileEntity and Block#createTileEntity .

Use PlayerEvent.Clone to clone IEEP data from the old instance of a player to the new one after they respawn. You shouldn't need to store the data in any kind of proxy, and there's no point in implementing IGuiHandler unless you're actually using the class as your GUI handler.

No, the models for each stage of the crop should be in assets/if/models/block. Your blockstates file should only use the resource domain and name of each model, don't include the block/ prefix. Look at assets/minecraft/blockstates/wheat.json for an example.

If you look at the method that threw the exception ( ItemSeeds#getPlant , line 61), you'll see it's trying to call getDefaultState on this.crops . The only possible value that could be null on that line is this.crops , which is set from the first argument of the constructor. This means you're passing null to the ItemSeeds constructor, probably because InsaneFoodsInit.init is called before InsaneBlocks.init .

You could probably make an IRecipe that only matched a stack of gold nuggets, but SlotCrafting#onPickupFromSlot specifically decrements the stack in each slot by 1.

The vanilla crafting table only supports recipes that require a single item for each slot, you can't create a recipe that consumes multiple items from a single slot.