Choonster

CommonProxy subscribes to RegistryEvent.Register<Block> and calls BlockRegistry#register, which registers all of your Blocks. BlockRegistry also subscribes to RegistryEvent.Register<Block> and registers the same Blocks a second time, resulting in this warning. Also see Code Style Issue 1. Your registration code should be largely self-contained, the class that registers the Blocks and Items should be the same one that subscribes to RegistryEvent.Register; there's no reason to subscribe to it in one class and call methods in another class to do the actual registration. You can see how I handle Block and ItemBlock registration in my mod here.

The main point of IItemColor is to separate the colour methods from the Item class (where they used to be in older versions), so you shouldn't implement it on your Item. You should implement IItemColor with a lambda or anonymous class instead. You can see how I implement and register my mod's IBlockColors and IItemColors here. ColorHandlerEvent was added in a recent 1.12.2 build, before that you needed to register them in init.

That should work. Could you post your entire model and IItemColor implementation?

There are two overloads of Block#hasTileEntity: one with no parameters and one with an IBlockState parameter. Only the one with no parameters is deprecated, the one with the IBlockState parameter is the one to override.

You haven't specified a tint index for any of the quad faces of your models, so they're not recoloured at render time. builtin/generated automatically specifies a tint index equal to N in the quads it generates for each layerN texture.

My harvest swords can be repaired with the ToolMaterial's repair item in anvils and I don't override any repairing-related methods or subscribe to any anvil-related events to achieve this; it just works by default. It looks like ModTools.initRepairs isn't being called from anywhere, since it's private and not called in ModTools. This means that your ToolMaterials' repair items aren't being initialised; which would explain why your tools can't be repaired. What do you mean by "it won't register"? Did you try to use the ItemAxe(ToolMaterial) constructor with a non-Vanilla ToolMaterial only to find that it threw an ArrayIndexOutOfBoundsException? You need to use the ItemAxe(ToolMaterial, float, float) constructor for modded ToolMaterials; the ItemAxe(ToolMaterial) constructor uses the ToolMaterial's ordinal as an index for the ATTACK_DAMAGES and ATTACK_SPEEDS arrays, which only have values for the Vanilla ToolMaterials.

That's correct.

Sneak-right clicking on a Block with an Item will only call Item#onItemUse by default, ignoring Block#onBlockActivated. To change this behaviour, either override Item#doesSneakBypassUse to return true (for your own Items) or subscribe to PlayerInteractEvent.RightClickBlock and call PlayerInteractEvent.RightClickBlock#setUseBlock with Result.ALLOW (for Items from Vanilla or other mods). This is handled in PlayerInteractionManager#processRightClickBlock on the server and PlayerControllerMP#processRightClickBlock on the client. Don't compare to ItemStack.EMPTY directly, it's just one of many possible empty ItemStacks. Use ItemStack#isEmpty instead.

Recipes and entities are managed by registries, so register them in RegistryEvent.Register<IRecipe> and RegistryEvent.Register<EntityEntry> respectively. Use EntityEntryBuilder to create the EntityEntry. World Generators aren't managed by a registry and there's no dedicated event to register them, so do it in preInit/init/postInit.

You can also check which player died by checking their UUID. Usernames can change, it's best to compare UUIDs instead as they're constant and unique.

The client only needs Forge installed if the server's mods need to be installed on the client. If none of the server's mods are required on the client, a Vanilla client can join. In what context? If you have a MinecraftServer argument available, use that. If you have an object with a method that returns MinecraftServer (e.g. World#getMinecraftServer), use that. If all else fails, you can use FMLCommonHandler#getMinecraftServerInstance.

serverSideOnly just tells the client to skip loading the mod if it's installed, you need to set the acceptableRemoteVersions property to "*" as well. This tells it to accept any remote version, including none.

1.7.10 is no longer supported by Forge, which means it won't receive updates and you won't get any help with it on this forum.

ArmamentHaki's post. I'll edit in a quote. Edit: I don't think I can on mobile.

For the record, I'm not a moderator; I've just spent a lot of time on here.

Using the JSON system is the recommended way to add recipes (and should be used wherever possible), but you can instantiate and register the recipe from code during RegistryEvent.Register<IRecipe> if necessary.

You've told us what you're trying to do, but you haven't told us what's not working or what you need help with. I'd recommend splitting the active light and facing into two separate properties, which will allow you to use Forge's blockstates format to specify the model once, the texture for each active light and the rotation for each facing rather than having to make a model for each combination of active light and facing.

You need to specify the IRecipeFactory class in the _factories.json file and then create the individual recipe JSON files for any recipes that use the recipe class.

If you look at EntityHorse, you'll see that it registers its DataParameters with their default values in its override of Entity#entityInit (called when the entity is constructed, before its position has been set) and then sets their actual values in its override of EntityLiving#onInitialSpawn (called when the entity is first spawned, after its position has been set). You need to do the same thing.

Just for future reference, you linked to the 1.12.1 branch; which is currently 11 commits behind 1.12.2 (the branch with the latest changes on it). I also recommend linking to a file/folder in a specific commit rather than a branch so that the link will remain pointing to the same code in the future rather than pointing to code that's been changed/removed.

If you look at the implementation of NBTTagCompound#setUniqueId, you'll see that it doesn't use the key you give it directly; it uses two different keys based on it. This means that NBTTagCompound#hasKey will never return true for the key you passed to NBTTagCompound#setUniqueId, you need to use NBTTagCompound#hasUniqueId instead. ItemStack NBT is automatically synced to the client. If you're setting on the server but can't access it from Item#addInformation, you're doing something wrong. Post your code. To create your own API or implement an existing one like IItemHandler/IFluidHandler; or to store data without having to serialise it to/deserialise it from NBT every time you want to access/modify it.

You need to register an IItemColor implementation for your Item with Minecraft's ItemColors instance in init. You can get the instance from a getter in the Minecraft class.

It's one JSON file per recipe, yes. Ah, I missed the version in the thread title. JSON recipes and the recipe registry were added in 1.12, 1.11 still uses the old recipe list system. In 1.11 and earlier, recipes should be registered in init.

Recipes are now managed by a Forge registry, so IRecipe extends IForgeRegistryEntry and instances of it should be registered in RegistryEvent.Register. As Kokkie said, you should use JSON files wherever possible. You can register your own recipe, ingredient and condition factories to extend the JSON system.

NEI is broken.