Draco18s

Question, as I have a 1.7.10 mod that creates blocks at runtime. The reason is that it's actually generating replacement blocks for an uncertain number of blocks, some of which may exist (as they are mod blocks) or may not. The reason being that I create BlockFalling types for them and give them several runtime generated textures (as in, I have a custom TextureAtlastSprite that takes the original texture and pre-renders an overlay onto it for several variants). For vanilla, it's no problem to handle this once, externally, and ship it. But due to there being other mods that also ship blocks that I'd want to replace (and due to the overlay nature of the texturing) I did this programmatically and it even handles variant resource packs. I even supply an API hook for someone to write a plugin that would register additional types. When I do get around to updating to 1.9, how should this be handled instead? Pre-packaged data? (My number of blocks is small, vanilla would be 3 with another 3-6 from mods, so it's not an undo amount of work to generate the data externally, I'm just trying to understand the advertised method).

There's client (logical) and client (physical). The physical client can also be the physical server.

That visual glitch is entirely because you're extending the vanilla chest and letting it "double-up" with the vanilla chest. The vanilla chest is trying to be a double chest, but you're drawing your own not-double chest as well. The visual effect is called z-fighting.

Ernio is right, just use the Class#isAssignableFrom method. The only reason to compare strings is if one of the objects isn't actually a class reference. i.e. I was read class names from the config file and had to validate against a class reference (and then because it's user-entered, I wanted to be able to check for typos, so there's some Levenshtein distance code in there too; inefficient as hell, but it only runs when there's no match for the supplied string).

Do nothing != Return null

[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)