Draco18s

That's because both of those factors are handled by EntityBase#onEntityUpdate They check the current block that the entity is in, and if that block's material is water, you get pushed (and get a drown meter). If it's lava, you get set on fire.

On 2) TileEntities do no exist in your inventory. In your inventory everything is an item stack. You will need to also add NBTtags to the ItemStack for the block when it is in ItemStack form. Crafting and such will need to have custom recipes (look up IRecipe). On 1) You need to override getActualState() IIRC

My suggestion: Stop using Clojure.

Technically, most mods are different client-to-server because of rendering code and other client-side-only code

By the way, you won't want to overwrite the values from the client's config. If they connect to a server (receiving the server's values), then disconnect, and load their own single player game, the config values should be used at that point. Otherwise you'll have a disparity between logging into the server first, then playing single player, than playing single player directly.

Oooh, alright. I knew that the setting lowered the chance of the particle spawning, but I thought it lowered the cap, too.

GL_QUADS is bad for performance because it requires triangle computation on the CPU.

No. Its global and modified by the game settings. Low Particles reduces the count (though I don't know by how much).

Its all about how you read the data.

Haha, that would be silly!

You can read and write NBT files outside of the Capabilities and WorldSavedData system. It's a file like any other, run through CompressedStreamTools, IIRC.

Sure exploding torches. Whatever you want.

Oh god, if you're going to make your own block, don't use the vanilla torch item. That's dumb. Just remove and replace the recipe.

You can also use FMLInitializationEvent#getSuggestedConfigurationFile() which you could manipulate to get the config directory There's also Loader.instance().getConfigDir()

Then World#getSkyLightSubtracted() IIRC.

Yes, your save location is faulty because it is inside the JAR file. You need to point to a location that has write access.

More or less correct. The problem is not the code running, but the class loading into the JVM.

That's not how light works

Let me quote it again.

Its not. You are registering your recipes wrong.

Well. Given that the ClientProxy he posted contains an empty @Override for the PreInit method (no call to super) that code would not produce that call stack.

He's not, actually. He has a CommonProxy (which registers crafting) that the server proxy extends, and the client proxy extends the server proxy. (The "common" part can be wholly removed and its code added elsewhere). Recipes, item instantiation, item registration all of that should happen in the main mod class. Some tutorial recently shoved it all into the proxy for no god damn reason and its made a mess of things ever since.

243 isn't your code, I was mistaken because I found the problem. Which you did not comment on:

And which line is line 243? Actually I don't care. GameRegistry.addShapelessRecipe(new ItemStack(Bong.bbowl, 3), new Object(), " B ", 'B', Items.iron_ingot); new Object() ? Seriously?

Ok, so now I need to see the mitems class, because none of the code you posted lately references it. GameRegistry.addShapelessRecipe(new ItemStack(mitems.nvud, 9), new Object[]{" X ", 'X', mitems.mvud}); See how you make an item stack from mitems.nvud ? Where it nvud set to a value? It certainly isn't happening in your Bulb (or other item) classes, which do the instantiation and registration (which, by the way, is terrible practice).