Choonster

You can also override the recipes with dummy recipes that do nothing, as I do here. The DummyRecipe class is here. This prevents the advancement errors, but instead spams the log with "Dangerous alternative prefix" warnings because you need to set the registry names of the dummy recipes to the registry names of the vanilla recipes they override. As LexManos said here, there's currently no way to avoid this.

You register an instance of your class with the Forge event bus, so it looks for non-static event handler methods to subscribe. Your event handler method is static, so it's never subscribed. Either make the event handler method non-static or register the Class object instead of an instance (manually or with @Mod.EventBusSubscriber). Forge's documentation explains events in more detail here.

latest.log isn't the FML log. MorePlayerModels is broken. Make sure you're using the latest version for the Minecraft version you're using. 1.9 is very outdated, I recommended updating to 1.12.2. If you must use 1.9.x, at least use 1.9.4.

The client uses an IResourceManager instance (Minecraft#mcResourceManager) to load resources from its list of IResourcePacks (this list is compiled in Minecraft#refreshResources). The server uses various mechanisms: AdvancementManager and CraftingManager use Class#getResource to find the vanilla advancements and recipes directories respectively and then uses Java 7's NIO.2 system to iterate and load them. Forge's CraftingHelper.findFiles method (used to load mod advancements and recipes) also uses NIO.2 to iterate through the directories and load the files. LootTableManager.Loader uses Guava's Files#toString to load loot tables from files on disk and Resources#toString to load loot tables from files in JARs. TemplateManager uses FileInputStream to load structure templates from files on disk and Class#getResourceAsStream to load structure templates from files in JARs. These might be unified with the addition of data packs in 1.13.

You're using Containers with a different number of Slots on the client and server. The client uses ContainerRepair; but the server uses GuiServer, which extends ContainerRepair and adds an extra Slot. The client-side Container doesn't have a Slot at this index, so the update packets throw an IndexOutOfBoundsException. You need to use Containers with the same number of slots on both sides, usually instances of the same class. GuiRepair doesn't have a constructor that lets you provide your own Container, so you'll probably need to copy rather than extend it. If you extend a class, you don't need to copy all of its fields and methods; you only need to override the methods that should have different behaviour. To access the private IInventory fields in ContainerRepair, either use reflection or get the corresponding Slots from Container#inventorySlots and get the inventory from the Slot#inventory field. GuiServer isn't a good name, since it's not a GUI and the server doesn't have GUIs. I recommend following the MCP naming conventions and naming it something like ContainerGoldenAnvil.

You can open the game directory by selecting your profile in the "Launch options" tab of the launcher and then clicking the "Go to folder" button next to the "Game directory" option. Inside the game directory is the logs directory, inside that is the fml-client-latest.log file (the FML log). Upload this to Gist and link it here.

The FML log is located at logs/fml-client-latest.log in the game directory. Upload it to Gist and link it here.

Removing blocks from the registry isn't possible. It is possible to override registry entries with your own, but that should be avoided where possible because it can cause compatibility issues if multiple mods try to override the same entry. Instead, you should subscribe to HarvestDropsEvent and add items to/remove items from the drops list as needed.

Where is the exception being thrown? Is it being thrown on the line that calls TileEntity#hasCapability or is it being thrown inside TileEntity#hasCapability? Post the stacktrace.

Can you post your entity and entity renderer registration code?

Thanks, I'll just look up the Potion from the registry manually.

As I understand it, the currently recommended practice is to both instantiate and register all IForgeRegistryEntry implementations during the appropriate registry event and use @ObjectHolder to inject them into fields. When attempting to refactor my code to this pattern, I ran into an issue: I need to create PotionTypes for all of my mod's Potions during RegistryEvent.Register<PotionType>, but the @ObjectHolder fields storing my Potions are still null at this point because object holders aren't applied between RegistryEvent.Register<Potion> and RegistryEvent.Register<PotionType>. What should I do here? Should I just look up the Potions from the registry manually? Should I apply object holders? Should Forge apply object holders after each registry event?

Salamander offered an alternative solution in my thread on WTDWTF. They suggested moving the initialisation to a static initialiser block instead of initialising the fields inline. This seems less hackish than a method that always returns null, but it also adds a lot of clutter if there are a lot of fields to initialise (which there are in my case). For example: public class Injection { @CapabilityInject public static final Capability<IItemHandler> CAPABILITY; static { CAPABILITY = null; } public void doStuff() { // No warning Capability<IItemHandler> capability = CAPABILITY; } }

Thanks for the response. Using a method annotated with @SuppressWarnings("ConstantConditions") worked, the @Nonnull wasn't needed on the field access. I have all my packages annotated with @MethodsReturnNonnullByDefault already, so @Nonnull wasn't needed on the method either. I'm not sure what the best alternative to the current injection systems would be, though ideally it would be something that didn't require suppressing IDE warnings.

This is a cross-post from StackOverflow, I thought I'd ask here as well in case anyone knew the answer. Forge injects specific objects into public static final fields with null values through the @CapabilityInject and @ObjectHolder annotations. Unfortunately whenever I reference one of these fields in a context that doesn't allow null values, the "Constant conditions & exceptions" inspection in IntelliJ IDEA warns me that the field may be null (because it doesn't know about the injection). I know that these fields won't be null when they're accessed, so I'd like to disable the warning for them. Is there a way to disable the warning for a specific field or all fields in a class? Adding @SuppressWarnings("ConstantConditions") or //noinspection ConstantConditions to the field doesn't remove the warning on the field access and adding the annotation to the field's class only removes the warning in that class. I'd like to avoid adding //noinspection ConstantConditions or null-checks to every location I access the fields from.

In the code you posted you register the recipes in that method, but they're created (instantiated) somewhere else.

Forge's documentation explains how to register things using registry events here.

ItemStack#getTooltip checks for its existence using the type ID 99, which is "any numeric". This means you can use any numeric data type for the tag, including integer and short.

There's a JAR and EXE version of the installer available for every version of Forge, including the versions for Minecraft 1.12.x.

It looks like you create your recipes before you create and store the filled bucket ItemStack, so the field hasn't yet been populated when they reference it. Where and when do you create your recipes? It should be done in RegistryEvent.Register<IRecipe>.

You can hide the attribute modifiers from the tooltip completely by setting the "HideFlags" key of the ItemStack's compound tag to a number with bit 2 set to 1 (e.g. 2). You can also subscribe to ItemTooltipEvent and modify the list of tooltip lines as you want.

You need to register an implementation of IBlockColor for your Block to recolour the greyscale grass texture when the model is rendered. Do this by calling BlockColors#registerBlockColorHandler in init from a client-only class. You can get the BlockColors instance using Minecraft#getBlockColors. Look the BlockColors class for the vanilla IBlockColor implementations.

Override Item#getAttributeModifiers, the ItemStack-sensitive version of Item#getItemAttributeModifiers. It has an ItemStack argument that you can access the NBT of.

Create a directory for each version, then create a launcher profile for each version (in the Launch options tab) with its game directory set to the directory you created.

You need to implement IRecipe#getCraftingResult to iterate through the InventoryCrafting and find the input ItemStack(s) that will determine the output NBT, then create and return the output ItemStack with the appropriate NBT. As Draco said, I do this for item damage in the ShapedArmourUpgradeRecipe class.