Choonster

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.

ITickable#update is called on both the client and server, you need to check if it's being called on the server (i.e. World#isRemote is false) before spawning the items and the lightning bolt.

The post mentions Windows Explorer, not Internet Explorer. It's called File Explorer rather than Windows Explorer in Windows 10 (and possibly other versions).

Are you sure this is only running on the server? It sounds like it's running on the client. Post more of your code.

Read the documentation or look at my example. If you've actually tried to use it and it's not working, post your code and the error message(s).

The ICommandSender will usually be the client player, but this isn't guaranteed. Mods can execute client commands with their own ICommandSender if they want. The Minecraft#player field contains the current client player.

You don't have delete part of the log, you need to delete the mod that the log tells you is installed incorrectly. If you already have the mod JAR downloaded, copy that to your mods directory without extracting it. If you don't have the mod JAR any more, download it again before copying it to the mods directory (again, without extracting it). If you've done this and it's still crashing, run the game again and post the new FML log. Don't hijack other people's threads. I read every thread in this forum and respond when I know the solution, asking for a reply in another thread is just annoying.

Select the directory and press the delete key. Save what?

The section of the log I quoted tells you which directory is an extracted mod, delete this.