Choonster

Post the FML log, the models/blockstates files and your model registration code. Are you getting the missing model (a black and pink checkered cube with the model location overlayed on it that appears in the middle of the screen when held) or the actual model with the missing texture (a black and pink checkered pattern).

ForgeRegistry#getEntries returns an immutable copy of the registry's entries, so you can't use it to modify the registry. As I said earlier in the thread, use IForgeRegistryModifiable#remove.

That looks mostly correct, but I highly recommend moving the synchronisation to MoralityScale itself (like I described in this post) so the code that uses it gets the synchronisation automatically. This avoids repeating the synchronisation code in every place you change the morality value and prevents inconsistencies between places that change the value, e.g. forgetting to send the packet or sending the wrong packet. Your addVirtue/addSin methods attempt to clamp the morality value between the maximum virtue and sin values but you only do this when the morality is already at the maximum, which means that any argument greater than or equal to 2 could push it over the maximum ((max - 1) + 2 = max + 1 ). I recommend using MathHelper.clamp(int, int, int) to clamp morality +/- points between the maximum virtue and sin values. Don't create a new Random each time you need a random number, create one instance and store it. You're still using hardcoded chat messages rather than specifying them in the lang files. You should only send chat messages on one side (usually the server) to avoid sending the message twice. I'm glad you've learned from this.

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.

I'm not a moderator. Reality Controller is a title based on the number of posts I've made and Forge Modder was an opt-in group for mod developers before the site revamp (I'm not sure if it's still possible to opt-in).

Don't include the .png extension in your model texture paths, Minecraft adds it automatically. If you've already fixed that in your models but Minecraft is still using an older version of them, rebuild your project to make sure everything is up-to-date.

I explained in detail how to upload the FML log to Gist here, you should be able to adapt these instructions to your situation. If you're using Gist, you can upload multiple files in a single gist.

I'm not good at diagnosing problems without information. Uploading files to Gist/Pastebin is a very simple process, you shouldn't need to be good at it.

Yes, every model that uses non-vanilla textures specifies the testmod3 resource domain for them.

You could use an Access Transformer, but I'm not sure how much documentation there is on them.

Don't create a new Random every time, create one and store it. Item#itemRand already contains a Random instance that you can use. You need to generate the random number in your override of Item#getContainerItem(ItemStack).

Wherever you specify the textures, in the model or the blockstates file.

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).

Minecraft is trying to load your textures from the minecraft resource domain, where they don't exist. You need to specify your mod's resource domain, i.e. use "<modid>:<texture_path>" rather than just "<texture_path>".

The only one of these constructors added by Forge is ItemAxe(ToolMaterial, float, float), which uses the same access level as the vanilla ItemAxe(ToolMaterial) constructor. All of the others are vanilla constructors whose access levels aren't changed by Forge.

No, ConfigManager creates and stores the Configuration instance for each @Config class. You get the Property from the Configuration (via the ConfigCategory) and call Property#setConfigEntryClass with NumberSliderEntry.class.

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.

Post your code, any relevant JSON files and the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin.

It looks like you'll need to use reflection to call ConfigManager.getConfiguration with the mod ID and name you specified in your @Config annotation, this will return your mod's Configuration instance. You can then use Configuration#getCategory to get the ConfigCategory (you can specify a full path by separating each category name with periods . ) and ConfigCategory#get(String) to get the Property. You'll want to do this on the physical client (e.g. in your client proxy) in preInit.

PopulateChunkEvent.Populate is fired for specific features and I guess nobody ever requested the addition of The End's 1.9 features. If you create an issue or PR on GitHub, the missing features may be added to the event.

It looks like Forge only fires PopulateChunkEvent.Populate in ChunkGeneratorOverworld and ChunkGeneratorHell, but it fires PopulateChunkEvent.Pre/Post in these classes as well as in ChunkGeneratorEnd and ChunkGeneratorFlat.

You can get a Cycle Value String control by using an enum field. To get a Slider control, you'll need to get the Property from the Configuration instance Forge created for your @Config class and call Property#setConfigEntryClass with NumberSliderEntry.class.

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.

Something was null on line 63 of EntityBrianade, most likely the return of RayTraceResult#getBlockPos. RayTraceResult#getBlockPos will only return a non-null value when RayTraceResult#typeOfHit is RayTraceResult.Type.BLOCK (i.e. the raytrace hit a block). Calling Object#getClass on a BlockPos will never return a Class that's equal to BlockAir.class, the two are incompatible types. Use World#getBlockState to get the IBlockState at the specified BlockPos, then use IBlockSate#getBlock to get the Block and Block#isAir to check if the block is air.