This bug was originaly reported on my Train Construction Site mod.

__reverse-factory__/func.lua:27: in function 'addRecipes' (attempt to index field 'expensive' (a nil value)).

I create recipes where I only provide recipe.normal and not recipe.expensive, as it is not required by the base game.

You'll have to split these out into 2 defferent cases where one of them could be defined.

Kind regards
lovely_santa

Good to know. I kinda had the feeling that some mods might try this, but hadn't actually run into the issue yet, so left it as is. Shouldn't be too difficult to separate them out.

Any particular reason to do it that way though? I know the game still recognizes normal recipes without expensive defined, and vice versa, but why?

There are some mods libraries (bob is one of them) that convert recipe.ingredients to recipe.normal.ingredients.
I adapted my lib to this as well, as it is easier to code if you have less edge cases. When I create a recipe, I use recipe.ingredients no mater what (usualy). But when I use a lib function on it, it automaticly converts it.

EDIT: This is 60 lines of code of a function, just to add an ingredient to an existing recipe. And this is already getting out of hand as it it; But it will work in all cases.

Alright, should be fixed as of v6.1.6 v6.1.7 (mistakes were made)

Even had some issues with the Factorio Stdlib, as many of its functions actually check for normal, and then attempt to perform actions on normal and expensive. So I guess it's not just me who assumes if normal then expensive :D

Overriding the functions wasn't too difficult at least, though if/when they fix these issues, I'll have to go back and prune some code later.

Also, bobs mods is one of the modsets that I always test with, and I've never had any issues with them and reverse factory. This is the first time any one has reported an error like this, so I assume that the practice isn't very common. I've actually had the opposite happen though; where expensive variant is defined, but not normal. Though I think Factorio handles this differently than defining normal without expensive, since it doesn't produce an error on any of the checks.

These are the factorio rules:
1) if recipe.normal.ingredients or recipe.expensive.ingredients (or both) are defined, it ignores recipe.ingredients
2) if recipe.normal or recipe.expensive (not both) are defined, it will use that recipe for both normal and expensive
3) if recipe.normal exists, and recipe.expensive equals false (or virsa versa), the recipe will exist in normal, but not in expensive
It took me a while, and the only reason I know this, is as it threw an error on me a while back. Fix the error once, fix it good, and it will happily work for a long time ^_^

just a quick update, related to the threads about crashing: those rules also apply in the strange case that is breaking there: in rule one, "recipe.ingredients = {}" is "valid", and ignored, if the others are set. which is what the code gets to break on func.lua 455. more debugging around it there, but I'm now convinced the correct behaviour is to ignore it in this case. -_-

Yup, seems my fix for this issue has caused issues in other cases where certain properties are defined, but not others. Mainly basic ingredients table can exist alongside normal/expensive, but not have a results defined. Where my code doesn't check that both ingredients and results exist before trying to perform logic on both fields.

Squash one bug, two more pop up...