Draco18s

Because you asked for a field named "maxDamageArray" not "field_77882_bY" which is what it will be in a runtime (not development) environment (at least, in 1.7.10, I can't find the mappings for 1.8.9 as quickly).

Been a while since I looked at it, TBH.

replaceBlocksForBiome is intended for replacing the top 4 blocks of stone with grass or sand (or at least, that's what Minecraft uses it for). The bottom bedrock is handled by the chunk provider the last time I looked at it.

Oh god. Why is your render registration code inside your item? That will absolutely positively crash the server, it does not give a shit that you only call that method from the client, the JVM still needs to load the class and validate it and the mere existence of a reference to a client-side class will cause it to attempt to also load that class. Why are you using getUnlocalizedName()? The unlocalized name shouldn't be used for anything other than language localization. You did not include your JSON

You will want the data in two places. Place 1 is where it gets read from the config file and stored. I would store this in my ServerProxy (or CommonProxy, whatever you want to name it). These values will still exist when the player logs into a server, but won't be used unless the player starts a local server. Place 2 is where the client would store the values it receives from the server and uses for display. I would store this in my ClientProxy. Note: this is a separate field that is public in the ClientProxy along side the public field in the ServerProxy. These client-side values would be overwritten every time the client receives the info packet the server sends on login (sent in the PlayerLoggedInEvent from the sever). The cool thing is, you don't have to do anything special for this setup to work for a singleplayer game: the single player instance would send a packet to the single player client and the values would be updated correctly.

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.