Choonster

You should very rarely need to import or use any AWT classes with the possible exception of Color , which can be used to get the RGB integer of a colour. You can't use LWJGL or read player input in common code, these can only be done on the client. Why are you using Scala's Console class? You shouldn't need this enum. PlayerInteractEvent#getHand returns an EnumHand . Checking if an EnumHand is equal to an Action makes no sense and will never be true . PlayerInteractEvent.RightClickBlock is fired when a player right clicks a block. PlayerInteractEvent.RightClickItem is fired when a player right clicks air while holding an item.

Each tag in the "pages" list must be the JSON representation of an ITextComponent . For a TextComponentString , you can simply wrap the contents in quotation marks (e.g. new NBTTagString("\"Page one text\"") ). If you want anything more complex than plain text, I suggest you create the ITextComponent for each page and then use ITextComponent.Serializer#componentToJson to serialise them.

There is no cloud block in vanilla. BlockBush and BlockTorch both allow the player to pass through the block.

Don't subscribe to PlayerInteractEvent directly, use the appropriate sub-event ( PlayerInteractEvent.RightClickItem in this case). EntityLivingBase#getActiveItemStack only returns a non- null value if the entity is actively using an item like a bow or shield. Use PlayerInteractEvent#getItemStack to get the ItemStack that the event was fired for. Use EntityLivingBase#getHeldItemMainhand , EntityLivingBase#getHeldItemOffhand or EntityLivingBase#getHeldItem to get an entity's held item when it hasn't been provided for you. Events should generally only be used for external objects (i.e. items, blocks, etc. created by vanilla or other mods); you should prefer to override the appropriate callback method when possible ( Item#onItemRightClick ). That will only ever return the item in the player's main hand, but the event may have been fired for the off hand.

You've overridden the wrong overload of Block#hasTileEntity . You need to override the one with the IBlockState argument, not the deprecated one with no arguments (and a comment telling you to use the state sensitive version).

I'm glad you got it mostly working in the end. I'd say it's unlikely that a PR to add an inventory reference to ItemStack will be accepted, since that would be a massive change to a lot of vanilla and mod code.

You need to call World#notifyBlockUpdate if you want to send the update packet to nearby clients.

Not every AttributeModifier adds a flat amount to the attribute's value, so you can't just sum the value of each modifier to get the total attack damage. Operations 1 and 2 multiply the value by some amount rather than adding a flat value. To calculate the actual attack damage provided by an item, use the attribute system: Create an AttributeMap Call AttributeMap#registerAttribute with SharedMonsterAttributes.ATTACK_DAMAGE Store the resulting IAttributeInstance and set its base value to 1.0 (the same base value used by players) When you want to calculate the attack damage: Remove all existing modifiers from the attribute instance (IAttributeInstance#removeModifier ) Apply the current item's modifiers (IAttributeInstance#applyModifier ) Get the value (IAttributeInstance#getAttributeValue ) Since modifiers can be multiplicative, you may want to include the modifiers provided by the player's other items. A sword that adds 8 attack damage will be better than a sword that adds 50% attack damage if the player's other items add less than 16 attack damage or worse if the player's other items add more than 16 attack damage. I have an example of a similar use of the attribute system here. I copy modifiers from an entity's SharedMonsterAttributes.MAX_HEALTH IAttributeInstance to my own IAttributeInstance and adjust the value of a modifier to ensure the entity's max health is at least 2.0.

The else block that adds the "Unidentified..." tooltip is part of the cap != null if statement instead of the !cap.needsUpdate if statement, so it's only running when cap == null .

Set the acceptedMinecraftVersions property of your @Mod annotation to "*" , i.e. accept any remote version including none. Set the serverSideOnly property to true if you only want the mod to load on the dedicated server and not the integrated server.

Your onDataPacket method is creating an SPacketUpdateTileEntity from the client-side values by calling getUpdatePacket (twice) and then reading those values back into the client-side TileEntity . The values sent from the server are completely ignored. Instead of calling getUpdatePacket , use the SPacketUpdateTileEntity argument that contains the values sent from the server.

