Choonster

That's strange. Please post the latest version of your ModBlocks class. It looks like you added the condition to the breakpoint in the BlockWoolSlab constructor, which is pointless since this will always be an instance of BlockWoolSlab in that context. Please add the condition to the breakpoint in Block#getSoundType instead.

You didn't set a condition for the breakpoint, so it was hit for a BlockStone instance, which uses SoundType.STONE. Set the condition of a breakpoint by doing the following: Show the Breakpoints view (Window > Show View > Other... > Debug > Breakpoints) In the Breakpoints view, right click on the exception breakpoint and select Breakpoint Properties... In the Properties window, check the Conditional checkbox In the large textbox, enter the condition this instanceof BlockWoolSlab Click OK in the Properties window.

I'm not sure why it's not working for you. Please create a Git repository of your mod, push it to a site like GitHub (if you haven't already) and link it here. See my mod and its .gitingore file for an example of the structure to use and which files to include.

Open the Block class, navigate to the getSoundType(IBlockState, World, BlockPos, Entity) method and set a breakpoint in it. If you don't know how to set breakpoints, look at your IDE's documentation or ask your search engine of choice.

Only the top-level @Config class can have static fields, the other classes need to have non-static fields. You need to access the values from the static fields of the top-level class and the non-static fields of the other classes. In your example, this would be ModConfigClass.client.var1 and ModConfigClass.client2.foobar (after you make the ModConfigClass.Client2.foobar field non-static).

You don't need to create your own SoundType instance, you can use the vanilla one stored in the SoundType.CLOTH field (Edit: It looks like you are using the vanilla instance, but still creating your own that you never use). If you put a breakpoint in Block#getSoundType(IBlockState, World, BlockPos, Entity) with the condition this instanceof BlockWoolSlab, run Minecraft in debug mode and trigger one of the block's sounds (e.g. place or break the block), what's the value of the Block#blockSoundType field?

As Animefan8888 said, the method is now called Block#setSoundType. You're trying to call the method with a Material, but it takes a SoundType argument; so your current code obviously won't compile. You need to call it with a SoundType, you can get the vanilla SoundType instances from the static fields of the SoundType class. You're also trying to access the static field Material.CLOTH from an instance of Material, which is misleading since it makes it look like an instance field. Access static fields and methods through the class, not an instance.

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.