Choonster

If you ever built your mod with the build Gradle task, you may have a source JAR in the build/libs directory of your mod's workspace. This will contain your source code obfuscated to SRG names. BON2 can deobfuscate a compiled JAR from SRG (obfuscated) to MCP (deobfuscated) names, but probably not a source JAR. You can then decompile it with a decompiler like Bytecode Viewer. The decompilation process isn't perfect and all comments are stripped during compilation, so the code you get out of it won't be exactly the same as the original code. If you use version control software like Git and host a copy of your repository on a site like GitHub, you can retrieve any version of your code. This will make it much less likely that you'll lose anything.

Set a breakpoint in the lambda with the condition p_194039_2_ == null. When the breakpoint is hit, look at the value of the element parameter to see which Item has a null registry name.

The PR has been merged, update to Forge 1.12-14.21.0.2342.

A Forge client should be able to connect to a vanilla server as long as none of the installed mods are required on the server side. You shouldn't need to do anything special to connect to a Realms server.

I've created a Pull Request to fix this crash here. If the PR is merged, this particular error will be logged like other syntax errors instead of crashing the game.

Any field 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.

Registry events are fired before preInit, so you need to annotate the event handler class with @Mod.EventBusSubscriber to automatically register it at mod construction time (or register it manually). In addition to this, you're registering an instance of the event handler but your methods are static; which is incorrect. Static event handler methods require you to register the Class object rather than an instance, as explained in the documentation. You need to set the registry name of an IForgeRegistryEntry like Block or Item before you register it. Having a constructor modify static fields in a class where there there are no instance fields or methods and calling this constructor purely for the side-effects is very strange and probably a bad idea. If you need to do more stuff to the Items in preInit, create a regular static method instead of a constructor. ModelLoader is a client-only class and can't be referenced from common code. ModelRegistryEvent should be handled in a client-only class that's only registered with the event bus on the physical client (pass Side.CLIENT to the @Mod.EventBusSubscriber annotation or manually register it in a method only called on the physical client).

It's not absolutely required, but it's a good idea to avoid potential conflicts. All unlocalised names are used as keys in the same Map, so your unlocalised name's translation could overwrite or be overwritten by the same name from another mod. I recommend using the Item's registry name (IForgeRegistryEntry#getRegistryName) as the unlocalised name as it already includes the mod ID.

You need add the dependency repositories used by CoFH to your build.gradle file manually, JitPack doesn't seem to handle that automatically. Basically, copy the repositories from the repositories section of CoFHCore's build.gradle file into the repositories section of your build.gradle file. Use the repositories sections in the main body, not in the buildscript section. I also had to add the universal classifier to the CoFHCore dependency, e.g. deobfCompile 'com.github.CoFH:CoFHCore:f60b7b70fe:universal'.

One of your mods has added an invalid recipe via JSON. Unfortunately the crash report doesn't say which one, so you'll need to remove mods until it stops crashing to figure out which one it is.

Rename it to something other than .gradle (or move it to a different directory) so Gradle doesn't use the cached files stored in it. You can rename a folder to a name starting with a period from the command line with the rename command (in Command Prompt) or the Rename-Item cmdlet (in PowerShell).

Item#onArmorTick being called in the wrong place is a known issue. I'm not sure why the patches would fail to apply like that. It's possible that something in the Gradle cache is corrupted, you can try temporarily renaming the ~/.gradle directory (%USERPROFILE%\.gradle on Windows) and re-running the setupDecompWorkspace task.

You can also use CurseForge as a Maven repository, see the documentation. I explain this in more detail here.

This is a known issue. There's a Pull Request open to fix this, but it hasn't been merged yet.

Either use a wildcard in the parameter declaration or give the method a generic type argument and use that in the parameter declaration.

func_187246_z is loadPlayerBanList, which is the method responsible for loading the list of banned players from banned-players.json. This error was thrown because that file has a syntax error in it. Either fix the syntax error or delete the file and re-ban any banned players.

Are you subscribing to RenderLivingEvent.Specials.Pre<AbstractClientPlayer> directly, or are you subscribing to RenderLivingEvent.Specials.Pre and checking if the entity is an instance of AbstractClientPlayer? Only the latter will work in this case. Forge only performs generic filtering for events that implement IGenericEvent, which RenderLivingEvent.Specials.Pre doesn't. It's too expensive to do multiple times every frame, so it's generally only done for load-time events. Render#doRender (which is called by every class that overrides it) calls Render#renderName. RenderLivingBase overrides Render#renderName to fire RenderLivingEvent.Specials.Pre/Post and call Render#renderEntityName with the entity's display name. Render#renderEntityName calls Render#renderLivingLabel to render its argument. RenderPlayer overrides Render#renderEntityName to render the player's score with Render#renderLivingLabel and then call the super method.

A better example of saving data in the ItemStack when the block is broken is Forge's patches to BlockFlowerPot. This delays the removal of the TileEntity until after Block#getDrops is called, allowing you to access it there and store the data.

That should be the method to override. Have you actually replaced the vanilla RenderPlayer instances with your own? A better way to do this would be to subscribe to RenderLivingEvent.Specials.Pre, which is fired just before a living entity's nametag is rendered. You can cancel this to prevent the nametag from being rendered.

The unlocalised name has nothing to do with models, it's only used for localisation. The registry name is what determines the default blockstates file/item model location. I have an explanation of the model loading process and where models are loaded from here.

That output doesn't appear to match your code. Where did the "false" message come from? What did the first System.err.println call output? It appears that chunkPollution is indeed null. Is the ChunkEvent.Load handler definitely being called? Was it called for the chunk that produces this error?

If the goal is to have a separate blockstates file for each value of a property, you can do that by creating an IStateMapper using StateMap.Builder and registering it with ModelLoader.setCustomStateMapper.

It sounds like Eclipse is showing you NullPointerExceptions being thrown in external code that it doesn't have source code for. Restrict the breakpoint to your message handler class 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, select Filtering in the left column and then click Add Class... Type in the name of your message handler class, select it in the search results and click OK. Click OK in the Properties window.

You shouldn't need to set the class/line or add any null checks, the breakpoint will be hit as soon as something throws a NullPointerException. Once your code throws the exception and hits the breakpoint, look at the debugger to see what's null.

Look at the documentation or use your search engine of choice. If it's anything like IDEA, the Debug window should have a button that shows all breakpoints. Clicking this will bring up a window that also allows you to create new breakpoints.