Choonster

So you've set a breakpoint inside the if statement in onKeyInput and it was hit? Did you try stepping through the code to see what happened? The way you're sending the command chat message with EntityPlayerSP#sendChatMessage should work. ClientTickEvent is an event just like KeyInputEvent, you subscribe to it in the same way. It's even fired on the same event bus (the FML bus). Forge's documentation has an introduction to events here.

EntityPlayerSP#sendChatMessage is the correct method to send a chat message from the client (which may be a command). ClientCommandHandler#executeCommand can only execute client-side commands, not server-side commands. KeyBindings should be checked in ClientTickEvent (make sure you check TickEvent#phase to avoid checking the KeyBindings in both phases of the event) rather than KeyInputEvent. Have you registered an instance of KeyInputHandler with the appropriate event bus? Is the onKeyInput method being called? Set a breakpoint in the method and run Minecraft in debug mode if you're not sure.

This should be possible if you give the coloured faces of the model a separate tint index (see the wiki for an explanation of the format) and register an IItemColor for the Item. Use the tintIndex argument of IItemColor#getColorFromItemstack to determine which colour to return. If you're using builtin/generated or a model that extends it (e.g. item/generated), each layerN texture has a tint index of N.

Because I'm doing other things and this thread is becoming frustrating. Are you absolutely sure that you posted fml-client-latest.log? Like I said, it doesn't appear to be the correct log. "The mod doesn't work" doesn't really tell me anything. How does it not work? What's the "signature problem"? If you mean the "FML appears to be missing any signature data. This is not a good thing" message, I explained that this is bad but it doesn't crash the game or stop anything from working.

That's closer, but it's still not the FML log. The FML log should have several DEBUG and TRACE messages, the log you linked doesn't. There's no error in that log. What issue are you currently experiencing?

You're running into these limitations of Forge's blockstates format, so it's treating the individual colours as properties instead of fully-defined variants. I suggest moving the individual colours to be values of a "color" property instead of being fully-defined variants and using "color=" + colorName as the ModelResourceLocation variant.

I believe so, yes. You may be able to use it now, even before Forge drops Scala support.

Give each launcher profile a separate game directory.

That's not the full log. It doesn't appear to be the FML log, either. The missing signature data error is bad if you're running Minecraft outside of the development environment, but it doesn't crash the game.

Please post the full error or the full FML log. ModelLoaderRegistry.LoaderException is a just wrapper around the actual exception that was thrown by the model loader, which explains why the model failed to load. You're getting one exception for all states because you're mapping all states to the same model.

Your IStateMapper implementation only specifies a model for the default state, but not for any of the other states. It's probably easiest to extend StateMapperBase, this will call StateMapperBase#getModelResourceLocation for each state of the Block. All you need to do is return the same ModelResourceLocation from this method every time, ignoring the FACING property.

That's the crash report, not the FML log. As I said previously, the FML log is the logs/fml-client-latest.log file in the game directory. Did you select the correct Forge version in the launcher profile? Post the full FML log (the actual FML log, not a different log or a crash report) from a session where this happens.

Ah, I forgot that they're different instances rather than states of the same instance. You can still use Forge's blockstates format, you'll just need to create a blockstates file for every colour (or register an IStateMapper to map them to variants of the same blockstates file).

In future, please post the entire FML log. The snippets you posted appear to be from a different log. You appear to be running FML without Forge, but your mod uses at least one class from Forge (and using FML by itself isn't supported). Forge includes FML, so use Forge. You should be able to download a 1.8 version of Forge from the main Files site.

You don't need to create 16 models if you create an empty model and use Forge's blockstates format to specify the "particle" texture for each state.

Scala is likely to be removed at some point in the future, so Forge probably won't be including newer versions of it.

Vanilla hardcodes this for shulker boxes in BlockModelShapes#getTexture, but I think you'll need to create a model without any elements that specifies the "particle" texture and use it instead of registering an IStateMapper to ignore all states.

Post the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin. How exactly did you build you mod?

You can see some examples in my mod's init classes.

Minecraft calls BlockModelShapes#registerBuiltInBlocks for the shulker box Blocks, which means that BlockStateMapper#getBlockstateLocations and BlockStateMapper#getVariants return an empty Set/Map respectively when called with one of the Blocks. You can achieve the same result by implementing IStateMapper#putStateModelLocations to return an empty Map (using Collections.emptyMap) and registering an instance in ModelRegistryEvent using ModelLoader.setCustomStateMapper.

You're checking if the Block is both replaceable and is equal to Blocks.GRASS, which will never be true because Blocks.GRASS isn't replaceable. You can use the && (and) operator to combine multiple boolean expressions (like the conditions of the four if statements) into one. Don't call World#getBiomeForCoordsBody directly, call World#getBiomeForCoords instead. This allows the WorldProvider to return the appropriate Biome (this may or may not call World#getBiomeForCoordsBody). Don't compare to Blocks.AIR directly, use Block#isAir to support modded air-like blocks.

You needed to change the blockstates file and the model, not the registration class. RegUt.registerBlocks and RegUt.regItems are broken since they only register the Blocks/Items on the physical client, but this needs to happen on both physical sides. Model registration must be done in a separate client-only class to avoid crashing the dedicated server. You should be using registry events instead of registering things in preInit. GameRegistry.register is no longer accessible in 1.12, so this will make it easier to update. The log you linked isn't the FML log.

Items load their models from either an item model file (the normal location) or a variant of a blockstates file (the blockstate location). You need to provide at least one model for every item. That's correct. Display transformations are rotation, translation and scale operations applied to the model when it's rendered as an item in various contexts (e.g. left/right hand, GUI, item entity, etc.).

You need to include your mod ID as the domain of the model and texture paths, i.e. "<modid>:<model_name>" and "<modid>:<texture_path>". Textures need to in PNG format, not JPEG. Is the block called fooblock or memeblock? Your files are apparently called fooblock, but the blockstates file uses the memeblock.json model and the model uses the memeblock.png texture. In future, the FML log (logs/fml-client-latest.log in the game directory) will tell you why models/textures failed to load. If you don't know how to interpret the errors, post the full log using Gist or Pastebin when asking for help.

Override Block#getDrops to do the following: Write the TileEntity to NBT. Create the ItemStack that will be dropped. Set the "BlockEntityTag" key of the ItemStack's compound tag to the compound tag containing the TileEntity data. Add the ItemStack to the drops list. The TileEntity is normally removed from the world before Block#getDrops is called, so you need to delay its removal by overriding BlockFlowerPot#removedByPlayer and BlockFlowerPot#harvestBlock. See Forge's patch to BlockFlowerPot for an example of this. When an ItemBlock (or ItemBlockSpecial) is placed by a player and the ItemStack has a compound tag at the "BlockEntityTag" key, it will automatically call TileEntity#readFromNBT with the compound tag (unless TileEntity#onlyOpsCanSetNbt returns true and the player isn't an op).