sequituri

Your proxy does need this method declared, but only as abstract -- (No {...} used). In other words, in the common proxy only: public abstract void registerRenderThing(); -- also add @Override to your client proxy version of the method with the actual code {...}. Alternatively, if you do not want an abstract base class, declare the method with empty braces "{}" instead.

READ THE EAQ~!!!, then... Either upgrade to latest Forge or downgrade Java to Java 7.

look at: hasContainerItem() and getContainerItem()

Check your renderer with @Overrides on every method you expect to get called by Minecraft. I suspect that since you changed the method signature, your renderItem method is not called at all. Or, you could call it yourself from the Overridden renderItem method. Another question... Why does your method have two (2) ItemStack parameters? You can always get metadata from the original parameter.

Where do you call this method? I cannot find it in your posted code. It should look like this: proxy.registerRenderThing(); Did you forget it?

Two things: [*]You're using an old version of Minecraft that is no longer supported. Update to 1.7.10... [*]Cauldron is not Forge ... Forge is not Cauldron. Your answer might find be better answered on the Cauldron forums. ~S~

Also, make sure you do not "Export jar file" in the IDE. You did remember to run: gradlew build (right?) then get your jar from the build/libs folder...

.........1.........2..... ....|....0....|....0....| BioshockPacketChannel As you can see the message is indicating that your channel name length is 21 characters, where: 21 > 20 the maximum length of a channel name. Therefore, your channel is invalid.

Please see this article on why it is bad to pass 'this' outside the constructor. You should not call registry or any method that uses 'this' when constructing.

This is a pixelmon issue, not a forge issue. Take it there.

@bcwadsworth, I have given you the code to get a tag containing all of the TE's NBTData. Saving it in your entity is basic java. Read the inline comments. Also, beware that you will have no way of knowing how to recreate a tile entity just by its NBT data. You need its class, as well as the associated Block's class. So, if the TE is deleted as Hugo said, your item is no longer associated with anything. @Whov, if you understood the question, the answer is not "Go the <someperson> way." State what you think the problem is and offer a suggestion. @bcwadsworth, you could get more focussed help here by explaining what you are trying to accomplish with this method you seek.

Sounds like an incorrect import of Block.

Don't override 'isOpaqueCube()' that handles the opacity based on graphics level for you in the BlockLeaves base class. ALso, the only statements you need in the constructor is the setCreativeTab one. Everything else is, again, in the base class you used.

Here is an example of subclassing and overriding TNT blast sizes: CAVEAT: It has not been syntax checked or tested. Use at your own risk.

NBTTagCompound tag = new NBTTagCompound(); p_tileEntity.writeToNBT(tag); // examine or do something with the NBT Data tag // if you change the values for some silly reason p_tileEntity.readFromNBT(changedTag); But, beware! Messing with the NBT data of an unknown TE can cause nasty behavior or crashes.

You're missing what I'm telling you (important parts of it, anyways.) Try this: mkay?

You're also going to need to do a whole lot of sanity checking when you start allowing arbitrary user content in that form into the game. Keep that in mind when you start getting floods of reports of crashes with no explanation.

<associatedBlock>getBlockTextureFromSide(1) {{ which calls getIcon(1, 0) }} returns that ItemBlock's texture; that is, unless you override the Icon or the getIconFromDamage(int dmg) method. So, your block getIcon(side,meta) method should return the front icon when it sees side 1 and meta 0.

Start putting debug log output in the different methods that are called and the ones they call, etc. (The most important place is where it eventually calls setBlock...). That would get you a decent trace through your logic. Alternatively, run in debug mode, break point on your StructureGenerator, and single-step through the code.

I looked at the code and as far as I can see diesieben is correct. You're temple (which is a hallway from the looks of things), will generate at the deepest depths of the overworld. You'd have to dig down to bedrock to see anything.

public static int ironmanMk1helmID; // <==== This is zero by default public static int ironmanMk1chestID; public static int ironmanMk1pantsID; public static int ironmanMk1bootsID; //Define Iron Man Armor *** This is the renderID (see above) ---v public static Item ironmanMk1Helmet = new IronManMk1(IronManMk1Mat, ironmanMk1helmID, 0).setUnlocalizedName("IronManMk1Helmet"); public static Item ironmanMk1Chest = new IronManMk1(IronManMk1Mat, ironmanMk1helmID, 1).setUnlocalizedName("IronManMk1Chest"); public static Item ironmanMk1Pants = new IronManMk1(IronManMk1Mat, ironmanMk1helmID, 2).setUnlocalizedName("IronManMk1Pants"); public static Item ironmanMk1Boots = new IronManMk1(IronManMk1Mat, ironmanMk1helmID, 3).setUnlocalizedName("IronManMk1Boots"); With this code, you are setting the renderID to be cloth (0). I don't do much rendering stuff at all, but that doesn't seem correct to me. I'd help you more, but my konwledge of rendering issues is pretty slim.

I suspect your syncConfig is reloading the configuration before it is first saved... thereby erasing your firsttime update. Please repost your main class as it is now. It is unnecessary to config.load() in syncConfig as the configuration should already be loaded and updated, it only needs to be read into variables and saved. In fact, you FIRSTTIME property check & set should be part of syncConfig anyways.

The possibility also exists the getHealth was overridden but with a @SideOnly(Side.SERVER) annotation and is being called here on the client side.

This topic has been moved to ForgeGradle. [iurl]http://www.minecraftforge.net/forum/index.php?topic=23598.0[/iurl]

Without a full log, it's hard to say what led up to the error.