Draco18s

1) He's not calling it every tick. Blocks get random update ticks, and his isn't set to tick randomly and he's not calling ScheduleUpdateTick anywhere, so his updateTick method isn't being called. 2) Even if he was, checking the block volume of a 5x5x5 region doesn't take that long. It takes ~0.6ms to scan an entire chunk.

That's the exact same thing, except now it's a class-scoped variable instead of function-local. The default value for a boolean is false.

Change compound.setTag(extendedPropertiesName, subCompound); subCompound.setShort("career", entity.getCarrerId()); To subCompound.setShort("career", entity.getCarrerId()); compound.setTag(extendedPropertiesName, subCompound);

You need packets.

Aren't these names indicative of what needs to go there? o..O The first one is called "mod" I wonder what goes there. YOUR MOD CLASS, MAYBE?

Uh... ItemStack(item, count, meta) ?

Tee hee, that was the same crash.

System.out.println("Trying to repair: " + input.getItem() == MyItems.bronze_helmet + " && " + repair.getItem() == MyItems.bronze_ingot);

Just got to where I can pull up my code (I was on my tablet, on a shitty 3G signal, waiting for my car to get its oil changed, so I couldn't remember how I'd done TE integration). There's actually no reason that you need to reflect access to that class. Because here's what that function you're invoking looks like: public static void addPulverizerRecipe(int energy, ItemStack input, ItemStack primaryOutput, ItemStack secondaryOutput, int secondaryChance) { if (input == null || primaryOutput == null) { return; } NBTTagCompound toSend = new NBTTagCompound(); toSend.setInteger("energy", energy); toSend.setTag("input", new NBTTagCompound()); toSend.setTag("primaryOutput", new NBTTagCompound()); if (secondaryOutput != null) { toSend.setTag("secondaryOutput", new NBTTagCompound()); } input.writeToNBT(toSend.getCompoundTag("input")); primaryOutput.writeToNBT(toSend.getCompoundTag("primaryOutput")); if (secondaryOutput != null) { secondaryOutput.writeToNBT(toSend.getCompoundTag("secondaryOutput")); toSend.setInteger("secondaryChance", secondaryChance); } FMLInterModComms.sendMessage("ThermalExpansion", "PulverizerRecipe", toSend); } Notice the last line, FMLInterModComms.sendMessage("ThermalExpansion", "PulverizerRecipe", toSend); FML inter-mod communications are an awesome piece of tech that gives a pretty substantial ability for mods to configure each other without the need for adding packages to build paths and what not. So what you actually want to do is basically copy the source for that class (I believe it's on their github? If not I can toss my copy up somewhere, I've forgotten where I got it from) and just add it to your own class hierarchy. It'll save you on the reflection calls.

You need to download the "dev" version of CofH and add it to your build path. I'm away from my own code at the moment, but when I get back in front of it, I can give you a better idea of how our works, I added recipes for my own project. Or I'm pretty sure I did; I spent a good while on IRC asking around about how to do it x3

Ok, i don't know why you ate having the problem your seeing, but you have a huge amount of pointless ItemStack creation. You get the result item twice (causing two lookups which have O(n) time; also the advantage of a hash map is lost by iterating over the key-value pairs this way, but item stacks don't override hashcode, so your kind of stuck with this method, so look up the result once), so you can create a new stack with the same item and metadata (rather than cloning the stack). And you do the same thing when registering your recipes, creating a new stack from the parameter, rather than cloning. You also don't need a separate HashTable for the output size: you can quite easily store that as the first hash's value-stack's size.

And if that isn't somehow enough, you can use ASM and make a core mod. Warning: I am not responsible for any effects, temporary or permanent, acquired from having The Abyss looking back at you.

Try it as N247S said, then. Setting the brightness to 0.

Man, Spaceballs came out in 1987. I didn't see it until I was in college (post 2005).

"Stupidly large" but not " ly large." I recall someone having an issue with too much NBT data on an item before, but it was an amount measuring in MB.

Download, run, click install.

Ok, what is it that you are trying to do? Are you trying to make "particles which are black"? In which case, you probably want the blend mode GL11.glBlendFunc(GL11.GL_ZERO, GL11.GL_ZERO);

http://goo.gl/OF5NIo

That class on the server returns a Container (just as you said) and on the client returns a GuiContainer (not like you said). public class GuiInventoryFurnace extends GuiContainer

Also be highly skeptical of the Javadoc. world.getWorldTime() calls provider.getWorldTime() which returns the private field totalWorldTime which has the comment "stores the time of day, 0-23999" which is false. (Note, I may have misremembered the actual names, but the comment is the important part here. The saved time is the total time and is not bounded to 24000 ticks. One modder decided that the javadoc was correct and the implementation wrong, so for his mod he decided he would modulo the time down under 24k, save it back to the world time, and use it like that. I had to discourage that idea).

Err, no? No? Last I checked the base implementation for description packets were blank, because vanilla entities had custom packets and didn't need it. No, not really. The update function runs on both client and server, so the update tick will handle the update to burnTime. The only thing that does need to get synched is anything that can happen that the client cannot be aware of which includes inventory modification. Sorry, the premise and conclusion here don't seem to be correlated, nor does it contradict my own statement of "you'd have to include the information in the description packet."

#ThisIsWhyYouUse"glPushState()"And"glPopState()"

In which case: 1) You still need to declare the getPacket onPacket methods 2) Including the information is not in itself bad 3) You only need to call markBlockForUpdate when something major changes. The code I posted addresses 1 and 2 which are required, because otherwise a player will log in and experience a desync (client not matching server state) due to the machine being in the middle of a cycle and the client started at the top. #3 I did not include. You do not need, and should not call, markBlockForUpdate just because the entity ticked. But there are cases where it will need to be called (inventory changing) but again, I did not include this call.

That's really not a good idea. Adding additional types (like ATG does) is fine, forcibly overwriting is not cool. The user would select "ATG" and get yours. They'd select "Flat" and get yours again.