Choonster

CommandBase already implements ICommand, there's no need to implement on your class. I told you to implement IClientCommand. You need to override CommandBase#getRequiredPermissionLevel to return the permission level required to execute the command. 0 allows anyone to execute it, higher numbers restrict it more.

RenderingRegistry.registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) must be called before init. It won't do anything if called in init or later.

Change the value of the field and then call ConfigManager.sync to synchronise the fields and the Configuration properties. This will iterate through every field and use ConfigManager.shouldReadFromVar to decide whether the property should be set to the field's value (true) or the field should be set to the property's value (false).

Modding requires a solid understanding of Java and OO programming. Spend some time learning the basics of these and you'll find modding a lot easier.

Edit the first post of a thread to edit the thread's title.

I'm saying that is an error, but your original code (on Pastebin) didn't have that error. You're trying to call the method on the class as if it were a static method, but it's not a static method so you need to call it on an instance of the class instead. In 1.8, ClientTickEvent (as with all events in net.minecraftforge.fml packages) is fired on the FML event bus (FMLCommonHandler#bus), not the Forge event bus (MinecraftForge.EVENT_BUS). You need to register your event handler on the FML event bus to handle ClientTickEvent. In 1.8.9+, the FML event bus has been merged into the Forge event bus, so all events that were previously fired on the FML event bus are now fired on the Forge event bus instead and the FMLCommonHandler#bus method has been deprecated. Each subclass of TickEvent (including ClientTickEvent) is fired twice per tick of its corresponding system (server, client, world, player or render), once at the beginning with Phase.START and once at the end with Phase.END. If you don't check for a specific Phase, your code will run twice per tick instead of once.

Your code was already calling the method correctly. I use Class#member to refer to instance (non-static) fields and methods. I use Class.member to refer to static fields and methods. EntityPlayerSP#sendChatMessage is an instance method, it needs to be called on an instance of EntityPlayerSP (i.e. Minecraft#hePlayer). This is a basic Java concept.

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?