Choonster

Not with the vanilla crafting table. Either add some intermediate product so you don't have 10 ingredients in a recipe (e.g. 5 copper coins become a stack of coins and 2 stacks become a silver coin) or create your own machine that can handle the required recipes.

We'll need a bit more detail than this. Does the unlocalised name displayed in-game match the unlocalised name in the lang file? What's the exact name of your lang file? Do you have a pack.mcmeta file and if so, what's pack_version set to? If you have a pack.mcmeta file with pack_version set to 3 (which you should do), Minecraft will load all assets with lowercase names. This means your lang files should be en_us.lang, fr_fr.lang, etc. If pack_version is set to 2 or you don't have a pack.mcmeta file, Forge will wrap your mod's resource pack in LegacyV2Adapeter which loads lang files with the old mixed-case names, e.g. en_US.lang, fr_FR.lang, etc.

Use the ResourceLocation(String, String) constructor to specify the domain (mod ID) and path (name) components of the ResourceLocation separately. You only need to combine them with a colon when specifying a ResourceLocation in a string (e.g. an item registry name in a recipe file). The vanilla crafting system has always ignored the stack size of ingredients, a recipe can only consume one item per slot. I noticed in your previous post that you're registering the recipe in postInit, but it should be done in the registry event (as I said in my initial reply).

It's the same as GameRegistry.addShapelessRecipe: name is the registry name and group is the recipe book group. We could help you fix this if you posted your JSON file and the errors. It works perfectly fine with mods. If there are specific bugs you've encountered, report them so they can be fixed.

Return true from Block#onBlockActivated when an action was performed to prevent Item#onItemUse/Item#onItemRightClick from being called.

That will just rotate your model by 90 degrees about the x axis; for anything more complex than 90-degree rotations about the x and y axes you need to use TRSRTransformations.

