Choonster

The -D option sets system properties, which the -X options aren't. Forge's documentation explains how to give Gradle more memory here.

Block s should be created and registered before Item s. You should be using the new registry events, RegistryEvent.Register<Block> will be fired before RegistryEvent.Register<Item> . If you don't want to call a bunch of setter methods at the place of instantiation, move them to the constructor.

It looks like you passed a null Block to World#canBlockBePlaced from ItemCheeseCake#onItemUse . Side note: It looks like you've copy-pasted the vanilla cake code. Why not just use/extend the existing classes?

Aren't those just String constants he's using to name the NBT fields? Not sure how that could cause any trouble... The attributes field is storing the attribute values, the attributeTags field is storing the tag names.

I've never used Lombok myself, but it looks like Blood Magic uses a Gradle plugin for it; you may have more luck using this.

CapAttributeData.attributes is a static field, so it's shared between all instances of CapAttributeData .

Can you post the output from Gradle with and without --stacktrace ?

There is no build/libs folder in my folder Only taskLogs and tmp I'm not sure why the libs directory wouldn't be there. Can you post the output from gradlew build and either your build.gradle file and a screenshot of your project's directory structure or a link to a complete repository of your project?

Actually that means it couldnt find an Itemmodel.json and started looking for a blockstate because yes they can have those. I didn't know that, thanks. So items can have blockstates too? Yes. I have a description of the model loading process here, which explains this in more detail.

Running the build Gradle task should compile and reobfuscate your code, outputting the JAR to build/libs. Gradle will skip a task if it doesn't need to be run (i.e. it already has a current and valid copy of the output file(s)).

The speed reduction while using an item is handled in EntityPlayerSP#onLivingUpdate (line 934). You can probably counteract this by applying an AttributeModifier to the player's SharedMonsterAttributes.MOVEMENT_SPEED attribute from Item#onUsingTick . You'll also need to remove the modifier from this method if the player is mounted (because they won't be slowed in the first place) and also remove it from Item#onItemUseFinish . You may also want to handle FOVUpdateEvent to stop the FOV from increasing.

Lines 159-162 of StatList : for (ItemStack itemstack : FurnaceRecipes.instance().getSmeltingList().values()) { set.add(itemstack.getItem()); } Someone added a furnace recipe with a null output.

Lines 267-269 of SuperOresGeneration : if(Config.SapphireOre) { this.runGenerator(this.UraniumOre, world, random, chunkX, chunkZ, Config.SapphireRate, 0, 54); } this.UraniumOre is almost certainly the wrong field to use here.

ItemBlock s are rendered in exactly the same way as regular Item s, including the ability to use translucent textures. You can see an example of this here.

You can use the forge:multi-layer model to combine other models that are rendered in different layers. I explain this in more detail here.

is this file even needed? i'm updating old FarLands Mod https://github.com/Valiec/FarLands and i found this file in his repo and this file makes me unable to setup the workspace and i'm updating to 1.8.9 be cause then i'm going to update to 1.9 and then to 1.10.2 and i cant et the errors frm console bcause it closes No, it's not needed; it's included in Forge itself. I'm not sure why the original author decided to copy that and the Forge logo into their mod. If you're running the setupDecompWorkspace Gradle task from the command line, open a console window and then run the batch/shell script from that window instead of double-clicking on it.

You need to call ModelLoader.setCustomModelResourceLocation to set the model for each metadata value of the Item . Consider creating an enum to store the metadata value, unlocalised name and other properties of each sub-item. For examples, look at ItemFishFood / ItemFishFood.FishType and ItemDye / EnumDyeColor .

That appears to be Forge's AT, not yours. What are the errors? Why are you updating to 1.8.9 and not 1.10.2?

You can have two entries for a golden apple in the same loot pool with different "entryName" properties, yes.

Each entry in a loot pool must have a unique name. The default name of an entry is the name of the item or loot pool that it references. If you have multiple entries with the same default name, you need to set the "entryName" property of each entry to a unique name. The wiki has an explanation of the vanilla loot table format here. Forge adds the requirement that each loot pool must have a unique "name" property and each loot entry must have a unique name (either the default name or the "entryName" property). These requirements don't apply to vanilla's loot tables, only to mod loot tables.

There are some examples linked in this thread.

Instead of overriding Block#getItemDropped and calling super.getDrops , just create the List to return from getDrops yourself.

The BlockFlowerPot.CONTENTS property isn't stored in the metadata, it's set by BlockFlowerPot#getActualState from the values stored in TileEntityFlowerPot . After setting the block to Blocks.FLOWER_POT , you need to get the TileEntity from the World and call TileEntityFlowerPot#setFlowerPotData to set the contents. Side note: Metadata should be considered an implementation detail, you shouldn't be calling Block#getStateFromMeta yourself. Instead, call Block#getDefaultState to get the default IBlockState and call IBlockState#withProperty to get an IBlockState with the appropriate property values.

First you need to delay the removal of the TileEntity by overriding Block#removedByPlayer and Block#harvestBlock like BlockFlowerPot does in Forge's patch. Then you need to override Block#getDrops to create an ItemStack of the Item to drop and write the TileEntity 's NBT to the "BlockEntityTag" sub-compound of the ItemStack 's compound tag. Minecraft will automatically read your TileEntity from the "BlockEntityTag" sub-compound of the ItemStack used to place your block.

You can still store data in ItemStack NBT, but I'd recommend using a capability if your data is complex, you intend to store the same type of data for multiple different items or you intend for other mods to interact with/extend the data.