Fountry crashes when trying to make mod gear.

[The-Arcanian]

When trying to make Thaumcraft tools and armor or Immersive Engineering armor the foundry will cause a null pointer error.

Minecraft 1.12.2 Forge 14.23.4.2739 ExpandedIndustry 6.0.0a Thaumcraft 1.12.2-6.1.BETA23 Immersive Engineering 0.12-85

All crashes have the same server log, which is as follows:

Click to Expand

java.lang.NullPointerException at com.draco18s.industry.entities.TileEntityFoundry.castItem(TileEntityFoundry.java:166) at com.draco18s.industry.entities.TileEntityFoundry.update(TileEntityFoundry.java:69) at net.minecraft.world.World.redirect$tileEntityUpdate$zbb000(World.java:4128) at net.minecraft.world.World.updateEntities(World.java:1832) at net.minecraft.world.WorldServer.updateEntities(WorldServer.java:613) at net.minecraft.server.MinecraftServer.updateTimeLightAndEntities(MinecraftServer.java:767) at net.minecraft.server.MinecraftServer.tick(MinecraftServer.java:668) at net.minecraft.server.integrated.IntegratedServer.tick(IntegratedServer.java:185) at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:526) at java.lang.Thread.run(Unknown Source)

---

While Thaumcraft crashes also have a client log:

Click to Expand

java.lang.NullPointerException at com.draco18s.industry.entities.TileEntityFoundry.castItem(TileEntityFoundry.java:166) at com.draco18s.industry.entities.TileEntityFoundry.update(TileEntityFoundry.java:69) at net.minecraft.world.World.redirect$tileEntityUpdate$zbb000(World.java:4128) at net.minecraft.world.World.updateEntities(World.java:1832) at net.minecraft.client.Minecraft.runTick(Minecraft.java:1845) at net.minecraft.client.Minecraft.runGameLoop(Minecraft.java:1096) at net.minecraft.client.Minecraft.run(Minecraft.java:3938) at net.minecraft.client.main.Main.main(SourceFile:123) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) at net.minecraft.launchwrapper.Launch.main(Launch.java:28) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:196) at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:231) at org.multimc.EntryPoint.listen(EntryPoint.java:143) at org.multimc.EntryPoint.main(EntryPoint.java:34)

---

(On a side note, IE's treated sticks are not recognized so that steel tools can be made, I am guessing this would also hold true for Botania's sticks for its tools.)

[Draco18s]

Hum. Interesting crash. Definitely my fault for not null-checking the results of a method I marked as nullable.

(On a side note, IE's treated sticks are not recognized so that steel tools can be made, I am guessing this would also hold true for Botania's sticks for its tools.)

If they're ore dict registered as "stick" it should work. Should being the operative word here. I never looked into checking what mods had them registered and if they worked just fine. Mostly because I don't see how the code I'm using would fail if the item is registered as a "stick"

[The-Arcanian]

Would the null checking allow for the recipes to start working, or would they just not be craftable? On a side note, are the recipes detected from normal crafting table recipes (it looked like they were), if that is the case my idea of make the foundry the only way to make metal tools by crafttweeking the normal recipes out will not work... Maybe if recipes could also be added via crafttweeker...

And no, IE's and Botania's sticks are not oredict. They are harder to get than normal sticks as part of the gating for those tools.

[Draco18s]

Null check would mean that nothing would happen (instead of crashing). Still need to figure out why it returns null (I would need more information).

Essentially what the foundry does is it gets a mold and the mold has a given recipe squished into it. The foundry says "ok, I need a recipe that has this exact layout, except instead of iron ingots, I need one with [the ingots I have]."

[The-Arcanian]

Ok, your foundry code has a foundational error. It will crash even if using gold. So molds can only be made using iron items, and the foundry can only make iron items.

From your code, it looks like you are attempting to look up the recipe for the iron variant of what the mold is for then try to craft the same pattern but with the ingredients from the input slots.

I don't know exactly what is going wrong, but I can think of 2 alternative methods.

