Draco18s

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.

Awesome, thanks!

That's not how you compare Item Stacks. You should, in this case, be doing hand.getItem() == Items.dirt

JD GUI does a great job. The only thing it can't recover is the friendly names for vanilla methods and fields (you get SRG names and have to do a manual lookup on each one* but class names come through just fine). *Speaking of, while I have the methods.csv and fields.csv for 1.6.4, I can't find the srg <-> friendly names list for 1.7.x

if(player.isSneaking) { ... } ? (or is it player.capabilities.isSneaking , I can't remember)

GameRegistry.registerTileEntity(...)?