Draco18s

Basically you'd want to do an outward radial search looking for a location that matches the following criteria: 1) Block is solid 2) Block above is air

Considering that you haven't posted your damn code, how the fuck should I know?

You should never set a value in the constructor. There are something like three different constructors for entities, which are all used in different places. Depending on which one you're using, that value might be being overwriten when the entity gets an update from the server that tells it what the server knows/sends to the client.

http://www.minecraftforge.net/forum/index.php?topic=22764.0 You should be using a GUIHandler instead.

I have this feeling he isn't writing java code, but trying to do this via a resource pack. And the end result is: you can't do this with a resource pack.

If you're extending a class, don't copy-paste that class into your new one. Let the parent class handle all the stuff that's exactly the same. That's the beauty of OOP.

Man, if only I knew where it was crashing...might possibly be EntityBlasterBolt.java line 94? No, that couldn't possibly be it.

Ah, you're right. That's what the OP gets for using useless variable names like "item" "item1" and "item2" FFS, name those something intelligent. If you're going to number them at least make them "1" "2" and "3"!

(From a purely aesthetical point of view, the fog will probably look better, as it will lower the maximum view distance as well as make things darker, rather than a 2D flat overlay, giving the effect of tunnel vision).

Ah, it got moved, I forgot about that. Sorry, last time I used it was 1.7.10 Had a real tough time locating the right package so I could see what it's usage parameters were!

new ItemStack(Blocks.DIRT, 2), new ItemStack(Blocks.DIAMOND_BLOCK) if(item1.getItem().equals(item2.getItem())){ Gosh. I wonder why this doesn't return true.

Look at how the blindness potion works. You'll need to subscribe to the FogDensity event and do some manipulation to it/the GL state.

@Optional is part of the cpw.mods.fml.common.Optional package. Eclipse isn't very good at being able to auto-import that particular annotation, usually because it requires a parameter and if you don't have it (because you don't know what it is) the package can't be determined. I had a lot of trouble the first time I tried to use it.

If you want a "stack of 5" to be used, you need to create your own IRecipe implementation.

Something something, recipes still don't respect stack size something something. ItemStack oneCopperCoin = new ItemStack(ModItems.copper_coin, 1); GameRegistry.addShapelessRecipe(new ItemStack(ModItems.silver_coin), oneCopperCoin, oneCopperCoin, oneCopperCoin, oneCopperCoin, oneCopperCoin);

That's not the actual exception. You have this: catch (Exception e) { This is known as a Pokemon Catch Block. I.e. "gotta catch em all!" You didn't even then print out the error but instead a generic "I had a problem" message.

What?

You need to know how to program (in at least one language, even if it isn't Java!) before you can mod.

Rather than update the NBT every tick, you can save a "start" time and compare with the current time, waiting for the elapsed distance in time to be large enough.

You misplaced thing involving the doohickie inside the whatchamacallit method.

Or your main mod class. I see no point in passing off the initialization events to the proxy classes when they can just do the work themselves. Prior to 1.8 my common proxy would be virtually empty except for the stub methods for the client proxy to override. Now in 1.10 it contains several wrapper methods around GameRegistry.register so I don't have to set the registryName between creating the item and registering it. End result, my main class is full of the dirty work (a lot of people put this in a ModBlocks class, and that's fine, but there's litterally no reason to pass the event off to the proxy, only to call ModBlocks.doStuff(): just call doStuff from Main!)

Finding logs is easy: they'll always be within 1 block (sometimes up wards) of another log (99% chance of never touching a different tree if their bases are not right-up-next-to-each-other adjacent). Leaves will be within 3 blocks (IIRC the distance correctly) in any direction of their "parent" log. There's literally nothing you can do about stripping the leaves off "nearby" trees, where their blocks intermingle. Not unless the variant types are different.

Yes, because the GUI portion still needs to know what the slots are which is defined in the Container (the "server" half).