Reverse Factory

by Kryzeth

Reverse Factory machine will recycle (uncraft) nearly any item placed inside. Supports the recycling of most, if not all, modded items.

Content
14 days ago
0.13 - 2.0
67.6K
Manufacturing

b [Fixed] func.lua:179: attempt to index field '?' (a nil value)

9 months ago

I get this error message during game startup:

6.181 Error ModManager.cpp:1741: Failed to load mod "reverse-factory": reverse-factory/func.lua:179: attempt to index field '?' (a nil value)
stack traceback:
reverse-factory/func.lua:179: in function 'checkResults'
reverse-factory/func.lua:108: in function 'makeRecipe'
reverse-factory/func.lua:49: in function 'addRecipes'
reverse-factory/data-final-fixes.lua:128: in function 'final_fixes'
reverse-factory/data-final-fixes.lua:170: in main chunk
6.216 Loading mod core 0.0.0 (data.lua)
6.319 Checksum for core: 1334491919
6.340 Finished checking unused prototype data in 0.000370 seconds. Number of properties that were used: 26398
6.341 Error ModManager.cpp:1741: Error in assignID: procession with name 'default-b' does not exist.

Source: default (utility-constants).

Maybe the below is related to above?

9 months ago

Ah, I see the mistake, some mods are not having an array around the results dictionary: result = {type="foo", name="bar", amount=x} instead of wrapping it with another {} pair.

9 months ago
(updated 9 months ago)

Can you please add more debug output lines which output the recipe's name and so on? Then debugging and finding the culprit is much easier.

9 months ago
(updated 9 months ago)

Is this related to a specific mod on the mod portal? I can't imagine that mod would function properly if written that way, since the game has gotten a little more strict with the way recipes have to be coded.

As for adding more debug lines... there are already a lot of checks in place to make sure item-recipe pairs are properly coded, so adding debug lines might just make things even more bloated. I could add another check here, to ensure that recipes have a proper results table, but that wouldn't really help you in this regard.

Funnily enough, I do already have a line there specifically to help me find the offending recipe:

--if not recipe.results[1] then error(serpent.block(recipe)) end
9 months ago
(updated 9 months ago)

Yes, some mods had malformed recipe results and/or ingredient lines, with short-hand array or only result="foo", result_count=4 and not results={{type="item",name="foo",amount=4}}.

Your mod crashed there with broken results={type="item",name="foo",amount=4}. After I fixed them, with the help of a log(string.format("receipt.name=%s", receipt.name)) line, it loaded fine.

9 months ago
(updated 9 months ago)

Can you check if the malformed versions of those mods still cause a reverse-factory error? I added another check to ensure recipe has a proper results table before attempting to create a reverse recipe, so those recipes should just quietly fail now (though I didn't actually test that part)

9 months ago
(updated 9 months ago)

I was not able to reproduce it with simply removing the wrapping {} braces: results = {type="item" name="foo", amount=1} causes a bug in that mod, not in reverse? And can you please add a else log("Recipe has no valid results: "..recipe.name) or something like this?

9 months ago

Alright, perfect, thanks!

9 months ago

Please add some message if a mod was rejected for debugging it. See my edits.

9 months ago
(updated 9 months ago)

Just realized I actually did have some debugging statements around each of those aforementioned checks (it's been a long while since I had to update this mod), and just needed to update the check for recipe results (since I was using next(recipe.results) as the final deciding factor)

Redownload v9.0.20 (didn't want to increase the version number for such a minor edit that didn't affect functionality, and only had 24 downloads before I pulled it) and it should add some logging lines for malformed ingredients or recipe tables.

New response