Choonster

--mods "modsDir1/mod1.jar,modsDir1/mod2.jar,modsDir2/mod3.jar"

It looks like you have both a 1.8.9 and a 1.7.10 version of Warp Book installed. Remove the 1.8.9 version.

Like I said, it's a comma-separated list of mod files to load. There's not much more to it than that.

Yes, that would be a much better way to handle compounds. You could even have elements as a single Item with the atomic number as the metadata. You could probably even use Capabilities instead of NBT.

ForgeGradle for 1.8.8+ requires at least 2 GB of memory to decompile Minecraft. I believe this is due to Mojang's obfuscation process leaving generics intact instead of stripping them. This tutorial explains how to give ForgeGradle more memory. Side note: Why are you using 1.8.8? It's been superseded by 1.8.9.

You can use the --mods command line argument (a comma-separated list of mod files) or just create a separate game directory for each profile. I think the mod list file was mainly intended for modpack launchers (e.g. ATLauncher) to store their mods in a central location shared between all instances/profiles and still only load the mods for the launched pack.

{ "repositoryRoot": "jsonmods", "modRef": [ "dan200:ComputerCraft:1.78", "org.squiddev:CCTweaks:1.8.9-0.3.2" ] } This will load two mods: <gameDir>/jsonmods/dan200/ComputerCraft/1.78/ComputerCraft-1.78.jar and <gameDir>/jsonmods/org/squiddev/CCTweaks/1.8.9-0.3.2/CCTweaks-1.8.9-0.3.2.jar (where <gameDir> is the game directory specified in the client's launcher profile or the server's directory).

That sounds like what I'm doing. Every element is being registered in the language file, and then when combining the names I loop over each element in the compound, use the StatCollector line on each element, and append it to the string, which is returned and set as the compound's unlocalized name. If I don't include that extra .name then the element name is not found to be translated and I get a horrible mess of a combination of unlocalized names making one big unlocalized name. Code's here: https://github.com/Roboguy99/Chemistry/tree/master/src/main/java/roboguy99/chemistry/item The translation keys in your lang file end in .name , so you need to include that when using StatCollector.translateToLocal . If they didn't end in .name , you wouldn't need to include it. Item#getUnlocalizedName returns the unlocalised name without the .name suffix so items with subtypes (e.g. dyes) can combine the base unlocalised name with the unlocalised name of the subtype before the .name suffix is added. You can't compare strings with == or != , since two different string objects may have the same value. Use Object#equals instead. I would suggest using StringBuilder rather than concatenation to build strings. The way you're currently building your localised names should mostly work, but you should override Item#getItemStackDisplayName to return this name instead of setting it as the unlocalised name. Your current implementation of getCommonName will only work for English. I would recommend having common names in your lang files, having a field or method for the unlocalised common name and translating it in getCompoundName . You should also check if the common name exists before building the full compound name to avoid unnecessary processing. I would recommend against using the empty string as a default return value, I'd suggest using null to indicate no value instead. What you have now won't re-translate the names when the user changes the game's locale. On the client side, you need to register an instance of registerReloadListener that rebuilds the localised name of every Compound when the client's resources are reloaded (e.g. when they change the locale). Use Minecraft#getResourceManager to get the resource manager, then cast it to IReloadableResourceManager and call registerReloadListener with your registerReloadListener instance.

Add the individual name parts to your language files, translate each part individually and then combine them into the full name. The argument of StatCollector.translateToLocal is the full translation key to translate, it doesn't have to end in .name .

Currently, you don't. This Pull Request will add a way for mods to use vanilla's new loot system, but it's still a preliminary draft.

The Modder Support section is for seeking help with mod development. The Support section is for seeking help with mod use. Your thread should be moved there soon. The ATLauncher has a button for each pack in the Packs menu to create a server of that pack. Create a server using this button and then either copy the new server's files into your existing server or copy your save to the new server.

