Choonster

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.

Ehm, how does one do that? Doesn't it want one list? VillagerRegistry.VillagerCareer#addTrade is a vararg method, you can pass any number of ITradeList objects to it and Java will automatically wrap them in an array.

Your IDE can almost certainly tell you which classes implement ITradeList . In IDEA, there's a small green circle with a down arrow in the side bar between the line numbers and code, clicking this brings up the implementations of that interface/method. Eclipse probably has something similar.

You need to create and register a VillagerProfession using GameRegistry.register . You can then create one or more VillagerCareer s for the VillagerProfession and use VillagerCareer#addTrade to add trades to each VillagerCareer .

I've told you what you need to do, I'm not going to just give you the code. You need to understand what I've told you and how to translate that into code.