Choonster

InventoryPlayer#getSlotFor is a client-only method (i.e. it's annotated with @SideOnly(Side.CLIENT)), so it doesn't exist on the dedicated server and can't be used from common code (like an event handler running on the logical server).

The crosshair texture is in the assets/minecraft/textures/gui/icons.png file.

Event handlers with the same priority are called in the order that they were registered in. This isn't documented, so it's probably best to consider it an implementation detail that shouldn't be relied upon.

I explain how to get an InputStream from a SoundEvent here:

The forge launcher profile isn't actually configured to use a Forge version. You need to set it to a Forge version in the Launch Options tab.

That doesn't appear to be the FML log. Please find the file named fml-client-latest.log in the logs folder of the game directory and then upload it to Gist and link it here.

Post the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin. This should tell us why it's crashing.

I explained how to sync item capabilities here:

That code looks like it's from a Bukkit plugin (or a plugin for a similar system) rather than an old Forge mod. You need to use IBlockState#getValue to get the values of the various properties stored in the BlockDoor class from the state. This will tell you the door's facing and hinge position diesieben07 explained which properties you need and which block to get their values from earlier in the thread.

I must have confused getHitVec with the hitX/Y/Z arguments of Block#onBlockActivated, which I'm pretty sure are between 0 and 1. I don't have my IDE in front of me, so I might be mistaken (again). Edit: The hitX/Y/Z arguments of Block#onBlockActivated are between 0 and 1.

You register the Class object with the event bus, which means your event handler methods need to be static. The Forge documentation explains this in more detail here.

getHitVec is the position on the block that the player clicked (in the range 0-1), not the position of the block in the world.

Are you definitely registering your event handler properly? Post the registration code.

Which version are you using? By the looks of it, it's not 1.12; which is where the new registry system was introduced. Before 1.12 there was the substitution alias system (GameRegistry.addSubstitutionAlias), though I never managed to get it working properly myself.

These warnings were quietened down in Forge 1.12-14.21.1.2399. Update to 1.12.2 and you won't see them anymore.

Have you tried looking at Biomes O' Plenty's code for Nether biomes?

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.