Choonster

In setCompostLevel, you're only setting READY to false when the existing LEVEL value is 0; you should set it to false when the new LEVEL value is 0 instead. Make sure you still set the new LEVEL value, even when it's 0. You're explicitly boxing, unboxing and casting the primitive values you pass to IBlockState#withProperty and receive from IBlockState#getValue; but there's no need to do this. Java will automatically box and unbox primitive values for you, there's no need to do it yourself. These methods are generic, so they will always use the IProperty's generic type argument as the parameter/return type without the need for casting.The only reason you see this in the vanilla code is because the compiler automatically generates it. Why are you calling World#setBlockState with flags to prevent the comparator output updating and then updating the comparator output manually? Just use the overload without the flags parameter. Why do you handle LEVEL >= 2 and LEVEL == 1 separately in onBlockActivated while doing exactly the same thing for both? You can use ItemHandlerHelper.giveItemToPlayer to insert an item into a player's inventory and drop the remainder on the ground; this saves having to call InventoryPlayer#addItemStackToInventory and EntityPlayer#dropItem.

That should work, I can't see any obvious errors. Could you post your whole Block class and the FML log (logs/fml-client-latest.log)?

There should be a very minimal performance hit if you're using a non-ticking TileEntity to store a value for a baked model. Using a ticking TileEntity or a TESR would be more expensive. Halving the integer property would allow you to store both values in the metadata.

Did you re-run the setup task (setupDecompWorkspace) like the comment tells you to? Did you refresh your IDE project (re-run the eclipse task or click the Refresh all Gradle Projects button in IDEA's Gradle window)? If you did and you got an error, post the Gradle log. You don't need to change any hashes.

I don't know exactly how to do this myself, but I suggest you look at FancyMissingModel to see how it renders text in a baked model.

To store multiple values in a single integer, you need to use bitwise operations. There are a lot of resources available that explain these, in addition to the vanilla code that uses them. I just realised that your integer property appears to have 11 values, which means that you can't store both it and the boolean property in the metadata. Metadata is limited to 4 bits (2^4 [16] potential values), but the highest value of the integer property (10) already occupies all 4 bits. You'll need to store one of the values in a TileEntity instead of the metadata. If you still need it to determine the block's model, you can keep the property and set it from the TileEntity's value in Block#getActualState instead of storing it in the metadata. You'll also need to override TileEntity#getUpdateTag and TileEntity#getUpdatePacket to sync this value to the client. Override TileEntity#onDataPacket to read the NBT data from the packet and call World#notifyBlockUpdate to redraw the chunk containing the block (so it draws the model for the new value). Call World#notifyBlockUpdate whenever this value changes to send the update packet to the client. You can see some examples of this here: Block classes: Coloured Rotatable , Coloured Multi-Rotatable TileEntity classes: Coloured Rotatable, Coloured Multi-Rotatable Blockstates files: Coloured Rotatable, Coloured Multi-Rotatable These blocks store their colour in the metadata and their facing(s) in the TileEntity.

Have you overridden Block#getStateFromMeta and Block#getMetaFromState to convert both properties to metadata and back?

1.0 is 100% drop chance, anything greater than that will be dropped even if the entity wasn't recently hit by a player and won't be damaged before it's dropped.

This is an intended feature, not a bug.

This issue has been reported here.

You need to handle any references to client-only classes through your proxy, with methods that return the client player, the client world, etc. In your client proxy, implement these to return the appropriate values. In your server proxy, implement these to throw an exception (because they should never be called on the logical or physical server).

Have you registered all of your messages with unique IDs? This can happen when two messages are registered with the same ID and FML uses the wrong message handler on the receiving side.

Forge's documentation has an introduction to block states here.

If you look for usages of the method, you'll see that PotionUtils.addPotionTooltip uses I18n.translateToLocal to localise it for potion tooltips.

This exception is caused by a client-to-server message (which Forge limits to a single CPacketCustomPayload, i.e. 32,767 bytes), not a server-to-client message.(which Forge splits into a a maximum of 255 SPacketCustomPayloads, i.e. 267,366,480 bytes). Do you need to send all of that data to the server at once? Can you send individual parts that have changed, possibly through the Container? You shouldn't be storing mutable game data in a field of your @Mod class (Caterpillar#mainContainers), since it's shared between logical sides in single player. You should be using World Capabilities or World Saved Data (if storing the data directly in the TileEntity isn't an option). Iterating through a server's World's to find a block at a specific position is very unreliable, what happens when two dimensions have a drill at the same position?

You don't need the old player's thirst data after you've copied it to the new player in PlayeEvent.Clone, just use the new player's thirst data when sending the packet.

You shouldn't be catching IndexOutOfBoundsException, it should be allowed to propagate up to FML's exception handling and/or crash the game. It's only thrown when you've done something wrong that should be fixed. Is the IMessageHandler scheduling a task on the main thread to perform its action? Is it being called at all?

You're trying to send data to the server from the server, which makes no sense.

Use the Simple Network Implementation to send data between the client and server.

That code reaches across logical sides by accessing the server through the Minecraft class, which is client-only. It will also crash the dedicated server. Since FakePlayer extends EntityPlayerMP and requires a WorldServer, it should only be used from the logical server.

I'd suggest having a method on your TileEntity called something like insertHeldItem that takes an EntityPlayer and an EnumHand and attempts to insert the player's held item into the TileEntity's inventory. Use IItemHandler#insertItem to insert into a specific slot or ItemHandlerHelper.insertItemStacked to try and insert into the first slot possible, filling up existing stacks first. These both return the remaining ItemStack that couldn't be inserted (null in 1.10.2 or ItemStack.EMPTY in 1.11.2 if the full stack was accepted), so use EntityLivingBase#setHeldItem to replace the player's held item with this.

Line 429 of RenderItem is the following: if (stack.getItem().showDurabilityBar(stack)) The only value that can be null on that line is the return of ItemStack#getItem, which means an ItemStack with a null Item is being rendered. The method is being called from GuiContainerCreative#drawTab, which draws the tab's icon ItemStack into the GUI. This means that the ItemStack with the null Item is the one you're returning from CreativeTabs#getIconItemStack. Creative tabs need to be initialised before items, so you can't pass an Item to a CreativeTabs constructor. Instead, override CreativeTabs#getTabIconItem or CreativeTabs#getIconItemStack (there's no need to override both) to get the Item from the the field it's being stored in (e.g. in your ModItems class).

Your file probably wasn't encoded in or compiled as UTF-8.

Call TextFormatting#toString to get the formatting code of a TextFormatting value. If you're registering your event handler with EventBus#register, do it from the client proxy (or a client-only class called from it). If your mod is marked as client-only, you can reference client-only classes from anywhere and don't really need a proxy. If you're registering your event handler with the @Mod.EventBusSubscriber annotation, pass Side.CLIENT to it as an argument so it's only registered on the physical client. EntityJoinWorldEvent is fired when an entity is added the world. It should work in any event. Side note: Everything from the start of the quote in your second bullet point to the end of your post is formatted with a white background and black text, which looks quite ugly in the dark theme. I suggest you remove formatting when copying and pasting text into posts (or use Ctrl-Shift-V to paste without formatting).

That should work, but I'd recommend using TextFormatting instead of hardcoding the formatting code in the prefix string. I'd also recommend only setting the prefix when you create the team. Make sure you only add entities to the scoreboard on the client side (register the event handler from your client proxy or pass Side.CLIENT to @Mod.EventBusSubscriber [so it only runs on the physical client] and check that World#isRemote is true [so it only runs on the logical client]). What are you trying to do?