Leaderboard

When FML sends an IMessage over the network, it includes the discriminator byte you specified for the class in SimpleNetworkWrapper#registerMessage so it knows which class to instantiate on the receiving side. If you don't register an IMessage class, it defaults to 0 and instantiates whatever class you registered for discriminator 0. Since the class instantiated on the receiving side is different to the one that was sent, the byte buffer won't contain the data it was expecting and an exception will be thrown (if it tries to read more data than was written) or it will silently corrupt the data as it reads it from the byte buffer (if it tries to read less than or equal to the amount that was written).

I don't suppose anyone knows of any good tutorials on how to build a config gui in Forge? You know, when you go into the main menu, click on mods, scroll down to yours and click on Config button. One that's preferably in english? It'd be nice if Forge put out a template for those.

If you extend RenderBiped, it automatically adds LayerHeldItem (which renders the entity's held items) for you. If you extend RenderLiving, you need to add it yourself.

In the moralityScale class, yes. Don't add the player as an argument to any of the functions, the moralityScale already knows which player it's attached to (the one stored in the field). Again, you don't need these arguments because the moralityScale already knows its current morality value and which player it's attached to. Data persistence and networking are completely separate. Only the server persists the game state (i.e. writes your capability to NBT and writes the NBT to the disk), the client doesn't need to persist anything. This is correct, just have the packet set the morality value directly; it doesn't need to do anything NBT-related. Side note: I recommend following Java naming conventions by using PascalCase for class, enum and interface names and camelCase for field, parameter, local variable and method names.

GameRegistry.addRecipe(...).

I don't know exactly - I think it's something to do with the way they are written to/from bytes which is kind of linear, so if things get offset by one packet not being registered right then the problem appears to come from somewhere else. The reason I recognised it in this case is just because I've had this crash a couple of times and tracked it down to unregistered packets!

It looks like you haven't registered your QuizStartingMessage, that may be the problem.

moralityScale should have an EntityPlayer field holding the player it's attached to. Create a method in IMorality called something like synchronise and implement it in moralityScale to check that it's being called on the server (i.e. World#isRemote is false for the player's World) before sending a packet to the player with the current morality value. In moralityScale#addSin, moralityScale#addVirtue and moralityScale#set (i.e. the methods that change the morality value), call the synchronise method after changing the morality value to sync the change to the client. Byte buffers are for sending data between the client and server using packets. NBT is for storing data that will be saved to the disk. You very rarely send NBT between the client and server and should never need to use byte buffers for saving data to the disk.

It looks like the server-side Container has more Slots than the client-side Container. Are you sure your GUIs are using the right Containers?

Is this a client-to-server or a server-to-client packet? Why does the packet send an int (FetchMoralityPacket#toSend) if the handler ignores it? Any string that you display to the user should be localised. Include a format placeholder (e.g. %d for an integer) in the translation and you can create a TextComponentTranslation with the translation key and the format argument instead of concatenating the text and the amount in a TextComponentString. If the handler is a nested class of the packet, you don't need to include the packet's action (FetchMorality) in its name; since it's implied by being a nested class. This is just my code style, it's not required that you follow it. Apart from these issues, it looks correct.

Is this one of your blocks, meaning can you edit the class? If that is the case, you can override Block#onEntityCollidedWithBlock

Forge's documentation explains that here.

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