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. Fully featured integration with Bobs Mods, Industrial Revolution, and Fantario (independently, not simultaneously)

Content
23 hours ago
0.13 - 1.1
55.4K
Manufacturing

b [Fixed] Newest update failed to load with "bad argument"

4 years ago
 18.195 Mods to disable:Failed to load mods: __reverse-factory__/func.lua:455: bad argument #1 of 3 to 'insert' (table expected, got nil)
stack traceback:
    [C]: in function 'insert'
    __reverse-factory__/func.lua:455: in function 'formatResults'
    __reverse-factory__/func.lua:229: in function 'makeRecipe'
    __reverse-factory__/func.lua:123: in function 'addRecipes'
    __reverse-factory__/data-final-fixes.lua:14: in main chunk
4 years ago
(updated 4 years ago)

I debugged this some, and at least one path to triggering this is:
1. Install AAI Industries, Krastorio, and Reverse Factory. (possibly others, but these are the core.)
2. AAI Industries mutates the "inserter" recipe from "recipe.ingredients" to use "recipe.{normal,expensive"
3. Krastorio also sets recipe.ingredients directly on it.
4. ???
5. Reverse Factory gets a recipe with recipe.ingredients = {} as well as recipe.{normal,expensive} = { ... actual content ...}

Which leads to the crashing out there, because the nrecData.result is nil at that point in time. I'm not certain exactly what happens where to trigger this, but I think the correct behaviour is to simply ignore it: the core game will, during prototype building, treat this recipe as valid, and only use the normal/expensive paths.

I'll probably poke at it a little more, but I verified the last by using a horrible hack to simply skip the empty ingredients table in that one case, and the game, y'know, didn't explode or complain. and had inserters. :)

4 years ago

I don't have AAI Industries, but I do have Krastorio.

4 years ago
(updated 4 years ago)

Ahh.. I hadn't tested with mods like Krastorio or AAI. But yeah, my mod is expecting that if ingredients are defined, then results should be defined.

Should just need a check that both ingredients and results are defined before attempting to put the ingredients into the results table. Unfortunately will have to wait until I can get back home...

(On a completely unrelated note, if anybody has a copy of v6.1.6, can upload and send please? I seem to have deleted the wrong version from the mod portal, and there's not really a stable version to revert to)

4 years ago
(updated 4 years ago)

I was bemused by the fact it had an empty ingredients table, but the crash was that "results" was nil in your code ... but something needs to be defensive here, I'm convinced, per the other thread with lovely_santa, since the game will just ignore that.

I have my own local hack, which does exactly what you just said, in place so I could test it. Seems to work just fine -- notably, I don't remove the ingredients={} data from the original, and the game loads fine. C++ must totally ignore the field if normal/expensive is defined at all.

if recipe.ingredients and nrecData.results then

I didn't touch anything else because, at this time, nothing else breaks, but I suspect that you need to treat "either normal or expensive is not nil, ignore ingredients" across the board. Such ... lack of structure. -_-

4 years ago

"Lack of structure"...? In my mod? Probably so lol... But I think changing that one line would basically fix the issue.

I originally had simple checks like:

if normal then [do things to normal and expensive recipes]
else [do things to simple recipe]
end

But mods like lovely_santa's, among others, define one without the other, so I had to separate it into:

if normal then [do things to normal] end
if expensive then [do things to expensive] end
if ingredients/recipe/etc then [do things to simple recipe] end

And in most cases, "do things", involves even more checks for main product, ingredients, result/results, etc. Adding another if check to all of the simple recipe sections wouldn't be so bad, but it's still more lines of code... if everything works fine with this simple line change, then I'll probably stick to that, and check for consistency everywhere else. If nothing breaks, it should be fine like this.

4 years ago

No, lack of structure in the way prototype tables in the data phase are handled. The roughly one million different, valid, ways to say "one iron plate" as an ingredient. :)

Your code is very pleasant to read, and easy to understand.

I honestly don't know the right way to handle all them being present. I just checked for the results table existing and skipped the recipe if it didn't, on the basis that if I couldn't recycle something, better than not being able to play. :)

4 years ago
(updated 4 years ago)

Lmao, oh! Is it really? Wow, I'm glad to hear it! I thought it be a bit obtuse tbh...

But yeah, it is pretty annoying how many different ways recipes can be defined, and how those ways interact with each other.

One of the most annoying thing was learning that normal/expensive being undefined is handled differently then normal/expensive being nil. In one case, normal = expensive, and in the other, normal/expensive don't appear in-game.

Back when I was using my old [do things to normal and expensive] code, I was wondering why an ingredient was being added to the recipe twice (since the "ingredient" is always supposed to be the item being recycled). And realized the normal/expensive property were being duplicated. Adding an ingredient to one was the same as adding it to the other lol.

Of course, I'll go through and make sure that all the recipes work with the simple line change. Should be back in about.. an hour or so? And then upload shortly after that.

I'm really annoyed that I accidentally deleted the last "stable" version (6.1.6) by accident, when trying to remove the accidentally crashy upload of (6.1.7). Half a day without a working Reverse Factory is far too long of downtime (for anybody who hasn't already hack-fixed their local copy, that is)!

4 years ago

<3 thanks so much. I'm not well placed to judge downtime: I expect it, and having written mods myself, know how real life and testing can get in the way. so ... I'm pretty understanding. :)

4 years ago

Alright, took only a bit longer than expected, but this error should be resolved as of v6.1.9

New response