Choonster

Each field in the @Config class is mapped to either a configuration category or a configuration property depending on its type. If it's a type that implements Map, a category is created and a property is created in that category for each key-value pair in the Map. The Map must have String keys and primitive, primitive array, String or enum values. If it's a type that directly extends Object, a category is created and a sub-category or property is created in that category for each field of the class following the same rules as the @Config class. These classes can be declared anywhere, they don't have be nested in the @Config class. If it's a primitive, primitive array, enum or String, a property is created. If it's any other type, an error is thrown.

The classes could be declared anywhere, it's the fields that use those classes that are mapped to categories.

I thought you were saying that something in the new Forge version broke JourneyMap. I didn't realise that the author didn't want to update the mod to fix a bug in their own code. There's usually a few months between Recommended Builds, so you'll probably have to convince the JourneyMap author to release the bugfix.

Each category will be given its own page. Any field of the @Config class whose type is a class that directly extends Object will become a config category, with its fields becoming properties or categories following the same rules as the top-level class. Map fields are also mapped to categories with properties as key-value pairs.

You'll need to synchronise the value from the server to the client with a custom packet, yes. If the capability is attached to a player, do this when the player logs in (PlayerEvent.PlayerLoggedInEvent) and when the value changes.

JourneyMap works just fine on newer versions of Forge (I just tested it on 1.12-14.21.1.2406), like most mods do. Just use the latest version of Forge.

What type is the variable holding the entity you're trying to modify the tasks of? Since tasks is a field of EntityLiving, you can't reference it on a variable of type Entity or EntityLivingBase.

The .gradle/gradle.log file in your mod's root directory should contain the output from the latest Gradle run.

If you use the annotation-based config system, a config GUI will automatically be created for your mod. All you need to do is subscribe to ConfigChangedEvent.OnConfigChangedEvent, check if the event's mod ID is your mod ID and then call ConfigManager.sync to synchronise the changes made to the Configuration object (by the GUI) back to the fields of your @Config class. You can see an example of this here.

When are you calling these methods? They should both be called in preInit. Instead of using new ResourceLocation("<modid>" + "<texture_path>"), use new ResourceLocation("<modid>" + ":" + "<texture_path>") or new ResourceLocation("<modid>", "<texture_path>").

If Cards are in a Forge registry, you won't be able to reference them from your Item constructors. I'm not sure how your code is currently set up, but I recommend using a single Item that stores the Card in the ItemStack's NBT (as the registry name) or capabilities (as a reference to the Card instance). This way you'll have a single Item instance that can be any card type and you won't be referencing the Card instances in your Item constructors. If cards need custom behaviours in item form, create methods in Card matching the Item methods you need and override the Item methods to call the corresponding Card methods.

You need to call IModel#process with a map containing the key-value pair "flip-v" = "true" to tell the model to flip-v. This is what Forge's blockstates format does when you specify custom data.

IForgeRegistryEntry.Impl is a generic type, you need to specify the type argument. In this case, use Card as the type argument (since that's the super type of the registry).

The name of the registry should be something like <modid>:cards, not <modid>:textures/cards. It's a unique name for the registry, not a texture path. The default key of the registry is the registry name of the default value. This is optional, the Block registry uses minecraft:air (the registry name of Blocks.AIR) and the PotionType registry uses minecraft:empty (the registry name of PotionTypes.EMPTY); but the other vanilla registries don't specify a default key. You need to implement IForgeRegistryEntry on Card, the super type of the registry. Do this by extending IForgeRegistryEntry.Impl. Delete the CardRegistry class. You should create a class like ForgeRegistries to store the IForgeRegistry<Card> instance (the Card registry), using GameRegistry.findRegistry to initialise the field. Make sure you only reference this class after RegistryEvent.NewRegistry is fired (e.g. in your RegistryEvent.Register<Card> handler). You need to register your Card instances in RegistryEvent.Register<Card>.

It looks like the RenderManager instance was null when you created the RenderChimera instance, probably because you did this too early. RenderingRegistry.registerEntityRenderingHandler(Class<? extends Entity>, Render<? extends Entity>) is deprecated, use RenderingRegistry.registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit instead. The IRenderFactory#createRenderFor method will be called with the RenderManager instance and needs to create and return your Render instance. You can use a lambda or constructor method reference to implement IRenderFactory. RenderLiving is a generic type, you need to specify the type argument. Always annotate override methods with @Override so you get a compilation error if they don't actually override a super method. You should use your IDE to auto-generate override methods with the correct signature and annotation. You're creating a ResourceLocation with minecraft as the domain and your mod ID and texture path as the path, which is incorrect. Either use the ResourceLocation(String, String) constructor or separate the domain and path with a colon.

Are your Card objects singletons? Do they have some sort of unique identifier (e.g. a numeric or textual ID)? If they do, write this to the buffer in toBytes then read it from the buffer in fromBytes and use it look up the Card object in the master list/registry. Yes, see the documentation on registries. If you use a Forge registry, the ByteBufUtils methods I mentioned in my previous post handle reading/writing the ID and looking it up in the registry.

The log cuts off abruptly without an error, so it doesn't look like the game crashed. Did you get a popup on the launcher saying "An unexpected issue occurred and the game has crashed. We're sorry for the inconvenience."? Did Minecraft freeze and a Windows popup saying "Minecraft has stopped responding" appear? Was there a crash report created in the crash-reports directory (in the game directory)? If so, post it using Gist.

Post the full output from Gradle.

@Mod.EventBusSubscriber will register the Class object with the Forge event bus, which means that any static @SubscribeEvent methods will be registered. Registering an instance of the class with the Forge event bus will register any non-static @SubscribeEvent methods. I suspect your ModelRegistryEvent handler method wasn't static, so it wasn't being registered by @Mod.EventBusSubscriber. Forge's documentation explains events in more detail here.

As the GUI says, one of your mods (Botania) requires Baubles but you don't have it installed.

Yes, just create a launcher profile for each version and give each profile a separate game directory. Keep in mind that 1.7.10 isn't supported here, you won't get any help with it if things break.

That doesn't appear to be the full log, it just cuts off without an error. If you open the log in Notepad, is there any more to it than what you've uploaded?

Don't create a new packet in the handler, use the data from the one you receive as an argument to perform the desired action. Don't write objects directly to bytes, write the identifier (if it's a singleton) or the individual primitive/string values (if it's not). If you use the Forge registry system for your Card class, you can use ByteBufUtils.readRegistryEntries and ByteBufUtils.writeRegistryEntries to read/write a collection of Cards to/from the byte buffer. You never assign a value to the cardOP field and even if you did, you can't iterate through it in fromBytes. When a packet is received, it's constructed with the no-argument constructor (which your class is missing) and fromBytes is called to read data from the byte buffer and store it in the appropriate fields. The handler then uses the data from these fields. The REQ type argument is pointless.

Don't use ItemModelMesher#register to register models, use ModelLoader.setCustomModelResourceLocation/setCustomMeshDefinition in ModelRegistryEvent. Models need to be registered in a client-only class. I use this method to register models for each SlabGroup's item. This is set up so that the item uses the models specified in the blockstates file. To be clear, my mod is meant to be an example rather than a tutorial. You need to read through the code and understand how it works, I don't explain it step-by-step (though I do try to document what most methods and classes do).

No, just change the Forge version in build.gradle and re-run the setupDecompWorkspace task.