Choonster

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.

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