Choonster

ItemHandlerHelper.giveItemToPlayer will attempt to insert the specified item into the player's inventory and drop any remaining items at their feet. Your onItemRightClick method will never be called from anywhere, because it doesn't override a super method. You can't just add random arguments to override methods when you need a value of a specific type. You've also commented out the @Override annotation, which exists specifically to tell you when a method doesn't override a super method.

There were 4 model loading errors that weren't displayed. The number of errors displayed is controlled by the forge.verboseMissingModelLoggingCount system property, the default is 5. Set this property to at least 9 (using the -D JVM option) and post the new log.

Yes.

Set the JAVA_HOME environment variable to the path of your JDK. In Windows 10, you can do this by searching for "environment variables" in the Start menu.

Since you have an item model called sandcastle_mould, Minecraft will use that for every variant of your Item . It will only look for the blockstates file called sandcastle_mould if there's no item model. I explain the model loading process - including how ModelResourceLocation s are mapped to models - here.

This isn't quite the case. World#setBlockState(BlockPos, IBlockState) calls World#setBlockState(BlockPos, IBlockState, int) with 3 as the flags argument. Flags are additive, so 3 is both 2 (send the change to clients) and 1 (cause a block update).

PATH is not JAVA_HOME . You have JAVA_HOME pointing to a JRE rather than a JDK.

Are you registering the Render with RenderingRegistry.registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit? Post your code.

The method signatures I posted aren't valid Java themselves, they're using an abbreviated notation without the parameter names. You weren't meant to blindly copy-paste them.

The only methods you need in HandsawRecipes are the following: void addHandsawRecipe(Block, Function<IBlockState, ItemStack>) Get the Function for the Block from the Map . If it exists, log or throw an error. If it doesn't, add the Function argument to the Map . [*] @Nullable ItemStack geResult(IBlockState) Get the IBlockState 's Block , then get the Function for that Block from the Map . If there's no Function , return null . If there is a Function , call Function#apply with the IBlockState and return the resulting ItemStack . If you're going to use a singleton instance like FurnaceRecipes does, you'll also need an instance field and a static method to get the instance.

Your models have syntax errors. Use JSONLint to validate JSON, it will tell you about any syntax errors. builtin/generated still exists, but standard item models now extend item/generated . This extends item/generated and defines the standard display transformations (the "display" block). This also applies to blocks: most block models (e.g. cube_all ) now extend block/block , which defines the standard display transformations. The thirdperson and firstperson display transformations no longer exist, they were split into left- and right-handed versions. Your item models should extend item/generated . Your block and item models should only define display transformations if they're different to the standard ones.

It would help if you told us which class this method is a part of. If it's ItemFood , the new signature is ItemFood#setPotionEffect(PotionEffect, float) ; i.e. you need to create the PotionEffect yourself instead of passing the Potion , amplifier and duration to ItemFood .

I explain this here.

Only vanilla fields and methods (and overrides of vanilla methods) get obfuscated to SRG names, anything added by Forge remains unchanged. I wouldn't recommend using reflection on Forge classes, though; you should be using the public API to get what you need. If there's a compelling reason that you need access to something that isn't public, consider opening an issue/PR on GitHub asking for public access.

A Fluid object only defines the physical properties and texture of a fluid, it can't exist in the world or in inventories itself. An IFluidBlock is a Block that represents a Fluid in the world. You need to register a model for this Block and its Item form like you would any other. Forge provides the forge:fluid model for this purpose, which uses the textures and phase (liquid or gas) defined by the specified Fluid . You need to use Forge's blockstates format to tell the model which Fluid to use. I register models for my IFluidBlock s here. This tells each Block to use the variant of this blockstates file with the same name as its Fluid .

I think the best way to implement this is to have your recipe class store a Map<Block, Function<IBlockState, ItemStack>> . You can then have a method that takes an IBlockState , looks up the Function in the Map using the Block , calls the Function with the IBlockState and returns the resulting ItemStack . Return null if there's no Function for the specified Block . You can then call this method in ItemHandsaw#onItemUse . If it returns a non- null value, set the block to air and drop the ItemStack in the world.

Call UniversalBucket.getFilledBucket with ForgeModContainer.getInstance().universalBucket and the Fluid . This will return an ItemStack of the universal bucket filled with the Fluid . The ResourceLocation arguments of the Fluid constructor are the locations of its still and flowing textures.

Use World#getBlockState to get the IBlockState at the specified position. Use IBlockState#getBlock to get the Block represented by the IBlockState . If you only want to handle vanilla logs, check if the Block is Blocks.LOG or Blocks.LOG2 . If it is, use IBlockState#getValue to get the value of the BlockOldLog.VARIANT property (if it's Blocks.LOG ) or the BlockNewLog.VARIANT property (if it's Blocks.LOG2 ). This will give you a BlockPlanks.EnumType value. You can then create an ItemStack of Blocks.PLANKS , using the value returned by BlockPlanks.EnumType#getMetadata as the metadata. To drop this in the world, use Block.spawnAsEntity . Handling modded logs will be a bit trickier because there's no easy and reliable way to know what the corresponding planks are. You can use Block#isWood to check if a block is a log. To get the corresponding planks, you can either: Assume that a single log in the crafting grid will result in planks (which may or may not be the case): Create an InventoryCrafting with a dummy Container , put an ItemStack of the logs in it and use CraftingManager#findMatchingRecipe to get the resulting planks ItemStack . Pros: Has the potential to work for any mod without having to explicitly add support. Cons: Not guaranteed to work for all mods. [*]Create a class to hold the log to plank conversion recipes (similar to FurnaceRecipes ), register a recipe for each vanilla log and then use this in ItemHandsaw . You can then add recipes for other mods' logs as needed. Pros: Guaranteed to work for any mod you've added support for. Cons: Only works for mods you've explicitly added support for.

For examples of capabilities, look at the capabilities provided by Forge itself ( CapabilityItemHandler , CapabilityFluidHandler , CapabilityAnimation ), the Forge capability test mod or my own mod's capabilities (API, implementation).

The three float arguments of Item#onItemUse are where the player clicked on the block. The block's position in the world is given to you as the BlockPos argument. Always annotate override methods with @Override so you get a compilation error if they don't actually override a super method.

ModelResourceLocation was moved to the net.minecraft.client.renderer.block.model package.

I'm not entirely sure about that part. I think the skin texture will be added to the texture atlas if you override IModel#getTextures to return it, you can then use the bakedTextureGetter argument in your override of IModel#bake to get the TextureAtlasSprite . You can probably create and store an instance of NetworkPlayerInfo in your IModel 's constructor, creating a GameProfile from the IModel 's UUID . Use NetworkPlayerInfo#getLocationSkin to get the ResourceLocation of the skin texture. If you call this early (e.g. in the constructor), the skin should be downloaded in the background and may be available by the time the texture atlas is created.

When you extend a vanilla class, you need to override the vanilla NBT methods. When you create your own class that can be written to NBT, just implement INBTSerializable .

Post the FML log.

I'm not sure how to use a custom build of Forge in your mod, but cpw has a video explaining how to add your mod to a Forge development workspace in IntelliJ IDEA .