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.

it doesn't have a 'current' and I can't jump out of it if I can't touch the bottom of a pool of it.

 

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.

The particles setting is only used by

RenderGlobal#spawnEntityFX

, but some particles are spawned using

EffectRenderer#addEffect

directly and won't be affected by the setting. The setting doesn't affect the particle limit, it just reduces the chance for particles to spawn (Decreased) or completely stops particles from spawning (Minimal).

 

Oooh, alright.

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

What makes outdated OpenGL (I think Minecraft uses 2) so slow compared to modern OpenGL?

 

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

That's a lot of particles . Is that per mod?

 

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

But you can use JSON for pretty much anything you want.

 

Its all about how you read the data.

slot automatically checked the IInventory isItemValidForSlot

 

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.

I see a possible problem: There are several methods called "registerRender" in various non-sided classes, and each tries to get Minecraft. If I recall correctly, that's a client-only call. Methods called registerRender should either be in your client proxy or calling proxy.something to avoid blowing up the server. Indeed, you'd be well served to relegate all mention of "render" to your client proxy, because all rendering (graphics) is display stuff that is toxic to a server

 

More or less correct.

The problem is not the code running, but the class loading into the JVM.

TileEntitySpecialRenderer

 

That's not how light works

Let me quote it again.

 

 

GameRegistry.addShapelessRecipe(new ItemStack(Bong.bbowl, 3), new Object(), " B ", 'B', Items.iron_ingot); 

 

new Object()

?  Seriously?

Its not.  You are registering your recipes wrong.