[2.0.41] Set Recipe can set wrong recipe instead of no recipe in quality edge cases

[zig1000]

Cross-posting viewtopic.php?t=127371 as I think this might be considered a bug not a feature quirk.

TL;DR set_recipe(foundry, uncommon_iron_gear) -> common_iron_gear recipe gets set, instead of no recipe like for other impossible items.

I think that a machine setting a wrong recipe instead of no recipe is prone to breaking circuit builds (see remarks in other post), and worth treating as a bug.

[Rseding91]

Thanks for the report however I'm not seeing any bug here. LuaEntity::set_recipe() will set any recipe you give it quality wise. Circuit set-recipe will ignore quality for fluid-input-only recipes (as intended).

[zig1000]

> Circuit set-recipe will ignore quality for fluid-input-only recipes (as intended).

What are the upsides of this as intended behaviour? To my understanding, the game largely tries to treat different qualities as different items in most aspects (e.g., requests don't do any magic generalizations across quality levels) so setting a different quality than given is IMO close to as unexpected as if it had set a completely different item's recipe. As covered in the linked post, this makes it hard to automate passing recipes to machines that can make them, as the machine effectively lies and reports that it can create it.

I think it would be much more consistent if the machine refused to set any recipe at all in these cases, like it does for other items it can't create. That allows circuit builds to detect this case and send the recipe to a different machine (e.g. to an assembler instead of a foundry) without needing to hardcode all fluid-only recipes as special cases.

[Rseding91]

I don’t understand the use case. It is never valid to craft a recipe that takes fluid only with non normal quality. So if the machine can craft the recipe it will always be normal quality.

[zig1000]

The use case is a make-anything mall that includes multiple machine types, BOTH foundry and assembler. I prefer the mall to use the Foundry when possible, due to the prod bonus. So, for example, the mall might try to set a regular gear recipe on the Foundry, see the recipe successfully get set (by checking Read Ingredients), and stops there. If it needs to make a recipe the Foundry can't create (e.g. green chip), it tries to Set Recipe on the Foundry, detects the lack of any ingredients in Read Ingredients, and responds by instead sending that recipe to the assembler.

But if I need the mall needs to make *uncommon* gears, it CANNOT make them in the Foundry, but it CAN make them in an assembler, because the assembler's gear recipe is non-fluid. But, it does the same procedure:

1. Try to Set Recipe uncommon gear on the foundry
2. Foundry responds with a non-empty list of ingredients in Read Ingredients
3. The mall can only conclude that the foundry WILL be able to make uncommon gears, and gets stuck forever instead of sending the recipe to the assembler.

This means this mall design can only be achieved by hard-coding lists of recipes for each machine, which is painfully inelegant and toilsome. If the Foundry instead set no recipe when asked for uncommon gears, the mall can detect that Read Ingredients is empty, and fallback to the assembler instead of the foundry, just like it does for green chips.

[robot256]

I can see zig's point. The entire quality system treats "normal gear" and "uncommon gear" as completely different items. There are no cases in which they can be used interchangeably. Therefore setting a recipe with the wrong quality is no different than setting a completely different item than what was requested.

It would be possible to do a slightly better workaround than fully hardcoded lists--e.g. blacklists or quality filters for certain items. But it still doesn't make sense that you set A and get B instead.