Choonster

There is no net.minecraft.player package (or rather there's no classes in it to import), only net.minecraft.player.inventory.

That will work because the method checks if name is either null or empty, though Forge never calls it with null as the name argument (like I said in my previous post, the default value is the empty string). Method#invoke returns whatever the method returned. In this case it's the Configuration object, so store it in a local variable.

It's a local variable rather than a field, so it can't be private or static. It can be final to prevent its value from being changed, but this isn't required. If you were calling an instance method of ConfigManager (and ConfigManager actually had any instance methods), you'd pass an instance of ConfigManager as the obj argument. Since the method you're calling is static, just pass null. The two parameters of ConfigManager.getConfiguration are modid and name, which should match the values you specified in the @Config annotation. Use an empty string for name if you didn't specify it in the annotation, since that's the annotation property's default value.

If you want to call a method multiple times, you should look up the Method object once and store it in a private static final field; yes. You then call Method#invoke on it when you want to call the method (which is usually at a different time to when the field is initialised, i.e. in a method rather than a field initialiser). I've just realised that ConfigManager.getConfiguration only needs to be called once, so there's no need to store the Method object in a field. I forgot about this in my earlier posts. When I say "call Class#method", I mean "call the method named method on an instance of Class". In this case, call the invoke method on the Method object.

NumberSliderEntry isn't involved here. You want to access the getConfiguration method in the ConfigManager class, so use ConfigManager.class as the clazz argument and "getConfiguration" as the methodName argument. The method doesn't have an obfuscated name (since it's not added by vanilla), so use null as the methodObfName argument. The method takes has two String parameters, so use String.class, String.class as the parameterTypes argument.

I just added two more enum properties to my mod, both of which are in a subcategory/nested class rather than the top-level category/class. One uses an enum defined in the top-level class, the other uses an enum defined in the nested class. Both save without issue.

I then explained how to call it with reflection in more detail here: When you use reflection to call a method, you don't call it directly like you would normally. You need to get the Method object for the method and then use that to call it.

I've told you which methods you need to call, was there a particular part of my instructions that you didn't understand? Class.forName requires the fully qualified name of the class, e.g. "java.lang.Thread" rather than just "Thread". You only need to call Class.forName to get a Class object for a class that isn't known at compile-time. If you do know the class at compile-time, use a class literal instead.

I just added an enum config property to my mod and it saves without issue. I'm not sure why it's not working for you.

No, World Capabilities are implemented as a wrapper around World Saved Data but are nicer to work with.

Yes, I do my model registration in the ModModelManager class. There are a lot of methods in there that register models, but they all boil down to one or more calls to the two ModelLoader methods.

Use reflection to call ConfigManager.getConfiguration with the mod ID and name specified in the @Config annotation and get the Configuration instance: Call Configuration#getCategory with the full path of the property's category (separating each category name with periods) to get the ConfigCategory. Call ConfigCategory#get(String) with the property's name to get the Property. @Mod.EventHandler methods are only called if they're in your @Mod class, annotating methods in other classes won't do anything. GUIs only exist on the physical client, so you can't reference GuiConfigEntries.NumberSliderEntry in a method that would be called on the physical server. If your entire mod is client-only, you don't really need to worry about this since none of your methods will be called on the physical server.

Essentially, yes. The "temp" int doesn't need to be a variable, you can just pass it directly to MathHelper.clamp.

Use Gist to post large text files like the FML log.

Post the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin. This will tell us why and where it's crashing.

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?