Choonster

It was a missing [nobbc][/quote][/nobbc] tag in my post, nothing to do with the code.

You haven't created a new array for RGB here, it's pointing to the same array as DEFAULT_RGB . Any changes made through RGB will be visible from DEFAULT_RGB and the RGB field of all other instances of this class. Either create the default array in the RGB field's initialiser or use Arrays.copyOf to create a copy of the DEFAULT_RGB array and assign this to RGB . Edit: Add missing closing tag.

The subclasses of PlayerUseItemEvent are only fired for items that used while right click is held, e.g. charging/firing bows, eating food, blocking with swords. PlayerInteractEvent is fired with Action of RIGHT_CLICK_BLOCK when the player right clicks a block. KeyBinding s are client-only, but any persistent changes to the world (e.g. placing blocks) must be made from the server side. You need to send a packet to the server when the player right clicks a block with the key held. When the server receives this packet, check if the player is allowed to place the block (e.g. the target position is in range, the player has unlocked this ability) and then place it. This site explains networking, including how to use the Simple Network Wrapper (which you'll need to use here).

I suggest you share your findings so other people with the same problem can find the solution.

That should work, yes. That is indeed redundant. As the name suggests, PlayerTickEvent is only fired for players.

If you're not using the latest version of Forge, update. Recent versions overhauled the registry system, adding the GameRegistry.register method to register any IForgeRegistryEntry object (e.g. Block , Item , BiomeGenBase ).

Post your new code.

If the tick is happening on the server side and the Phase is correct (it doesn't really matter whether it runs in START or END as long as you pick one), increment your tick counter and check if the appropriate amount of ticks have passed. If you don't check the side and Phase , the handler will be called twice per tick per side for every player. You can't store the tick counter as a field of your event handler, since the same handler will be called for every player on the server. The more players there are, the more often one of them (there's no guarantee as to which one) will take damage. Event handlers are essentially singletons like Block s or Item s, so you can't store data for a specific object in their fields. The Entity#ticksExisted field stores the number of ticks the entity has been alive for. Use this instead of maintaining your own tick counter.

EntityLiving#tasks is initialised in the EntityLiving constructor, so you can add tasks in the constructor of your entity class (if you're spawning your own entity) or after the entity has been constructed (if you're spawning an existing entity with new AI tasks). If you're dealing with entities being spawned from external code (e.g. vanilla or other mods), you can't add tasks in EntityEvent.EntityConstructing as it's called from the Entity constructor before the EntityLiving constructor has run. The first event fired after the EntityLiving constructor has run is EntityJoinWorldEvent , which is the earliest you can add tasks in this situation.

Ah, I assumed you were using an IDE project generated by ForgeGradle. If you've created the project yourself it probably doesn't have the dependencies specified by ForgeGradle. If your mod and the mods it depends on (if any) aren't using any access transformers, you can find the compiled forgeSrc library in the Gradle cache: ~/.gradle/caches/minecraft/net/minecraftforge/forge/<forge_version>/<mcp_mappings_channel>/<mcp_mappings_version>/forgeSrc-<forge_version>.jar (replace ~ with %USERPROFILE% on Windows) If you are using access transformers, you can find the compiled forgeSrc library in your ForgeGradle workspace: <workspace_dir>/.gradle/minecraft/forgeSrc-<forge_version>-PROJECT(<project_name>).jar In both cases, the JAR containing the source code will be in the same directory with the -sources classifier.

Don't manually open any JARs. Your IDE project has a forgeSrc library as a dependency, this contains the Minecraft/Forge classes with the source code attached to them. Simply open a class in this library and your IDE will show you the deobfuscated source code. The JAR you tried to open is using SRG (semi-obfuscated) names, hence the srgBin classifier. build/tmp contains temporary files created by the build process, you should never need to use any of these files.

Block is a singleton, there is a single instance per block type shared between all blocks of that type. This means that you can't store per-position data in fields of your Block (or the position itself). Most methods of Block include the BlockPos of the block that's currently being affected/queried (or whatever it is that the particular method does).

Are you looking at the code in your IDE or manually opening a JAR? Your IDE should show you the deobfuscated source code when you open a vanilla class.

You didn't post the FML log or the crash report.

As it says on the Minecraft Forum thread and the download page:

You're confusing the blockstates format and the item model format. You can also use Forge's blockstates format instead of the vanilla format. Either use a blockstates file and move your model to models/block instead of models/item or set your OBJ model as the parent of your JSON item model.

You need to register your biome with GameRegistry.register in preInit, just like every other singleton class that implements IForgeRegistryEntry .

ModelLoader.setCustomModelResourceLocation only affects item models (including but not limited to the Item forms of Block s). It has nothing to do with the in-world model for blocks. The ModelResourceLocation passed to ModelLoader.setCustomModelResourceLocation can point to a regular item model (the first priority) or to a variant of a blockstates file (only used if the item model doesn't exist). The ModelResourceLocation <modid>:<name>#<variant> can either point to assets/<modid>/models/item/<name> (an item model in JSON, OBJ or B3D format) or the <variant> variant of assets/<modid>/blockstates/<name>.json (a blockstates file). For an item model, the variant should be inventory . If you want to load an item model other than the default (the one with the item's registry name), call ModelBakery.registerItemVariants . To load an OBJ model directly, include the .obj extension in the ResourceLocation / ModelResourceLocation 's resource path. To load a model specified by a blockstates file, don't include the extension. Minecraft used the name blockstates because it was only designed for blocks, but Forge adds the ability to use it for items as well. Edit: Added a missing closing tag.

World#setBlockState sets the block state at the specified position in the world.

I suggest you use the existing ModelRender fields of ModelBiped where possible so that ModelBiped 's methods can set the rotation angles and element visibility for you. Even if you override every method of ModelBiped , some parts of the code directly access and modify its fields rather than calling methods to do so. You'll still need to override most of ModelBiped 's methods to apply to your custom elements.

Blocks.grass uses a standard ItemBlock that will be returned from Item.getItemFromBlock .

Override Item#getArmorModel to return the armour's ModelBiped instance.

To use a mod with the obfuscated (non-development) client/server, it has to be reobfuscated first. Do this by running the build Gradle task.

Instead of a separate method to register each type of object, there's now a pair of GameRegistry.register methods that register any IForgeRegistryEntry . This includes Block s, Item s and SoundEvent s. The single-argument overload expects the object to already have its registry name set with IForgeRegistryEntry#setRegistryName . The two-argument overload takes a registry name as an argument. Make sure you're using Forge 1.9-12.16.0.1819-1.9 or newer, this is the version that added the new registry system.

Minecraft only loads one model per item by default: the one with the item's registry name. To load additional models, call ModelBakery#registerItemVariants client side in preInit.