Choonster

You installed a 1.7.10 coremod on 1.8.9, this won't work. If you don't know which mod this is, post the FML log (logs/fml-client-latest.log).

Unlocalised names are still required for display purposes (as they always have been) but shouldn't be used for anything else. They should be unique to your mod to avoid localisation conflicts with other mods. Including your mod ID in the unlocalised name (e.g. by using the registry name) is a good way to do this. This doesn't guarantee the uniqueness, but it makes it very likely to be unique unless another mod deliberately uses the same name. All translations for the active locale are stored in a single map, regardless of which mod's lang file they were loaded from. They're not stored separately for each mod. Usually the unlocalised name of an item will be the same as its registry name, but this isn't required. Some items like records have the same unlocalised name as each other but still have their own unique registry names.

The tag returned by Entity#getEntityData isn't automatically synced to the client, you need to do this yourself. That said, you shouldn't be using Entity#getEntityData anyway. Use the Capability system to store data on players (among other things). For examples, 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).

ForgeGradle downloads the same assets as the regular client does. You can find these in ~/.gradle/caches/minecraft/assets (replace ~ with %USERPROFILE% on Windows). The index file can be found at assets/indexes/<version>.json, the assets themselves can be found in assets/objects. The index file tells you the hash of each file, this hash is used as the file name.

I have an example in my mod: API, implementation This is a bit complex because the IMaxHealth object stores the entity's bonus max health and manages an AttributeModifier that actually applies the bonus max health to the entity.

Do you mean the Minecart?

I don't know of any tutorials, but you should read the official documentation page I linked in my first post. For examples, 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).

Yes. You create the types that store your capability data at runtime, you write the code to read this from and write this to NBT.

The data is stored as proper objects at runtime and saved to NBT on disk. It persists across game sessions.

Use the Capability system to store data on players (among other things).

You should be downloading and using Forge, not FML. FML is included in Forge. Installer installs a Forge client or server. Insaller-win is a Windows executable wrapper of the Installer JAR. These are the downloads you want. Src is the old name for the MDK, Mod Development Kit. It's only for developing mods. Universal is just the Forge JAR itself. This doesn't include any of the libraries required by Minecraft/Forge. Note that 1.7.10 is no longer supported here, so you won't get any help with it.

1.9 added the item/generated model, which extends builtin/generated and defines the standard display transformations. Most vanilla item models extend this, yours should too. Only define display transformations in your models if they're different to the standard ones. In addition to item/generated , there's now the block/block model that defines the standard display transformations for blocks. Most vanilla block models (including "abstract" models like block/cube_all ) extend this. 1.9 also split the firstperson and thirdperson display transformations into separate left- and right-hand versions. The first- and third-person display transformations only apply when an entity is holding the item. Item entities use the ground display transformation.

It's okay for the registry and unlocalised names to be the same, as long as the registry name isn't derived from the unlocalised name. I recommend setting the registry name, then setting the unlocalised name to the registry name (like this). Registry names are unique, constant IDs; unlocalised names aren't unique and can change at any time.

Do any of the existing capabilities ( IItemHandler , IFluidHandler , IAnimationStateMachine ) match the data you want to store? If they do, use them. If they don't, create your own.

You'll probably want to subscribe to PlayerEvent.BreakSpeed to slow down the breaking and BlockEvent.HarvestDropsEvent to remove the drops. I do something similar here, but this prevents the block from being broken at all unless the player has the correct tool.

Minecraft won't actually call this on your commands, but all vanilla commands return a translation key from this method. This is because a CommandException or WrongUsageException thrown by ICommand#execute will be sent as a TextComponentTranslation to the command sender, so vanilla commands throw a WrongUsageException with the return of ICommand#getCommandUsage as the message.

The lang file parser ( FMLCommonHandler#loadLanguage ) ignores any line starting with a hash ( # ), you can use this for comments.

Register your LootFunction 's Serializer with LootFunctionManager.registerFunction .

Yes, I'd recommend creating a method in bookScale to apply the NBT for the specified book to a provided ItemStack and then using this in both bookScale#getSubItems and the LootFunction . Now that I think about it more, you shouldn't be storing pre-written text directly in NBT anyway. Any text you display to the user should be translated to the client's locale, which won't work if you store the English text in the NBT. The best way to do this is the following: Store the number of pages in each book somewhere Store the book ID in the ItemStack using metadata or NBT Don't extend ItemWrittenBook Create a client-only (@SideOnly(Side.CLIENT) ) method (we'll call it getBookStack , but the name doesn't really matter) that takes the book ID or ItemStack and returns an ItemStack of Items.WRITTEN_BOOK with the translated text for that book in the NBT. To gather the translated text for a book, iterate from 0 (inclusive) to numPages (exclusive) and call I18n.format with a translation key containing the book name and the page number (e.g. book.<yourmod>:bookScale.east.page.0 , book.<yourmod>:bookScale.west.page.5 , etc.). Provide translations for these keys in your mod's lang files. [*]Use the IGuiHandler system to open the vanilla book GUI when the item is right clicked (only on the client): Pass the book's ID as the x argument of EntityPlayer#openGUI (since you don't need actual coordinates for item-based GUIs) Return null from IGuiHandler#getServerGuiElement (since your GUI doesn't have a server component) Return an instance of GuiScreenBook from IGuiHandler#getClientGuiElement . Pass it an ItemStack of Items.WRITTEN_BOOK returned from getBookStack .

Create a LootFunction that takes some sort of book ID (probably a ResourceLocation ) as an argument in the loot table and fills the ItemStack with the NBT for that book.

Your LootFunction will receive the ItemStack it's supposed to modify as an argument in the LootFunction#apply . There's not much point in specifying a whole ItemStack as an argument in the loot table itself, you may as well just use set_nbt .

You set ModWorldGen.nethergold to an instance of ModWorldGenMinable instead of ModNetherGenMinable . Why have you copy-pasted WorldGenMinable instead of extending it?

World#isRemote is true on the client and false on the server. The server is in control of the game state, but you're making your changes on the client so they get overwritten the next time it syncs. Side note: Consider using bitwise operations when storing multiple values in metadata instead of using harcoded metadata values for each combination.

Correct, the two-argument overload of World#setBlockState (which uses 3 [1 + 2] as the flags) should work. Oddly enough, ItemBed uses 11 (1 + 2 + as the flags even though it only sets the block on the server and only the client-side implementation of IWorldEventListener#notifyBlockUpdate (indirectly called by World#setBlockState ) actually checks for flag 8. Edit: I always forget to disable smileys when posting something with "" in it.

Post your Block class.