You haven't followed diesieben07's instructions: Your class doesn't extend EntityZombie You can't call methods directly in the body of a class You've typed the name of the method you need to call, but you're not actually calling it Do you actually know Java? You can't make a mod until you have a solid understanding of Java. In future, please use Gist or Pastebin to post logs/crash reports (if applicable) and code with syntax highlighting. To get syntax highlighting on Gist, give each file the appropriate extension (.java for Java code). To get syntax highlighting on Pastebin, select the language from the dropdown at the bottom of the page. It's much easier to read code with proper formatting and syntax highlighting.

The root object of the list file can contain three properties: repositoryRoot (string) - The root directory. All mod paths are relative to this. modRef (array of strings) - An array of mod references to load. parentList (optional string) - The path of the parent list, if any. If specified, FML will load this list as well as the current one. This can be chained (e.g. list A inherits from list B, which inherits from list C), but not looped (e.g. list A inherits from list B, which inherits from list A). Each mod reference is a string in the following format: "<group>:<name>:<version>[:<classifier>]" The path of the mod JAR is built from these components in the following format: <repositoryRoot>/<group>/<name>/<version>/<name>-<version>[-<classifier>].jar The square brackets denote an optional part; if no classifier is specified, it won't be used in the path. Any period ( . ) in the group will be replaced with a directory separator.

Better Sprinting needs to updated to work with Forge 1.9-12.16.0.1805-1.9 and newer.

If you're interested in the technical details: The GuiOpenEvent#gui field was previously public, but it was changed to a private field with a public getter method in Forge 1.9-12.16.0.1805-1.9. Since the field is private, it can no longer be accessed directly; the getter method must be used instead.

Use RenderingRegistry#registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit to register your renderer. To implement IRenderFactory , I suggest using an anonymous class (if you're targeting Java 6/7) or a constructor method reference (if you're targeting Java [nobbc][/nobbc]. The deprecated RenderingRegistry#registerEntityRenderingHandler(Class<? extends Entity>, Render<? extends Entity>) overload will probably be removed in a future version of Forge, likely one for 1.9 or 1.9.1.

Thanks for this great adivce but I want to use it in multiplayer and server-side only... Forge mods can be client-only or server-only. If your mod only needs to be installed on one side, set the acceptableRemoteVersions property of your @Mod annotation to "*" (i.e. accept any version, including none). In 1.8+, you can also set either the clientSideOnly or serverSideOnly property to true (but not both) to prevent the mod from loading on the wrong side.

Xaero's Minimap needs to be updated to work with Forge 1.9-12.16.0.1805-1.9 and newer.

ForgeGradle for 1.8.8+ requires at least 2 GB of memory to decompile Minecraft. I believe this is due to Mojang's obfuscation process leaving generics intact instead of stripping them. This tutorial explains how to give ForgeGradle more memory.

Upload your @Mod class, your item registration class and your recipe registration class to Gist or Pastebin with syntax highlighting and link them here. To get syntax highlighting on Gist, give each file the appropriate extension (.java for Java code). To get syntax highlighting on Pastebin, select the language from the dropdown at the bottom of the page.

The issue is with Minecraft itself, not MCP. MCP is only used by Forge for deobfuscation data, i.e. mapping names like aa to World . The code itself is decompiled from the Minecraft JAR, deobfuscated with the MCP data and patched by Forge. ItemAxe will only work for mods when someone submits a PR to Forge with a patch that fixes it (and the PR is accepted) or Mojang changes it in a future version of Minecraft.

Use ISmartItemModel to generate models on demand. I can't help you with it much myself, but it's been discussed before on this site and others. You can also look at Forge's implementation of it in ModelDynBucket .

I'm first registering the recipe in both client and server side and then items/blocks. Don't do that. Items/blocks should be registered in the preInit phase. Recipes should be registered in the init phase.

Create a model that inherits from builtin/generated and set the layerN textures (where N is an integer >= 0). Look at assets/minecraft/models/item/spawn_egg.json to see how vanilla uses two layers for the spawn egg model.

You tried to use a biome ID of 3663, but BiomeGenBase.biomeList (an array of biomes with their ID as the index) is only 256 long. This means the maximum biome ID is 255.