Choonster

Just add it to the constructor.

PlayerUseItemEvent was renamed to LivingEntityUseItemEvent in 1.9 to reflect the fact that any EntityLivingBase can now use items, not just players. Keep in mind that this is only for items that are continuously used like drawing a bow or blocking with a shield.

Automatic config GUIs for the annotation-based config system were added in Forge 1.11.2-13.20.0.2262 (commit 25497d3). If you're using an older version, update to get the automatic config GUI.

Forge does automatically create a config GUI for you if you're using the annotation-based config system and Forge 1.11.2-13.20.0.2262 (commit 25497d3) or later. You're using Forge 1.11.2-13.20.0.2228, so you need to update to get the automatic config GUI.

Packets haven't really changed in recent versions, so anything that worked in 1.8.x/1.9.x should still work in 1.11.2 or 1.12. You can't safely reference the Minecraft class in an IMessageHandler#onMessage method that will be called on both sides, you need to move the code to get an IThreadListener to your proxies (like this, this and this). That seems like a lot bolilerplate code for not a lot of gain. If you look at my mod's packets, you'll see that the first line of every packet handler uses the proxy methods to get the IThreadListener and schedule a lambda implementation of Runnable. This seems simpler than wrapping SimpleNetworkWrapper and IMessageHandler.

No, there shouldn't be any issues regardless of what data you need to sync. A single integer should make things very simple, though.

Did you read this part? This isn't the error, it's always printed to the log when the game starts up. In newer versions of Forge, it's been modified to print the specs without printing a crash report (reducing the potential for this sort of confusion). If it's crashing (and disabling the loading screen doesn't fix it), post the full FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin.

IThreadListener#addScheduledTask is intended to be called from a background thread (usually a Netty thread) to schedule a task to run on the main thread next tick. When called from the main thread, it executes the task immediately. You're not actually starting a new thread, you're just calling the LandGenerator#run method on the main thread. As diesieben07 said, you can't safely interact with the world from a separate thread. Side note: You can't compare Strings with the == operator, use the Object#equals method.

I don't know much about rendering, but it looks like RenderGlobal#renderStars is used to render the stars into a VBO/display list at startup and when the renderers are reloaded (e.g. when resources are reloaded or a new save is loaded). The VBO/display list is then rendered in RenderGlobal#renderSky(float, int).

The logging of missing models was broken in Forge 1.12-14.21.0.2363 (commit dc043ac) and fixed in Forge 1.12-14.21.1.2390 (commit ede05a2). Update Forge and run Minecraft again to see the model errors. In future, please post the full FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin.

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.