Draco18s

Based on having done basically that ("scan all the blocks") it's pretty fast, especially if you use Ernio's method, just keep in mind that an ExtendedBlockStorage object is a 16x16x16 volume (so each one in the array covers a range of 16 blocks on the Y axis inside a given chunk). If you're only looking for grass and leaves, you can easily skip the first 3. The fourth is probably skippable as well. Then you just have to skip the null ones until you run out (its possible for a non-null volume to be above a null volume in the extreme hills biome!). You can see what I did here. There's some things I need to update (like the fact that at one time it was registered as an IWorldGenerator, and now isn't and is called from a chunk generation event, so I can remove that interface).1 But the core loop is valid and handles blocks as their internally native block IDs (to avoid the overhead of converting every int back to a Block). There's some bits you don't need, of course, but that should at least help you figure out how to translate human-readable x/y/z values into the NibbleArray indexes (I had to dig into each call from world.getBlock until I had dissected all the way down to an inline array lookup). Also be alert to the fact that I broke the 16 block volume into two 8 block volumes for my own purposes. 1Huh, I don't remember doing that (Line 151). The hell'd I do that for? *Fixes*

Might want to hash the blocks' position so they don't all run at the same time.

No, I mean why do you need that information? What are you doing with it?

Look at the function in Item.java You return an ArrayList of ItemStacks

Obviously add "return false" just so you can run it. But seriously, are you sure you have the right method signature? If you put @Override on the line above this method, what does Eclipse tell you?

There you go then. I do suggest moving your EventHandler functions out of your main mod class (I use a single EventHandler class that deals with all of them--with a second client-sided one for client-side stuff--other people use one-class-per-event).

A better question is: What are you trying to do? With that answered, we might be able to provide a shortcut around simulating the world (which is doable, but takes a lot of work you really really don't need). In the end though, there might be some plants you just can't examine their behaviors and estimate accurately for. For vanilla ones you can fake it by going, "I know what this behavior is, use this edgeCaseFunction." Mod-added plants you won't have much luck with, except by looking at what mods people might want to use and see if there are edge-case plants there you have to account for. Then build an API that lets other mods tell you, "Hey this is an edge case plant, here's an edgeCaseFunction I'd like you to call for it."

Well, that would depend on the function being overriden. If you aren't overriding an existent function, you can't call super (well, you can, but generally speaking you don't ask the superclass to run a different function than the one the subclass is running). Ten bucks says if you comment the line and run the code, this function never gets called.

This is what makes javadoc awesome. Look at that goldmine of information! Some of the other events I've used have been a lot less detailed (cough, all TickEvents).

Show the code, you're likely doing something wrong. I did this exact thing just the other week. I created an event, set up a handler as normal, then posted it to the Forge event bus. Things went peachy. My only issue was that I had to modify CustomOreGeneration to do it. (Which I did a PR for and had accepted!)

Every tick would be bad. You'd want something more like every 1000 ticks. Which will probably be "every tick, if random(1000) == 0, doSomething()." As for mods that add large lava lakes, test your code out in the Nether. I took my smoke generation code down there and found it was very poor, performance wise. But I'll admit that was due to the fact that I was telling the game to spawn a ton of liquid blocks that then had to float up to the ceiling....

Override public ArrayList<ItemStack> getDrops(World world, int x, int y, int z, int metadata, int fortune) instead

That is not how you cancel events. You write your own code that subscribes to, and listens for, the event, then you call setCanceled() on the event object passed to your code. You've obviously created your main class, right? See the annotation that says "EventHandler" and you have a function that is passed an FMLInitializationEvent object? You didn't have to go into FML's classes and tell FML to initialize your mod, right? Same deal.

OTOH this is just a mess: Blocks.planks.getDefaultState().withProperty(BlockPlanks.VARIANT, BlockPlanks.EnumType.JUNGLE); We have to get the default state, then modify it, rather than having a way to access the state directly and involves a static property and an Enum. I mean, fine, sure, BlockStates are nicer than metadata and can include world-based states (FenceGate:isInWall) but holy hells did the code get longer and harder to read. world.getBlockMetadata -> 3 means I need a hand dandy lookup table, yes, but it's a lot easier to remember that function call and a lot faster to type out.

Or as I just said to a friend, "I looked at ASM this evening and ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." http://s10.postimg.org/yawll0uad/back_eyed_loaf2.png[/img]

I was actually looking at ASM about two hours ago for another problem (making crops tick less often) and arrived at the conclusion that ASM is way too advanced for my britches. I mean, I literally want to change "return 10" to "return 100" and I have no idea HTF to do that.

I would be interested in this as well. What I'm doing at the moment (which doesn't set things on fire, but spawn a "smoke" liquid) is randomly look at blocks near a player and if its lava, do something.

That's what you're already doing.

Because when you told it to look for textures, you didn't tell it not to look in Minecraft's assets folder. MODID + ":" + TEXTURE does not equal TEXTURE

Packets.

Ask the author.

It doesn't appear that there is a way to override the vanilla rendering of falling block entities and that renderer does not take into account two-pass blocks. So I end up with this: http://s24.postimg.org/nxzjt9jud/2014_12_19_15_29_04.png[/img] The block is supposed to look like Cobblestone. My block left, cobble stone right: http://s15.postimg.org/nimb1uzqj/2014_12_19_15_31_06.png[/img] Just another reason why I wanted to pre-multiply the original texture with an overlay.

getBlock != getBlockState getBlockState in 1.8 is equivalent to getBlockMetadata in 1.7, based on what I understand of the changes.

Yes, hit the jar with JD GUI, that will decompile it into near-readable source and you'll be able to figure out what he used.

Story of my life.