Choonster

You need to register models for your Items (including ItemBlocks) using ModelLoader.setCustomModelResourceLocation (for metadata-based models) or ModelLoader.setCustomMeshDefinition (for arbitrary ItemStack to model mappings) in ModelRegistryEvent. This needs to be done in a client-only class. If you use @Mod.EventBusSubscriber, pass Side.CLIENT to the annotation to prevent the class from being loaded on the physical server.

Hover over the "i" icon next to a download in the "All Versions" list and click "Direct Download" to bypass AdFocus.

You need to assign the return value of MathHelper.clamp to the morality field. You can pass the result of the addition/subtraction directly to MathHelper.clamp.

You need to use minecraft:book, not minecraft:enchanted_book for the enchant_randomly function.

Was there a particular part you didn't understand? I tried to explain it step-by-step. The enum looks correct, but you need to create a field that uses it and annotate that field with @Config.Name/@Config.Comment rather than annotating the enum. The field is what Forge uses as the basis of the config property. You should also use PascalCase for enum, class and interface names, not camelCase.

Forge requires that each loot pool in mod loot tables specifies a "name" property with a name that's unique to the loot table. This is so that mods can modify/remove loot pools in LootTableLoadEvent.

Have you tried to follow the instructions in my previous post? Create an enum with the values NONE, SHRINK, DOWN and ALPHA and use this as the field's type.

No, you need to add/subtract points to/from morality without changing the morality field (i.e. use +/- rather than +=/-=) and then assign the return value of MathHelper.clamp to the morality field. Currently you're adding/subtracting and then completely ignoring the clamped value. You should also use the existing max fields for the second and third arguments rather than using their values. A bit of both. Two Random objects with the same seed will always produce the same sequence of random numbers when the same methods are called on them. The Random() constructor does use a unique seed each time you call it, so each of your Random objects should have a different seed and produce different random numbers.

I think the OP is talking about attack damage, not durability. If you create your own ToolMaterial with EnumHelper.addToolMaterial, you can specify its attack damage. ItemSword adds 3.0 to this and uses it as the attack damage AttributeModifier.

As I said, you need to call it with reflection. This is because it's package-private rather than public. I use the Class#member notation to refer to the non-static field or method member in Class. I use Class.member to refer to static fields and methods. You can use ReflectionHelper.findMethod to get a Method object referring to a method and then use Method#invoke to call the method. The first argument is the object to call it on (use null for static methods) and the vararg is the arguments to pass to the method. If you were calling this method more than once, you'd want to store the Method object in a private static final field so you only do the expensive lookup once. The same applies to reflecting fields and Field objects. You need to do this in your client proxy (or another client-only class called from it), not just mark the preInit method in your @Mod class as @SideOnly. If your mod is client-only, it's probably safe to do this in your @Mod class. You could suggest this in the Suggestions section or on GitHub. Side note: The @Mod.Instance annotation is meant to be applied to the field that will store the instance of your @Mod class, not the field storing your mod ID. Why are you using fully-qualified names for the @Mod annotation?

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