Choonster

I have an explanation of the model loading process and how model locations are mapped to model files here. If you want the item form to use the same models as the block form use new ModelResourceLocation(item.getRegistryName(), "igneous_type=[type]") as the location for each metadata value, where [type] is the value of the igneous_type property for that metadata value. This will load the models specified by the blockstates file with the item's registry name (which should be the same blockstates file used for the block models), using the igneous_type=[type] variant. You can see how I do this for my coloured rotatable blocks here ( registerBlockItemModelForMeta is just a wrapper around ModelLoader.setCustomModelResourceLocation ). The blockstates files can be found here and here.

Which version of Minecraft are you using? Always specify this in the thread title. You should also wrap your code in [nobbc] [/nobbc] tags so it's formatted properly.

Most mod authors will have a thread for their mods on Minecraft Forum with the official download links. Many host their mods on CurseForge/Curse.

In that mod, ClientProxy#preInit and ServerProxy#preInit both call the super method ( CommonProxy#preInit ), so the code is run on both sides. This is equivalent to running the code from your @Mod class directly, so there's not much point in using the proxy system for it.

You can't make a mod without knowing basic concepts like how to implement interfaces. If you don't register a renderer for your entity, Minecraft will use the one registered for its super class.

Just like your capabilities, you're registering your packets in CommonProxy#preInit but ClientProxy overrides this and never calls the super method. Packets need to be registered on both sides, so do this from your @Mod class instead of your proxy classes.

That's not valid Java, a class name isn't a value. You must have a solid understanding of Java and OO programming in general before you can make a mod. You need to create an instance of a class (named or anonymous) that implements IRenderFactory and pass it to RenderingRegistry.registerEntityRenderingHandler . This class must override IRenderFactory#createRenderFor to create and return the RenderFireball instance using the provided RenderManager instance.

Capability registration must happen on both sides, so do it from your @Mod class instead of your proxy classes.

From the description of this section:

Use your IDE to find classes that extend Render , or look at the RenderManager constructor to see where vanilla creates its Render instances. If your entity extends EntityFireball and should render like the vanilla fireball, use RenderFireball .

Use RenderingRegistry.registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit. IRenderFactory has a single method that takes the RenderManager instance as an argument and creates and returns the instance of your Render class. You can implement it using a named or anonymous class (Java 6/7), a lambda or a constructor method reference (Java . You can find links to several tutorials here. McJty has a tutorial on mobs here. You can see how I register the IRenderFactory for an entity in my mod here. Edit: Removed unintentional smiley.

I think Lex meant "Why would your capability already be on the player in AttachCapabilityEvent.Entity ?"

The WorldType constructor automatically inserts the WorldType into the WorldType.WORLD_TYPES array (used by the GUI). Are you ever referencing the ApocalypseWorldType class anywhere to allow it to be loaded?

You can technically use a TESR to render items by registering it with ForgeHooksClient.registerTESRItemStack , but this is deprecated and marked for removal as soon as possible. Apart from that, you have to use the model system.

I don't think it's possible to do this with the builtin/generated model (or models that extend it like item/generated ), since the quads are automatically generated for each texture layer rather than specified in the model itself. You'll probably need to create a clone of ItemLayerModel (the IModel used for builtin/generated ) and its IBakedModel / ICustomModelLoader that has the option of generating unshaded (fullbright) quads for each texture layer. Although this is called shade in the model format, it's controlled by the BakedQuad#applyDiffuseLighting field in the code. To control which layers are rendered unshaded, you could either hardcode it for that particular item's needs (i.e. layer 0 is shaded, layer 1 is unshaded) or make your IModel implement IModelCustomData and specify this using Forge's blockstates format (which can also be used for items, despite the name). To make a block render as fullbright I had to make it emit light in addition to setting shade to false in the model; I'm not sure if shade is all you need for an item model. You could also request that something like this be added to Forge, though I believe the rendering guy (Fry) is currently away. There's also no guarantee that the request will be accepted or implemented immediately.

I would recommend always posting solutions so people can find them in the future even if you're no longer reading/responding here.

Like other singletons, Enchantment IDs are automatically assigned and can change between saves. Do not use IDs, pass the Enchantment instance to your constructor.

You don't need to get the ID yourself. Use ItemStack#addEnchantment to add an Enchantment to an ItemStack . Make sure you've registered your Enchantment with GameRegistry.register .

Your blockstates file has a syntax error. Edit: The error is in the blockstates file, not the block model as I originally said.

ok sorry to bug you more you have helped me alot, I dont have gradle.properties in my .gradle file is there anywhere i can get it, if not how can i create it You need to create it yourself. It's a plain text file, so use a text editor or your IDE.

The build Gradle task outputs the JAR to build/libs. Are you sure it's not working?

You need to override Block#createBlockState to create a BlockStateContainer with your property.

The item model you've specified doesn't exist. If an exception occurs when loading the item model, Forge will try to load the model specified by the corresponding variant of a blockstates file. I have a more detailed explanation of the model loading process here.

Just like the OP, you've set JAVA_HOME to the JRE path instead of the JDK path.

The model files you specified don't exist. Side note: I'd recommend using Forge's blockstates format or Vanilla's multipart blockstates format. These both allow you to combine models conditionally, eliminating the need to manually create a model for every possible combination of connections. I use Forge's blockstates format for a BuildCraft-style pipe model here. Vanilla uses the multipart blockstates format for Redstone and Fences, among other things.