Choonster

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.

Override Item#getAttributeModifiers to return a Multimap of AttributeModifier s that should be applied to an entity that has the item equipped in the specified slot. Use the unlocalised name of the Attribute to modify as the key.

I would recommend using ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit rather than ItemModelMesher#register in init. Regardless of which method you use, this must only be done on the client; so do it from your client proxy. You can see a more generic way to register a Block and its ItemBlock here. This makes use of several Java 8 features (functional interfaces, lambdas, method references), you'd need to replace these with the corresponding Java 6/7 features (Guava's functional interfaces, anonymous classes) if you're not targeting Java 8.

Send a packet to the server with the information required to execute the command. This includes the command and some way to identify the ICommandSender you want to use. On the server, get the MinecraftServer instance from the sending player's World ( World#getMinecraftServer ) and then use its ICommandManager to execute the command.

Post your @Mod class.

Put a breakpoint in the registerItem method and run Minecraft in debug mode. Is the breakpoint hit? Are you getting any errors in the log? Upload your item registration class and an individual item class to Gist or Pastebin with syntax highlighting and link them here. Screenshots are a terrible way to share code.

The doc comments of the deprecated methods tell you which method to use now. I explain how to register items and their models in 1.9 here.

The file should be called gradle.properties, not gradlew.properties.

I'm not sure exactly what your issue is, but you shouldn't need to write your own loader since Forge already has one. Just call OBJLoader#addDomain with your resource domain (mod ID) and Forge will load an OBJ model from anywhere you'd normally specify a JSON model.