Choonster

Have you got item models with those names in src/main/resources/assets/zylroth/models/item?

You installed a 1.7.10 mod on 1.8.8. Mods only work with specific versions of Minecraft.

You're using the same item model for every metadata value (the item's unlocalised name without the item. prefix).

PC worlds are 30,000 x 30,000. If your world is 256 x 256, something is very wrong. Screenshots and log files may help diagnose the problem. Use Gist to post logs.

Do you actually know Java? A solid understanding of Java is required to create mods. Pass the arguments of onBlockHarvested to the random class as method arguments, then do the same from the random class to the random event.

What I said before still applies: you have the world, position, blockstate and player as arguments of onBlockHarvested ; so pass whichever of these you need to the random class and then pass them to the random event.

You're using a 1.6.4 mod on 1.8.8. Mods only work with specific versions of Minecraft.

Then you already have the World the block was in, the BlockPos it was located at, the IBlockState and the EntityPlayer who harvested it as arguments of the onBlockHarvested method. Pass the required values to the code that handles the random events.

The OP has a second thread here, which Jabelar and myself have responded to.

You should be registering your blocks and items in preInit, then adding recipes in init. Don't register and add recipes in the same phase.

Your Eclipse crash report shows that you're running 1.8 rather than 1.8.8. ITickable was only added in 1.8.8. I'm not sure how you've managed to compile and run against different Minecraft versions.

You never create an instance of ItemMoneyWand , so its code is never used. Your onItemUse and onItemRightClick methods have the wrong signature, so they don't override the super methods with those names. Use the @Override annotation to ensure that your methods actually override the corresponding super methods - if it gives you an error, you haven't overridden a super method. Your IDE should have an option to automatically generate an override method, I suggest you use it. I wouldn't recommend overriding onUpdate unless you actually need to do something every tick. You should initialise the ItemStack 's NBT tag when it's actually needed - in onItemUse and onItemRightClick . Your onUpdate and onItemUse methods both create an ItemStack of MoneyModItems.itemMoneyDust , but neither of them use it. Your onItemRightClick method tries to add an ItemStack of MoneyModItems.itemMoneyDust to the player's inventory, but it doesn't check if the item was actually added; so it won't drop on the ground if the player's inventory was full like Buckets, Glass Bottles, etc. do. I told you how to do this in your previous thread.

I won't write your code for you. Learn Java properly before trying to make a mod. thenewboston has a series of Java tutorials . Vswe has tutorials on Java and modding here.

Full server and client logs (logs/fml-[client/server]-latest.log) may help diagnose the problem. Upload them to Gist or Pastebin and link them here.

You can deobfuscate mods using bearded-octo-nemesis. You can also download MCP mappings from the MCPBot website and manually look up SRG names (e.g. func_77637_a ) in the CSV files. If the SRG name doesn't have an MCP name, set up a 1.7.10 workspace and look at the method in your IDE. You may be able to figure out what its new name is by comparing the old and new versions of the class. func_111206_d is setTextureName (which no longer exists in 1.8 as it has been replaced with the model system) and func_77637_a is setCreativeTab .

Your code does nothing but set the ItemStack 's NBT tag to an empty compound tag. To do something when a player right clicks a block with your item, override Item#onItemUse . Item#onItemUseFirst should only be overridden if you need to do something before the block is activated and/or you need to prevent the block from being activated. To give the player an item, use InventoryPlayer#addItemStackToInventory (the player's inventory can be accessed from the EntityPlayer#inventory field). If this returns false the item wasn't added, so you should call EntityPlayer#dropPlayerItemWithRandomChoice to drop it on the ground. There are several examples of this in vanilla, like ItemEmptyMap#onItemRightClick and ItemGlassBottle#onItemRightClick . Use your IDE's Find Usages (IDEA)/Call Hierarchy (Eclipse) feature to find places where a method is called. You need a solid understanding of Java to write mods, there are lots of tutorials and other resources available online that you can use to learn Java. You also need to set up a ForgeGradle workspace by downloading the MDK (or src for 1.7.10 and earlier) and running gradlew setupDecompWorkspace . If you're using Eclipse, run gradlew eclipse to generate an Eclipse project. If you're using IDEA, open build.gradle and import the Gradle project then run the genIntellijRuns task and synchronise your project to generate the run configurations. LexManos has a workspace setup tutorial for Eclipse . There are probably various other tutorials available.

The blockstate system is essentially a convenient wrapper around metadata, so a regular block still can't store more than 16 combinations of property values. If you need more than this, you can store data in a TileEntity and override Block#getActualState to return an IBlockState with properties set from this data. Minecraft always calls this before choosing the model to render, so you can use these properties in your blockstates file.

You can't compile against a runtime dependency, make it a compile dependency.

Minecraft assumes that every block is an opaque cube by default, so it doesn't render any adjacent block faces that wouldn't be visible. You need to override Block#isOpaqueCube to return false for any block that isn't an opaque cube, this tells Minecraft to always render the adjacent block faces.

This is true in general, but running the deobfuscated versions of CodeChickenLib + CodeChickenCore will deobfuscate other mods at runtime; allowing you to use obfuscated versions of mods.

That looks like it should work. Is it not placing stairs facing east in the bottom half of the block?

You've passed the shape strings in their own object array ( Object[] ). Either pass them directly to the method like you have for the ingredients or pass them in a string array ( String[] ) (this only works because the code explicitly checks for a string array as one of the arguments).

Those recipes look like they should work. Which one isn't working and how is it not working? Is it crashing the game or does it just not output the result when you put the correct ingredients in? To make a shapeless recipe, call GameRegistry.addShapelessRecipe with the output ItemStack and the ingredients (can be ItemStack s, Item s or Block s). When you call a vararg method like GameRegistry.addRecipe you don't need to explicitly create an array, just pass in the arguments as normal and an array will automatically be created. This is the entire point of vararg methods.

You've commented out the last two lines of the Money Pickaxe recipe and the first line of the Pound Coin recipe. You've also commented out the Five Pound Note recipe, which contains an invalid shape string (the one with the O and a bunch of spaces).

You can store the UUID of the player who placed the block in a TileEntity (and then retrieve the player with that UUID to send a message to them at some point), but there's no way to detect the player who activated with a redstone signal.