Choonster

Are there any errors in the log? Have you registered your TileEntity class?

There should be an error in the log telling you why the model/texture wasn't loaded. If you don't know what to make of it, upload the FML log (logs/fml-client-latest.log) to Gist and link it here.

Assuming you have an EnergyStorage field in your TileEntity , call its readFromNBT and writeToNBT methods in your overrides of the corresponding TileEntity methods. You can also extend [url=https://github.com/CoFH/RedstoneFlux-API/blob/10e10af21489e351624813120ed6474c44b09ff6/src/main/java/cofh/api/energy/TileEnergyHandler.java]TileEnergyHandler[/url] and let it handle the NBT reading/writing for you.

Change the registerItemModel method to do what I said and change the code that calls it.

Did you have a question or problem?

registerItemModel should pass its Item and ModelResourceLocation arguments directly to ModelLoader.setCustomModelResourceLocation . It shouldn't be referencing any other Item or creating its own ModelResourceLocation . You should call registerItemModel with the Item to register a model for and a ModelResourceLocation pointing to the model.

I made a mistake in the first paragraph of post #69, I suggest re-reading the post now that I've corrected it. Each call to ModelLoader.setCustomModelResourceLocation with the same Item and metadata is overwriting the previous ModelResouceLocation . You only need to call this method for the standby model, the pulling models are handled through Item#getModel . I explained this in post #60.

registerItemModel should pass its arguments directly to ModelLoader.setCustomModelResourceLocation . Call registerItemModel with the item and model location for each item. To use the assets/ma/models/item/ObsidianBow_pulling_0.json model, pass new ModelResourceLocation("ma:ObsidianBow_pulling_0", "inventory") as the second argument of registerItemModel . I explained the mapping between ModelResourceLocation s and model files in my previous post. You need to have a solid understanding of Java and OO programming in general before you can make a mod. Edit: The first paragraph is about registerItemModel not MAItems.ObsidianBow

Neither of those are even valid Java. You seem to be struggling with basic concepts like creating objects and passing arguments to methods. Again you're ignoring the arguments passed to the method and hardcoding the arguments of ModelLoader.setCustomModelResourceLocation .

Why take an Item argument if you're going to completely ignore it and hardcode the Item argument of ModelLoader.setCustomModelResourceLocation ? I already told you how ModelResourceLocation s are translated into model paths. I suggest you re-read that post and try to figure it out yourself.

Change the type of the MAItems.ObsidianBow field from Item to MAObsidianBow . That's the right method signature, yes. Inside the method, you need to register the model using either ModelLoader.setCustomModelResourceLocation (with metadata 0 since the item is damageable) or ModelLoader.setCustomMeshDefinition (with an ItemMeshDefinition that always returns the same ModelResourceLocation ). Look at the code I linked in my previous post to see my implementation.

MAItems.ObsidianBow is a field of type Item , which doesn't have a getModelLocation method. Even though it currently contains an instance of MAObsidianBow (which does have that method), you haven't guaranteed that. It could contain an instance of Item or any subclass, so Java only lets you use methods that exist in the Item class. Either change the type of the field or cast the field's value before calling the method. Create the method as I described in my previous post.

Post the errors, not the suggested fixes. There is no registerItemModel method because you haven't created one. Look at the class I linked to see what that method does.

You posted ClientProxy twice instead of posting MAObsidianBow . "I got an error" is pretty vague, be more specific. I suspect the error is that you're trying to call methods that don't exist. The solution is to understand what my code is doing and implement it yourself instead of copy-pasting. testmod3 is my mod's resource domain (lowercase mod ID). Replace it with your mod's resource domain.

Always specify the Minecraft version in the title when asking questions. In 1.8.9: Override Item#getColorFromItemStack to return the appropriate colour. In 1.9: Register an IItemColor implementation for the Item that returns the appropriate colour. In both versions, this colour is a single integer in the format 0xAARRGGBB; i.e. Alpha, Red, Green, Blue. Each component is an integer in the range 0x00 - 0xFF [0 - 255].

Hover over the "i" symbol next to a download link in the expanded downloads list on files.minecraftforge.net and a popup will appear with a direct download link. This doesn't apply to the changelogs, since they're already direct links.

I've edited my previous post to make the file paths more clear. You can see how I register the item variants for my mod's bow here and here. These point to this blockstates file. You can see the implementation of the ItemModBow#getModelLocation method and the override of Item#getModel here.

new ModelResourceLocation("<domain>:<path>", "<variant>") produces a ModelResourceLocation in the format <domain>:<path>#<variant> . For item variants, this ModelResourceLocation can either point to the item model assets/<domain>/models/item/<path>.json or the blockstates file assets/<domain>/blockstates/<path>.json. <variant> should be inventory for standard item models or the variant of the blockstates file to use the model of. Your models are currently at <modid>:IronBow#inventory , <modid>:IronBow_pulling_0#inventory , etc.; but you're telling Minecraft to load and use <modid>:<registryName>#IronBow , <modid>:<registryName>#IronBow_pulling_0 , etc. (Where <modid> is your mod ID and <registryName> is the registry name of MAItems.IronBow ). If you're using item models, each item variant should have a unique <domain> and <path> pointing to a model and have <variant> set to inventory . If you're using a blockstates file, each item variant should have the same <domain> and <path> pointing to the blockstates file and a unique <variant> . Edit: Replace ResourceLocation -style file paths (in bold) with actual file paths.

Either use a blockstates file (like your current ModelResourceLocation s point to) or change your ModelResourceLocation s to point to the existing item models.

Look at the vanilla TileEntity classes, the packet has been renamed to SPacketUpdateTileEntity . LexManos decided to remove the packet ID from the packet class names in 1.9, you can see the reasoning here. This issue tracker also records most other 1.8.9 to 1.9 renames.

In 1.8+, OBJ models are rendered through the baked model system (like JSON models) rather than a TESR . Forge has a test mod demonstrating how to do this here (assets here).

I'm not trying to spam useless information, I'm posting this because I hope to find a solution for my problem. I'm very new to this so it will take me a while to understand certain things. We all started somewhere didn't we? But thank you for the information, I'll try to do something with it. Diesieben07 was talking about the logging in your code, not your post.

Foo#bar refers to the instance method/field of the Foo class called bar . Foo.bar refers to a static method/field. If you look at the doc comment of the deprecated RenderingRegistry#registerEntityRenderingHandler overload, it tells you to "use the factory version during Preinitialization." This means you need to call the non-deprecated overload of RenderingRegistry#registerEntityRenderingHandler with the IRenderFactory argument during the preInit phase. Implement IRenderFactory with an anonymous class (if you're targeting Java 6/7) or a lambda/method reference (if you're targeting Java . In future, post the crash report when asking for help with a crash. Edit: Smileys are annoying.

You installed a 1.8.9 version of WorldEdit on 1.9. Mods almost always only work on a specific version of Minecraft.

As far as I can tell, there is no way to directly do this. Use a custom packet. That has the same problem as Minecraft.getMinecraft().thePlayer.getServer() : the server is null. It should never return null on a server-side World . GuiCommandBlock#actionPerformed sends a CPacketCustomPayload with the command and either the command block position or minecart entity ID. The server-side handler then retrieves the TileEntity or Entity from this data and saves the changes.