Choonster

You'll want to use [url=http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-forge-1-6-4-1-8-eventhandler-and]IExtendedEntityProperties[/url] for that.

I believe the InstantiationException is thrown because Handler is a non-static inner class and thus can't be instantiated by itself (I think a constructor that takes an instance of the outer class is generated when the code is compiled, so there's no zero-argument constructor for Class#newInstance to call). Handler should either be a static inner class or a separate class entirely.

Use your IDE's Find Usages/Call Hierarchy feature to look for usages of EntityConstructingEvent and you'll see that it's fired from the Entity constructor. If you look for usages of EntityPlayerMP (the server-side player class), you'll see a new instance is created when a player logs into the server ( ServerConfigurationManager#createPlayerForUser ) or respawns after dying or conquering the End ( ServerConfigurationManager#respawnPlayer ).

This is the case if you're using the vanilla ItemModelMesher#register methods (like the OP is), but Forge's ModelLoader#setCustomModelResourceLocation and ModelLoader.setCustomMeshDefinition methods (which do the same thing as the vanilla methods) need to be called in preInit rather than init.

You should create the ToolMaterial once (probably in the same class where you instantiate and register your items, just before you do that) and then reference it for your tools. Multiple tools can share a ToolMaterial (e.g. all vanilla wooden tools use ToolMaterial.WOOD ). You can also just use an existing ToolMaterial . The Set is the Block s that the tool is effective against, but Forge replaces that with the harvest level system so it's not actually used unless some mod decides to ignore Forge's system and use the vanilla system. Just in case, you should pass an empty Set (just create a new HashSet ) instead of null ; that way the vanilla system won't crash with a NullPointerException .

Extend ItemTool and call setHarvestLevel("someCustomToolClass", toolMaterial.getHarvestLevel()) in the constructor. As long as the ItemTool#toolClass field is null (which it will be if you extend ItemTool directly), getHarvestLevel and getToolClasses will return the result of the super methods (which use the values set by Item#setHarvestLevel ). You can then call Block#setHarvestLevel with the same tool class to allow a block to be harvested by that tool.

Use OreDictionary.getOreIDs to get an array of ore IDs for an ItemStack and OreDictionary.getOreName to get the ore name from an ore ID. See this code for an example.

RegistryNamespaced#getNameForObject will return a ResourceLocation of the object's name (e.g. minecraft:iron_ingot ). Item.itemRegistry contains a reference to the item registry. If you have an ItemStack , you should use ItemStack#getUnlocalizedName to get the item's unlocalised name and ItemStack#getDisplayName to get the item's localised display name. If you only have an Item , use Item#getUnlocalizedName to get the item's unlocalised name and StatCollector.translateToLocal(item.getUnlocalizedName() + ".name") to get the item's localised display name.

Skins are downloaded and applied to players asynchronously, so you can't immediately replace the player's skin with your custom skin. When an AbstractClientPlayer is instantiated, it calls SkinManager#func_152790_a . This downloads the the name of the player's skin and cape textures from Mojang's session servers and calls SkinManager#func_152789_a for each one. This downloads the texture in a separate thread (if it hasn't already been downloaded) and then calls SkinManager.SkinAvailableCallback#func_152121_a (implemented by AbstractClientPlayer ) on the next tick to store the ResourceLocation of the texture in the appropriate field of AbstractClientPlayer . I'd recommend subscribing to EntityJoinWorldEvent (only on the client side) and checking if the entity is an AbstractClientPlayer . If it is, call SkinManager#func_152790_a with your own implementation of SkinManager.SkinAvailableCallback#func_152121_a that that the Type is Type.SKIN and then sets the player's locationSkin field.

Wouldn't it make more sense to override Item#hasCustomEntity and Item#createEntity to spawn a custom EntityItem class directly instead of using the event?

Ah, I gave you the SRG name of 1.8's NetworkPlayerInfo#locationSkin field instead of 1.7.10's AbstractClientPlayer#locationSkin field. The SRG name you want is actually field_110312_d . In future you should include the Minecraft version in the title so people know which version you're working with.

This is the same error as before: you're only using the deobfucated (MCP) name, not the obfuscated (SRG) name. You need to pass both names to ObfuscationReflectionHelper.getPrivateValue (and other methods in the same class that take a String array/vararg of field names). You can find the SRG name of a method/field in the MCP mapping CSVs, which can be found in your Gradle cache. For recent 1.7.10 versions of Forge, the CSVs are in ~/.gradle/caches/minecraft/net/minecraftforge/forge/<forge_version>/unpacked/conf (replace ~ with %USERPROFILE% on Windows). You can also download the mappings from the MCPBot Website.

To answer the question in your previous post, only use reflection when you can't use a normal method call/field access. Examples of this include accessing non-public methods/fields or methods/fields with a dynamic name/argument list and instantiating a class that's only known at runtime (i.e. you have a Class object you want to create an instance of).

Potion effects can only be applied to living entities, so you need to check if the entity is an instance of EntityLivingBase , cast it to EntityLivingBase and call EntityLivingBase#addPotionEffect on it.

Yes, override Block#getSelectedBoundingBox to return an AABB with the BlockPos 's x/y/z as the minimum coordinates and x/y/z + 1.0 as the maximum coordinates (like this).

Override Item#hasCustomEntity to return true and Item#createEntity to return a new instance of FragEntityItem at the same position as the Entity argument.

It works for me in the development environment and the deobfuscated client. Are you sure you're actually creating and registering an instance of your Block class? Does it have a bounding box smaller than a full block?

Whoops, that is indeed the method's name. I've edited my post.

Like diesieben07 said, it will work if you use UTF-8 everywhere. I assumed that your code was already saved as UTF-8, I didn't realise that the section sign is also present in older encodings like Windows-1252. You can see an example of this here (lang file is here). It looks like this in the obfuscated client. Edit: Added missing closing tag

Thanks diesieben07, that works perfectly. I looked at the bytecode earlier using Bytecode Viewer and noticed the INVOKEDYNAMIC instruction (though I wasn't fully aware of what it did), but it seems that the program doesn't know how to display it properly.

Lambdas can be used in place of any interface with a single method (like ItemMeshDefinition ), they act like an implementation of the interface with the lambda's body as the method body. This works in the development environment, just not in the obfuscated client.

Yes, it's just mapping to a constant model location regardless of the ItemStack 's metadata/NBT.

ClientSidedHorsesMod / Better Archery / BetterBowsMod1.6.4.zip is trying to load a client-only class on the server. This is an error with the mod, report it to the author (if they're still maintaining it) and remove it from the server and clients.

Implement ItemMeshDefinition (either in an anonymous class or a normal class depending on how complex the model selection logic is) and return the appropriate ModelResourceLocation based on the ItemStack . Register the implementation with ModelLoader.setCustomMeshDefinition in preInit or ItemModelMesher#register in init. You'll also need to call ModelBakery.addVariantName with the names of all possible models so they're loaded by Minecraft (this can be done in preInit or init). Edit: The method is called ModelBakery.addVariantName , not addVariant

I've run into a strange issue where using a lambda to implement ItemMeshDefinition crashes the game with an AbstractMethodError any time the item is rendered in a GUI. This only happens in the obfuscated client, not in the development environment. I've set up a small test case here. The lambda is used here. To reproduce, simply open the mod's creative tab or spawn in its block. The block will render without issue in the world, but as soon as it's rendered in a GUI or a player's hand the game crashes. You can see the crash report here. Does anyone know why this happens or how to fix it? It seems like it may be some weird interaction between lambdas and the reobfuscation process.