No, advancements are loaded when the server starts (WorldServer#init, called from MinecraftServer#loadAllWorlds) and when it's asked to reload them (MinecraftServer#reload). WorldEvent.Load will be fired for dimension 0 just after the initial load, but there's currently no event fired for the reload. This PR adds an event for the reload, but it's not likely to be merged until the author documents the event.

Instead of storing a collection of items and comparing the contents of a the crafting grid against them, recipes now store a collection of Ingredient objects and ask each one whether the contents of the crafting grid match. Recipes are now stored in a Forge registry, so each one has a unique registry name. This also means that they should be registered in the corresponding registry event using IForgeRegistry#register. GameRegistry.addShapedRecipe works much like it did before, but now it requires you to specify the registry name (the first parameter) an optional recipe book group (the second parameter). Recipes with the same group will be shown together in the recipe book. The vararg parameter should contain the shape strings followed by the character and ingredient pairs, just like before. The ingredients can be ItemStacks, Items, Blocks, Strings (for ore dictionary matching) or Ingredients. I highly recommend learning the JSON system. If you're getting errors that you don't understand, post them along with your JSON files and we can try to help you. That's not quite what the OP is looking for. Forge already allows you to specify conditions for a recipe that can disable it at load time, that class allows you to specify conditions for an individual ingredient. diesieben07 explains how to create your own conditions here:

I just re-read your post and noticed that you're using a block. Item display transformations are only applied when the model is rendered for an item, they're not applied when the model is rendered for a block in the world. I think you can specify a base TRSRTransformation for a model using Forge's blockstates format. Set the "transform" key of a variant to an object with either a single "matrix" key or some combination of "translation", "rotation", "scale" and/or "post-rotation" keys. You can see a simple example here in RFTools and a slightly more complex example here in a Forge test mod. Look at ForgeBlockStateV1.TRSRDeserializer to see how Forge deserialises TRSRTransformations.

If you look at the model format, you'll see that your display section is incorrect. You need to specify the display transformations for a specific transform type (e.g. thirdperson_righthand, ground).

The game directory is C:\Users\owner\AppData\Roaming\.minecraft, but you've installed mods in C:\Users\owner\Desktop\.minecraft\mods so Forge isn't loading them. Either install mods in C:\Users\owner\AppData\Roaming\.minecraft\mods or change the game directory to C:\Users\owner\Desktop\.minecraft.

That's exactly what vanilla does and what you need to do. They don't need to visible (i.e. you don't need to specify the "display" element in the advancements), they just need to exist.

Override Item#getAttributeModifiers to call the super method, add a movement speed AttributeModifier to the returned Multimap and then return the Multimap. The modifiers in the returned Multimap will automatically be applied to any entity that equips or holds the item. The key of the Multimap is the attribute's name (IAttribute#getName).

WorldServer#getAdvancementManager returns the server world's AdvancementManager. The World#advancementManager field is never used by client worlds, I'm not entirely sure why it's in World rather than WorldServer. Looking into this further, advancements are actually stored in the AdvancementList instance (AdvancementManager.ADVANCEMENT_LIST and ClientAdvancementManager#advancementList). You'll need to use reflection to access the server instance and the internal collections.

If a recipe fails to load, there will be an error in the log explaining why.

You can use the PotionEffect(Potion potionIn, int durationIn, int amplifierIn, boolean ambientIn, boolean showParticlesIn) constructor to control whether or not particles are displayed for a PotionEffect.

Forge automatically loads every recipe file in the assets/<modid>/recipes directory, you don't need to manually register them.

RealmOfTheDragons#onPostInit is never called because it has more than one parameter, there should be a warning in the log telling you this. This means that CommonProxy#onPostInit is never called and your entity is never registered. Proxies are for sided code, common code belongs in your @Mod class (or classes called from it). I recommend using an interface rather than a class as the common type of your proxies (i.e. the type of the @SidedProxy field).

Where do you register your entity?

That would work, but EnumFacing.getFront uses the same indexes as EnumFacing.VALUES (because it uses EnumFacing.VALUES), i.e. EnumFacing#getIndex rather than Enum#ordinal. There's also no need to use any index here, you already have the EnumFacing returned by EnumFacing#getOpposite.

I explained that in my first reply. I've also just edited it to include a detail that I forgot (EntityLiving#setEquipmentBasedOnDifficulty needs to be called from EntityLiving#onInitialSpawn).

Why are you using EntityJoinWorldEvent for your own entity? Look at the constructors of the ItemStack class to what parameters they require. You should have your Item and Block instances stored in static fields of a class (usually called something like ModItems/ModBlocks), you can get the instances from these fields to pass to the ItemStack constructor. Do you actually know Java? You need to have a solid understanding of both Java and OO programming in general to a make a mod. This forum isn't for helping people with basic Java issues. Do you ever spawn an EntityMasterJacket?

Use Entity#setItemStackToSlot to set the item in an entity's equipment slot. If the mob should always spawn with this equipment or always has a chance to spawn with it, override EntityLiving#setEquipmentBasedOnDifficulty to set the equipment and then override EntityLiving#onInitialSpawn to call it. If the equipment is specific to the way it's being spawned, set the equipment manually before spawning it. Edit: Forgot to mention that EntityLiving#setEquipmentBasedOnDifficulty needs to be called from EntityLiving#onInitialSpawn.

EnumFacing#getOpposite already returns an EnumFacing, you're getting its ordinal and then looking it up in the EnumFacing.VALUES array to get the same EnumFacing. You don't need to use the EnumFacing.VALUES array here at all. The indexes of EnumFacing.VALUES are the ones returned by EnumFacing#getIndex, not the ones returned by Enum#ordinal. These happen to be the same, but it's more correct to use the same indexes that are used to populate the array. Use EnumFacing.getFront to get an EnumFacing by its index rather than using the EnumFacing.VALUES array directly.

Use EnumFacing#getOpposite to get the opposite facing. Use the EnumFacing.values method or the EnumFacing.VALUES array to get all EnumFacing values.