Draco18s

[me=Draco18s]skips the local variable assignment.[/me] Items.lava_bucket.setContainerItem(null);

if(A == Foo && B == Bar) { }

Hey, try reading the console. It'll tell you what thread it came from [Client] At pos: Grass [Server] At pos: Dirt [Client] At pos: Grass [Server] At pos: Dirt

Yes. There's no point in adding inside the loop (even if it didn't crash, you'd then have to check the item you just added as well and that could be bad!). Also, your loop in your prior post makes no sense. //for each item in the list // save a reference to the item // if the block harvested is Leaves // add potato. You never do anything with the ItemStack

Step 1: Set registry name Step 2: Register item That's pretty simple. Even looking at the first line of your Items class I see this: Step 1: Register item Step 2: Set registry name Which is ass-backwards and should have been obvious.

Implementing an interface is not exactly basic Java, but absolutely required in order to mod. The problem is we can't give you an example. Interfaces are incomplete objects that require you to implement (write, code, program) their methods because the interface doesn't.

There are 3 names: obfuscated "notch" names ( a.bc() ) SRG deobfuscated names ( WorldServer.func_12345_a() ) MCP deobfuscated names ( WorldServer.getWorldTime() ) For reflection, you have to use MCP names in dev, but SRG names in release. There's no real way around this, which is why ReflectionHelper exists.

isWet is a boolean based on whether or not the entity was recently (or still is) swimming, that's it. It's not even close to what you'd have to do to check for caves. As for sky_light, that absolutely helps, and more so than canSeeTheSky. canSeeTheSky checks only the vertical column of blocks at the current location. sky_light can reach up to 15 blocks underneath an overhang. Sky_light is also tracked independently of block_light, so lit caves will still register as caves. The problem is figuring out whether or not the material blocking out the light is made of stone, as opposed to wood, dirt, water, or other block type.

Lets follow this through, shall we? void_ingot = registerItem(new Item(), "void_ingot").setRegistryName(Resources.MODID, "void_ingot").setCreativeTab(CreativeTabs.tabMaterials); So first we call registerItem(Item, string) which redirects us to registerItem(Item, string, CreativeTabs) . What's that do? GameRegistry.register(item, new ResourceLocation(Resources.MODID, name)); Ah, well. There's your problem. This method takes the item, gives it a registry name (if it doesn't have one), and registers it. Then you come along and call setRegistryName on the return object.

Your getMetaFromState is fucked up. int i = b0 | ((PrimalBlockLog.EnumWoodType)state.getValue(VARIANT)).getMetadata(); Well, b0 was already 0, so I don't see what the point was. case 1: i = 4; break; You know what, fuck it, just overwrite the value, we didn't need it. Not actually a problem, but in your getStateFromMeta: ((meta & 3) % 4)) (meta & 3) already returns a value, [0-3] so why the %4?

And this is why you fix your NPEs by looking at the line of code that actually caused the crash rather than assuming it was the new icon.

public MyTamableChicken extends EntityChicken implements IEntityOwnable

Yes. There is a better way. It's called: int someVarFromTE; if(te == null) { someVarFromTE = 0; //default value } else { someVarFromTE = te.getSomeValue(); }

post the crash.

I figured that was self-evident. But yes, ommiting the line entirely would be equivalent.

IIRC, "require-after" isn't enough to "hide" the mod in the menu->installed mods listing. It just declares the load order. Making the child mod actually show up as a child meant using another tag, but I've forgotten what it is, as I've never used it.

Or what Eclipse says when you hover over the underlined red area. ("No method to override, remove override annotation" means that you're not actually overriding the method you think you are, you need to change the method signature to match, not remove the annotation. The reason Eclipse suggests that is because it doesn't know what the method signature should be, so it makes the only suggestion it can).

Show MineBoard.java

if(r.nextInt(100/100) == 0) Why do you have math here? if(r.nextInt(1) == 0) Or better yet if(true)

Jesus Christ. IInventory#canInsertItem and IInventory#isItemValidForSlot

It is because you put the "stop flying now" code inside the "if wearing chest piece" block.

My mistake. *salute*

Well, I continue to study tesselator The Tessellator is just a wrapper class around OpenGL calls. So at this point what you probably need is a starter course on GL commands.

I don't think the blocks need to be registered with the GameRegistry, but they do need to be instantiated.