Choonster

Why not?

When the server-to-client packet is received by the client, you can access the current GUI from the Minecraft#currentScreen field. If it's an instance of your GUI class, you can update it with the data from the packet.

Forge's documentation explains that here.

It looks like ModItems.goldshotbow was null when ModelRegistryEvent was fired, which likely means that no Item was registered for the name unnamedmod:goldshotbow at that time (either because it's the wrong name or the Item was registered later). Where are you registering these Items?

Forge's documentation has an explanation of registry events here.

You need to tell the method which registry contains the registry entry you're trying to read. In this case, it's the SoundEvent registry (ForgeRegistries.SOUND_EVENTS). That said, Minecraft already has methods to play a sound from the logical server. Forge's documentation lists the methods and explains what each one does here.

Blocks are singletons, there's only one instance per block type. This means that a Block can't have a single IBlockState, BlockPos or World field, since a Block can have any number of valid states at any number of positions in any number of dimensions. Instead, any method that needs access to the these receives them as parameters.

Just send another packet. The return value of IMessageHandler#onMessage is largely useless now that packets are handled on a network thread and all the logic needs to be run on the main thread.

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.