Hello all,

I've written a couple of methods that use reflection to access private variables from ItemArmor, as their getter methods have been marked as ClientSide only, and don't work on dedicated servers. Line 96: https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java

I'm writing my code using Jetbrains IntellliJ. When I run this code through the IDE, everything behaves as intended. Yet when I build the mod (using gralde build) and run the compiled JAR through a Forge server, I get NoSuchField exceptions thrown. I'm honestly baffled by this.

 

Can anyone help me understand why the two versions are behaving differently?

 

Cross-posted to MinecraftForum: https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/modification-development/2941131-compiled-mod-throws-exception-yet-works-fine-from

More information (OP was pre-coffee):

 

The purpose of this getting of private variables is a workaround for using potion's NBT data in crafting recipes, which is not supported by the JSON format. On item initialisation, the ItemPotionArmor's material, slot and potion name are added to a dictionary, using these concatenated strings as a key, and the instance of the ItemPotionArmor as a value. This dictionary is later used by the ShapedArmorUpgradeRecipe crafting recipe class. Once it has confirmed that the right vanilla items are present in crafting grid, it takes the previously mentioned values from the vanilla armor / potions in the grid, concatenates them together, and retrieves the relevant ItemPotionArmor instance to pass back as a result.

 

The ModItems.getMaterialName is called during item initialisation, in the preInit stage of mod loading. You can see the exceptions being thrown and printed in the server logs at this time. It is also called again when the final item in the recipe is placed in the crafting grid. To test, I've been using standard fire resistance potions and any armor piece.
 

Here's the log from a server run: https://pastebin.com/NyBqL3ZU

I've tweaked the code to also print the stacktrace when this occurs, result: https://pastebin.com/gCziedDe

https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java#L100

This happens because minecraft's code is obfuscated, meaning that the names of the fields in the deobfuscated(dev) version don't match the names in the build version. Use ReflectionHelper/ObfuscationReflectionHelper's methods. You must provide an SRG name of the field/method to those methods(if you are using ReflectionHelper then you must also provide the dev name). You can get the SRG name using mcpbot or you can find it on your pc in your gradle caches.

Unrelated to the issue but still issues with your code:

https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java#L28

• Don't ever use static initializers they can and will cause numerous issues. Instantinate your stuff directly in the appropriate registry event.
• ItemBase is an antipattern, there is already an ItemBase, it's called Item.

https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java#L60

https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java#L146

You can't do this, since the method will be stripped away on the physical server. You might crash with a JVM error as a result because the method referenced in the code is no longer there. If you need to perform a side-specific operation use a proxy.

 

https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java#L103

Don't just catch exceptions, scream that they are there and continue as if nothing happened. If an exception like this occured you should crash the game.

 

https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/proxy/CommonProxy.java

A CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes anywhere else but your proxy.

 

Quote

serverSide = Reference.COMMON_PROXY_CLASS

This makes even less sense. Your common proxy can't be your server proxy. A server proxy either provides NOOP implementations for client-only methods or utilizes code that would crash the physical client. Common code is neither.

 

https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/util/IHasModel.java

IHasModel is stupid. All items need models, no exceptions and nothing about model registration requires access to private/protected data. Register your models directly in the ModelRegistryEvent.

 

 

That'd do it, thanks! I knew the Minecraft was obfuscated, just didn't put two and two together here.

 

As to code quailty, I've not been proud of this code for a while, I know it's got a lot of problems, the most of which being I'm learning how to use Forge through YouTube tutorials, so there's a quite an amount of strange code that I really don't like. Thanks for the feedback, I'll be taking all of these into my code, and reading into the Forge docs to properly understand how to use proxies.

 

The only real rebuttal I want to make is regarding exception handling. I know full well that you shouldn't just throw away exceptions. I've intentionally thrown them away during the dev cycle so I can reproduce and pin them down without having to restart the game every time I hit one. That code would NOT end up in the release.

6 hours ago, Cookiehook said:

That code would NOT end up in the release.

Except then you forget about it & it does, putting something like

if not dev environment crash

might be helpful