Metadata is limited to 16 values, so a property with 6 values limits you to one other property with 2 values (2 * 6 = 12, 3 * 6 = 18). If you require additional values, you need to store them in a TileEntity . If you want to use them to determine the model, override Block#getActualState to set the property from the value stored in the TileEntity . You can see an example of this here: Block , TileEntity .

ItemStack is the class that implements ICapabilityProvider , so this is where you retrieve your capability instance from. I can't see any obvious errors in your code. I attach this provider for this capability to Items.CLAY_BALL here.

Thanks, that's useful to know. When did they change that? (added the ability to use previous version #, I mean)? Still using ye olde IRC interface I see -TGG I have no idea when they changed it, I only found it earlier this year. It may have been in 2014 with the launch of MCPBot_Reborn.

AttachCapabilitiesEvent is the only way to attach a capability to an external object, so you'll need to attach the capability to all potential Item s and then check if an ItemStack is allowed to have stats before you do anything stat-related with it. There shouldn't be much impact of adding a capability to all Item s, as long as your ICapabilityProvider doesn't do anything expensive in hasCapability / getCapability it should just be one more iteration of the loops in CapabilityDispatcher 's implementations of these methods. ItemTooltipEvent gives you the ItemStack , so you can search the player's inventory to find the slot containing the same ItemStack (i.e. use == instead of checking for equivalency).

AttachCapabilitiesEvent.Item is fired from ItemStack#setItem , which is called from the ItemStack constructor. In general, AttachCapabilitiesEvent will be fired before you have access to any dynamic data. AttachCapabilitiesEvent.Item gives you the ItemStack and Item , AttachCapabilitiesEvent<TileEntity> and AttachCapabilitiesEvent<Entity> give you the TileEntity / Entity before it's been constructed and read from NBT, AttachCapabilitiesEvent<World> gives you the World when it's mostly initialised. You'll need to generate the random stats for the item when it's crafted or dropped by a mob, not in AttachCapabilitiesEvent .

MCPBot can tell you the name history of a field/method.

The cpw.mods.fml package has moved to net.minecraftforge.fml . MCPBot can tell you the name history of a field or method. I don't really want to download the entire mod to fix the errors for you, you'll probably get more help if you tell us exactly what issues you're having.

A request/response system may work, I haven't really tried something like that myself.

You need to override TileEntity#getUpdateTag and TileEntity#getUpdatePacket , which williewillus explains here. You don't need a custom packet for this, but you can learn more about custom packets and networking here.

Syncing of item capabilities is tricky. Capability-only changes to an ItemStack in a server-side Container will cause an SPacketSetSlot to be sent for the slot, but this doesn't include the capability data so the client-side copy of the capability data will be reset to the default. There are two open PRs with different fixes for this: #3099 and #3283. If either of these are merged, it should simplify the situation a bit. One way to handle the syncing currently is to register an IContainerListener , as described in this thread. The sub-events of AttachCapabilitiesEvent were deprecated in this commit with the addition of generic filtering of events. Instead of AttachCapabilitiesEvent.Entity , use AttachCapabilitiesEvent<Entity> .

Don't create an Item for your double slab, BlockSlab#onBlockPlaced is only designed to handle single slabs.

Yes, the return value of IMessageHandler#onMessage isn't that useful these days, since you need to do the actual processing asynchronously on the main thread. Just send the response message manually with your SimpleNetworkWrapper instance.

Packet handlers are run on a separate thread, you must schedule a task to run on the main thread before you can safely interact with normal Minecraft classes. Forge's documentation explains this here. Apart from that, your code looks like it should work. Could you post the ICapabilityProvider you attach to players to provide your capability?

The getter method didn't exist in 1.8.9, it was only in 1.9 that all event fields were encapsulated with getter methods. BlockEvent has a pos field of type BlockPos .