Choonster

You first need to implement IBlockColor, you'll probably want to do this with a lambda or anonymous class. Look at the BlockColors#init method for the vanilla IBlockColor implementations for leaves and grass. You'll also need to create an IItemColor implementation that returns the Block's colour. Look at the ItemColors#init method for the vanilla IItemColor implementation for leaves and grass. Call BlockColors#registerBlockColorHandler with an instance of your IBlockColor implementation and the Blocks that you want coloured at runtime. Call ItemColors#registerItemColorHandler with an instance of your IItemColor implementation and the Blocks (or their Item forms) that you want coloured at runtime. Do this from a client-only class (e.g. your client proxy) in the init phase. I have an example of an IBlockColor/IItemColor implementation for a block that uses the grass colours here.

You don't need to replace the Blocks themselves, just register IBlockColor instances for them and replace the textures using a resource pack (e.g. your mod's assets diretory). Do this using the BlockColors class, which also contains the Vanilla IBlockColor implementations.

That's only necessary when the original method is being called on a thread other than the main client/server thread, e.g. packet handlers are run on a Netty thread. Commands are run on the main server thread, so scheduling a task like that just runs it immediately on the same thread; making it completely pointless to do so.

Minecraft and Forge don't support Java 9, you need to use Java 8.

I haven't encountered that error before, but I haven't tried to remove every vanilla recipe. My code doesn't delete any recipes, it just overrides them with new recipes that do nothing. Your code is only overriding vanilla recipes, it shouldn't be touching any mod recipes. Set an exception breakpoint for NullPointerException and filter it to only include exceptions thrown from the GuiButtonRecipeTab class. When this exception is thrown on line 146, look at what's null (I think it can only be the list local variable) and what the value of GuiButtonRecipeTab#category is.

Why not?

1.7.10 is no longer supported on this forum. You're unlikely to get any support for MCreator anywhere except the MCreator forums, the Modder Support section of this forum is for helping people who understand programming fundamentals and aren't using a tool to generate (poorly-written) code for them.

It is overriding each recipe, but I'd argue that's it no more manual than removing them. Either way you need to specify which recipes to override/remove, overriding them only requires one additional class; you don't need to create a class or JSON file per recipe or anything like that.

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.