1. Instead of trying to look up the recipe at the time of foundry crafting, look up and cache the crafting pattern in the mold. But this would probably fail if someone wanted to do what I was thinking of and remove the normal recipes.
2. Sidestep vanilla crafting entirely. Either hardcode and/or dynamically detect the association between ingots and their gear. Most gear follows the rule of having the first word match the ingot and then the second word being the type of gear (Iron Ingot, Iron Pickaxe, Iron Chestplate, ect.). Exceptions can be handled with hardcoding, or by adding crafttweeker support so pack makers could do it themselves.

[Draco18s]

So, I'll grant that the code's changed from when I originally wrote the code, but that's not how it works. What it's supposed to do is compare each ingredient (each grid cell of the recipe) between the template recipe (what the mold says) and the recipe-to-test-against and the two either need to match or the to-test needs to accept the input material (e.g. gold).

Now, in poking around with things, yes, it's broken. Working on patching that up.

1) This won't work, as if you imprint the mold with an iron tool and then try to cast it in gold, the foundry needs to dynamically look up the gold result!

2) Doesn't work. Bucket, shears, and rails don't respect that rule. It also (necessarily) wouldn't work for any mod-added items; e.g. "Heavy ____" that uses the same recipe shape, but uses Steel ingot instead of iron. The output name doesn't match the input name.

[The-Arcanian]

Maybe I was not clear, but what I meant was that it looks like it attempts to craft an item in the same pattern as the mold. But instead of, say, Iron ingots to make an Iron Chestplate, it takes whatever ingot is in the input and attempts to use it in the same pattern you would use to craft an Iron Chestplate. So an input of Gold would output a Gold Chestplate. Though I could be wrong because I do not completely understand your "recipe-to-test-against" part...

1. I meant in an abstract fashion. If you use any chestplate the pattern for the mold would look something like this(Using something reminiscent of crafttweeker's recipe pattern because I am used to it): Ingot, null, Ingot Ingot, Ingot, Ingot Ingot, Ingot, Ingot Or any pickaxe would be: Ingot, Ingot, Ingot null, Stick, null null, Stick, null and then you just apply the foundry inputs to the abstract pattern.

2. That is why it would have to be a mix of dynamic detection and hardcoding. I cannot recall any example like you gave with ""Heavy ____" that uses the same recipe shape, but uses Steel ingot instead of iron", but even if I did it would be an outlier. There are no uniform conventions in Minecraft modding so no method is going to catch everything. The closest thing there it to uniform conventions in Minecraft is what we get from vanilla. And from my experience, these types of items more often than not follow the example set by vanilla very closely, names being the Ingot the tool is made from followed by what kind of tool it is, I have even seen it with shears and buckets. On top of that, you could add crafttweeker support so people could add things that are missed.

PS: Please note that I am not trying to tell how to make your mod, I am just trying to help by giving alternative implementation ideas.

[Draco18s]

1. I can't create abstract patterns like that because the recipes--as they exist--aren't "iron, iron, iron..." They're <Ingredient>,<Ingredient>,<Ingredient>..." Where Ingredient is a class that can contain an item stack, an ore dictionary entry, or other similar collection. And a list of Ingredients is an IRecipe, but I can't serialize an IRecipe directly, but I can serialize its output (an ItemStack). Ergo, I store the result item stack (normalized to iron) in the mold and look up the recipe every time.

2. If it can be dynamically detected for any set, it can be dynamically detected for all. There is no reason to hard code any of it. As for my example, its hypothetical, as there are no conventions. My current system (when working correctly, which it did at one point) will detect everything. Name-matching won't (trust me, I thought about it).

3. Craft Tweaker: the last time I messed with it, it was a horrible exercise in futility. How to integrate with it was not well documented and I couldn't get anything working. On top of that it'll be obsolete in 1.13.

[The-Arcanian]

Ok, fair enough. You have better knowledge of the code base than I do, Though I wish the foundry was set up in a way that was not dependent on vanilla crafting. (I had the idea of foundry being the only way to make metal tools and armor.)

And yes, crafttweeker can have horrible documentation (and when you try something that was given no indication not to do and it crashes the game are just told "don't to that" when you report the crash)... But it won't be obsolete in 1.13. There are things that crafttweeker can do that 1.13's custom crafting cannot yet. Plus it can modify the recipes in things other than vanilla crafting.

[Draco18s]

Ok, this should be resolved now. Pushing the code to github, will do a build later.

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/util/RecipesUtils.java#L258