Choonster

Your PlayerDataMessage#fromBytes method is trying to read more data from the byte buffer than was written to it by PlayerDataMessage#toBytes . You must read exactly the same number of bytes from the buffer that you write to the buffer. If you post the PlayerDataMessage class, I may be able to tell you in more detail what you've done wrong.

Each external object you attach the capability to (whether it's an Entity , TileEntity , ItemStack or World ) must have its own provider instance. Each provider instance must store its own instance of the capability ( IUUIDCapability ). Your capability will be read from NBT (i.e. INBTSerializable#deserializeNBT will be called on your ICapabilityProvider ) at some point after AttachCapabilitiesEvent is fired. Like I said before, consider lazy-loading the expensive operation instead of running it in the parameterless constructor. If it helps, you can look at the capabilities provided by Forge (look for usages of CapabilityManager#register ), the capability test mod or my own mod's capabilities (API, implementation). Edit: Fixed the implementation link.

Normally the ICapabilityProvider (or ICapabilitySerializable ) you attach to an external object stores at least one instance of your handler ( IUUIDCapability ) and returns that from ICapabilityProvider#getCapability . If the hashing operation is expensive, consider lazy-loading it; i.e. only run it when something requests the data and the data doesn't already exist.

You need to create an implementation of ICapabilitySerializable (which is just the two interfaces ICapabilityProvider and INBTSerializable ) that provides an instance of your handler (in the ICapabilityProvider methods) and reads it from/writes it to NBT (in the INBTSerializable methods). You then need to subscribe to AttachCapabilityEvent<Entity> ( AttachCapabilityEvent.Entity in Forge 2090 or earlier), check if the event's entity is a player and call AttachCapabilitiesEvent#addCapability with an instance of your ICapabilitySerializable implementation. When you want to access a player's handler instance, use the ICapabilityProvider methods implemented by EntityPlayer . I did notice some minor issues in your code: You should follow Java, MCP and Forge naming conventions: lowercase for package names, camelCase for field, method, parameter and local variable names; PascalCase for type names; CONSTANT_CASE for constant names; IWhatever for interface names. PlayerDataCapability isn't a very descriptive name, consider naming it something like IPlayerStats . The PlayerDataCapability.Strength field is pointless, there's no reason for it to exist. PlayerDataCapabilityFactory isn't a factory, so don't call it that. If you name your interface IPlayerStats , you can name the default implementation PlayerStats .

I linked several examples here.

Call it whenever you want to access your handler instance (i.e. the instance of PlayerDataCapability ). This handler instance stores the data, you need to create methods in your interface to interact with the data (read/write it). The ICapabilitySerializable is responsible for reading the handler from and writing the handler to NBT.

Call ICapabilityProvider#getCapability to get the instance of your handler attached to the provider. Every Entity (including EntityPlayer ) is an ICapabilityProvider .

I'm not entirely sure why it's not working, but I did notice some errors: The IDestruction#destructionPoints field doesn't need to exist. The DefaultImpl.points field shouldn't be static. Your IStorage expects to work with NBTTagCompound s, but your ICapabilitySerializable uses NBTPrimitive .

Don't subscribe to PlayerInteractEvent itself, subscribe to the appropriate sub-event; e.g. PlayerInteractEvent.RightClickBlock . The sub-events of PlayerInteractEvent are fired once per hand per side, which is why you see the event being fired four times when the player right clicks.

Use CraftingManager.getInstance to get the CraftingManager instance and CraftingManager#getRecipeList to get the crafting recipe list. You can then call List#clear to clear this completely. Use FurnaceRecipes#instance to get the FurnaceRecipes instance and FurnaceRecipes#getSmeltingList to get the smelting list. You can then call Map#clear to clear this completely. You may also want to clear the FurnaceRecipes#experienceList field, but this isn't publicly accessible so you'll need to access it via reflection.

No, you need to create an instance of PlayerDataCapabilityClass.PlayerDataCapabilityFactory and pass that as the third argument.

Register it in preInit from your @Mod class or a class called from it. There are two overloads of CapabilityManager#registerCapability that take a different third argument: One takes the Class of the capability interface's default implementation One takes an instance of Callable that returns an instance of the default implementation You're trying to pass the Class of the Callable implementation, which is incorrect. You haven't actually added any methods to your capability interface or implemented any of the methods in your IStorage and Callable implementations.

You should use the existing ItemArmor#armorType field to get the EntityEquipmentSlot of an ItemArmor instance rather than creating your own field. The ItemArmor.ARMOR_MODIFIERS array contains the UUID s used for the SharedMonsterAttributes.ARMOR and SharedMonsterAttributes.ARMOR_TOUGHNESS modifiers provided by each piece of armour (see ItemArmor#getItemAttributeModifiers ). It uses the return of EntityEquipmentSlot#getIndex as the index. You should create your own UUID for your modifier. Call UUID.randomUUID once at startup to generate a random UUID, then write it to the log. Create a private static final field of type UUID in your armour class and initialise it by calling UUID.fromString with the UUID that was printed to the log. Use this field as the ID of your modifier. Side note: You don't need to cast from int to double , Java will automatically convert numeric types to "wider" types. You only see these casts in vanilla code because the compiler automatically generates them.

There's a collection of 1.10.2 tutorials linked here. One of these may be what you want.

If you have a server-side World , use World#getMinecraftServer . If you don't have a World , use FMLCommonHandler#getMinecraftServerInstance .

Override Item#getAttributeModifiers to do the following: Call the super method. Check that the EntityEquipmentSlot argument is EntityEquipmentSlot.MAINHAND . If it is, replace the modifiers with the IDs Item.ATTACK_DAMAGE_MODIFIER and Item.ATTACK_SPEED_MODIFIER (use the existing fields rather than calling UUID.fromString ) in the Multimap with your own modifiers. Return the Multimap . I have an example of this here.

The tint index is part of the model and can't be specified in the blockstates file (even with Forge's format). You need to copy the block/cross model, add a tint index to each face and then use this model instead of the vanilla one in your blockstates file.

I think Lex meant the EAQ, which is linked at the top of the site, the top of this section and in the sticky at the top of this section.

Then start learning. Read the documentation, read the vanilla/Forge code, look for open source mods that add custom village components and read their code. There may even be some tutorials on structure generation out there.

You'll probably need to register a VillagerRegistry.IVillageCreationHandler to generate your own field village component.

Use BiomeManager.addVillageBiome .

Either spawn an entity inside the block when it's placed or suggest that Forge add a BlockStruckByLightningEvent .

Returning a value greater than 15 from Block#getMetaFromState will either break things or be truncated to 15.

Metadata is limited to 4 bits (16 possible values), you can't have 5 colours and 8 ages in a single Block . The age takes up 3 bits, leaving only 1 spare bit. You'll need to create a Block for each colour and only store the age in the metadata. You can register an IBlockColor to colour a block model at runtime, but each model element to be coloured must specify a tint index (see the wiki). If you also want the item model to be coloured, you'll need to register an IItemColor . Register your IBlockColor / IItemColor implementations with the BlockColors / ItemColors instances in init, you can get these from Minecraft . I have some examples of this here.

There's a collection of 1.10.2 tutorials linked here.