Choonster

Don't store the StateMap.Builder in a field, it's only a temporary object. You must actually create an instance of StateMap.Builder . StateMap implements IStateMapper .

ItemMeshDefinition is an interface with a single method: ModelResourceLocation getModelLocation(ItemStack stack) . This receives an ItemStack and returns a ModelResourceLocation pointing to the model that should be used for the item. How it determines which ModelResourceLocation to use is completely up to you. I have an explanation of the model loading process and how ModelResourceLocation s are mapped to models here.

Items have models, not icons. What exactly do you want the item's model to be controlled by? For metadata-based models, use ModelLoader.setCustomModelResourceLocation in preInit to set a model for each metadata value. For models based on some other aspect of the ItemStack , use ModelLoader.setCustomMeshDefinition in preInit to set an ItemMeshDefinition for the Item ; this allows you to map an ItemStack to an arbitrary ModelResourceLocation . You must tell Minecraft to load each possible model by calling ModelBakery.registerItemVariants . For models based on some aspect of the entity holding the item or the world it's in, specify overrides in the item model itself. These can use any IItemPropertyGetter registered for the Item ( Item#addPropertyOverride ) to specify another item model.

What you have now will work because you've used the proxy system properly, but it's not very flexible because it assumes that every Item uses the default model. Block breaking particle textures are specified by the "particle" texture of the block model. Are you using a regular baked model specified by a blockstates file or are you using a TileEntitySpecialRenderer ?

Your preInit , init and postInit methods all handle FMLInitializationEvent , so they're all called in init. I would recommend moving your model registration to a dedicated client-only class rather than registering models as you register items/blocks. Instead of reinventing method overloading with a series of instanceof checks, just use an actual overloaded method.

ModelLoader methods must be called in preInit, not postInit. Use the toString method instead of concatenating the registry name with an empty string. You added a recipe that has an ItemStack with a null Item as its output. This is probably because you added the recipe before you created and registered your items. You must register your TileEntity class with GameRegistry.registerTileEntity . Make sure you include your mod ID in the name you pass to this method.

Set a breakpoint in ManaHandler , does the client player exist when message sent from the PlayerLoggedInEvent handler is received?

PlayerLoggedInEvent is only fired on the server. The client doesn't save any data, so you need to send the player's current mana value to their client when they log in.

ManaHandler is called when the client receives a ManaValue message from the server. PlayerProperties#sendToClient sends a ManaValue message from the server to the client. PlayerProperties#sendToClient must be called from PlayerProperties#setMana , but only on the server side (when World#isRemote is false ).

ManaHandler calls PlayerProperties#setMana , which calls sendToClient regardless of which side it was called from. Only call sendToClient on the server. Your ClientProxy#getPlayer and getListener methods are incorrect because they don't account for the logical side (client thread or server thread) that they're being called from and only return the client player and listener. The MessageContext#side field tells you which logical side the message was received on. This page explains sides in more detail.

You're only calling PlayerProperties#tick on the client side (when World#isRemote is true ). You need to call it on the server instead (when World#isRemote is false ). The server should control all data and send packets to the relevant clients when they need the data for rendering purposes. The client should receive player input (clicks and key presses) and send packets to the server when these should trigger some action. You should convert your IExtendedEntityProperties to a capability, IEEP has been removed in 1.9+. You should also annotate override methods with @Override so you get a compilation error if they don't actually override a super method.

Read the EAQ, it has an entry on this crash.

I didn't say anything about the withName or withSuffix methods, they're not needed in this case. Only use ModelLoader.setCustomStateMapper when you need a custom IStateMapper for a Block . Use ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition to register the model(s) for every Item (including ItemBlock s).

This page explains how to fix that.

If you haven't already, create a dedicated client-only class to register your block and item models. In a method of this class called from your client proxy in preInit, create and register the IStateMapper . ModelLoader.setCustomModelResourceLocation will call ModelBakery.registerItemVariants for you (the corresponding ItemModelMesher#register overload doesn't), telling Minecraft to load the model. There's not really any difference between ModelLoader.setCustomMeshDefinition and the corresponding ItemModelMesher#register overload, but I'd still recommend using the Forge method rather than the vanilla one. There's no documentation on this that I know of.

There's always a log. It's written to logs/fml-client-latest.log in the game directory. Missing or broken textures log errors without crashing the game.

I don't quite understand your question. If you want a mod to load on both 1.9.4 and 1.10.2, you can either accept only 1.9.4 ( acceptedMinecraftVersions = "[1.9.4]" ) or both 1.9.4 and 1.10.2 ( acceptedMinecraftVersions = "[1.9.4, 1.10.2]" ). Forge for 1.10.2 will automatically replace the former with the latter when it loads your mod.

Forge for 1.10.2 will load any mod that accepts Minecraft 1.9.4. The doc comment of VersionRange#createFromVersionSpec briefly explains the version range format, the doc comment of VersionParser links to more detailed documentation of the format.

You haven't actually told us what the problem is. If you've received an error, post it. If your mod is only required on the server, set the acceptableRemoteVersions property of your @Mod annotation to "*" (i.e. accept any remote version, including none). main#resetStats is never actually called from anywhere.

I did link to an explanation of the model loading process in my first reply, you may want to look through the code paths it mentions to see how models are parsed.

I'm not entirely sure what you've done wrong, but you can see my implementation of an item (and its models) with enum-based metadata variants here.

Any Item can use a model specified by any blockstates JSON. Regular items obviously don't have a Block to get the variant names from, but you can use an enum like ItemDye and ItemFishFood do. In my ModModelManager class, all of the overloads of registerItemModel are designed to be used for Item s that have a single model. The overloads of registerItemModelForMeta are designed to be used for Item s that have a different model for each metadata value. All of these overloads just boil down to a single ModelLoader.setCustomMeshDefinition or ModelLoader.setCustomModelResourceLocation call with various default values.

Have you definitely imported the right Entity class?

You only call VillagerCareer#addTrade with SaltTrader_trades.trades[1] , the second value in the array. You need to add both trades, not just one of them. There's no real need to store the trades in an array, you can simply create them inline when you call VillagerCareer#addTrade .

Post your full code, not just a snippet of it.