Choonster

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.

That's not a field, that's an NBT key. morality is the name of the field in the moralityScale class. This tutorial code is overly complex and fragile, since it relies on sending class and field names between sides and reflectively assigning the new value to the field. I suggest you delete it and start over. The server is in charge of the game state, so any change to the morality value needs to be done on the server. When the morality value changes, the server can send a packet to the client to update its copy of the morality value. This should be handled in the moralityScale class itself, so the code that interacts with it doesn't need to know the details of how and when the value is synced. The packet should only send the new morality value, you don't need to send a class/field name or determine whether or not the packet is valid.

You didn't post the full crash report, you cut off the actual exception.

Your ModConfig.Handler.onConfigChanged method isn't annotated with @SubscribeEvent, so it's never called and the config file is never saved.

If the field's type is an enum, its config GUI entry should be a button that cycles through the enum's values (GuiConfigEntries.CycleValueEntry).

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.

You specify a GUI factory in your @Mod annotation, so Forge doesn't use the default GUI factory for your mod. The GUI factory that you specify doesn't exist, so a ClassNotFoundException is logged and no GUI factory is registered for your mod. Simply remove the GUI factory from your @Mod annotation and Forge will use the default GUI factory. The ModConfig.Overrides class is never used for the config file/GUI because there's no field of that type in the top-level @Config class (ModConfig). Even if there was, the ModConfig.Overrides.fixedHarvest field wouldn't be used because only the top-level @Config class can have static fields, other classes need to have non-static fields. I highly recommend learning how to use a local Git client rather than using GitHub's web interface. This will let you have finer control over what's in each commit so you can make sure each commit only consists of related changes and has a descriptive message. I personally use GitKraken, but you can also use your IDE's integrated Git client or the git command-line.

As I suspected, you've reversed the group names of your wool and concrete slabs. CONCRETE_SLABS should use "concrete_slab" and WOOL_SLABS should use "wool_slab".