Choonster

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.

The capability itself should sync its data whenever it changes, including when it's loaded from NBT.

Single player is just a server with one player online. The client and server will each have their own EntityPlayer instance, each of which will have its own instance of your capability. Capabilities are only written to NBT when they're being saved to the disk. They're not automatically synced, you need to sync them yourself. Only the server will save and load capability data from the disk, the client will always have the default data for your capability unless it's synced from the server. If an event is fired on both sides (not all events are) you should be able to make changes to the capability data on both sides; but this won't be reliable if the client never had the correct data in the first place. As an example, let's say that your capability stores a single number and a player has the number 2 stored. When an event is fired that adds 5 to this number, the server's new value will be 7 (2 + 5) but the client's new value will be 5 (0 + 5).

You haven't really shown how you're storing or retrieving your data, but it sounds like you're not syncing it to the client. Commands are run on the server side (unless you register them with ClientCommandHandler ), so a command would show the server's copy of the data rather than the client's.

You register your capability with CapabilityManager.register in preInit. You attach providers for your capability to external objects ( Entities , TileEntities , ItemStack s, etc.) when AttachCapabilitiesEvent<T> is fired. For examples of capabilities, you can look at the capability test mod or my own mod's capabilities (API, implementation). The IMaxHealth capability in my mod will probably be of particular interest, this is attached to entities to store and manage an AttributeModifier to provide bonus max health.