Behaviour of Set Recipe for quality fluid-only recipes

[zig1000]

TL;DR

Machines can set an incorrect recipe in some Set Recipe edge cases, when they should set no recipe.

What?

Current behaviour: When using circuit Set Recipe to request a quality item (e.g. uncommon iron gear), if the machine's matching recipe has only fluid ingredients (e.g. the Foundry's iron gear recipe), the machine will set the normal quality recipe - even if the machine has no quality modules.

Proposal: These cases should always fail to set the recipe or should only succeed if the machine has quality modules (or a > 0 quality chance after speed
module penalties).

Why?

This can lead to unexpected results when automating with Set Recipe and Read Ingredients - the machine is effectively reporting 'I can make this item' even though it cannot. This might prevent the circuitry from e.g. sending the recipe to an assembler instead, which can make uncommon gears, unlike a qualityless foundry.

The 'always fail' behaviour would be more convenient in obscure builds that want to get quality module upgrades when possible despite also having quality ingredients available. But having the behaviour change if quality modules are used seems like it would be more convenient for gambling setups, and is probably better on the whole.

[quineotio]

Wouldn't this be more confusing? I mean, in the example you gave, it has to fail one way or another - either set to quality recipe when it can't produce it, set to normal even though it was told to produce quality, or do as you propose and set no recipe.

I think setting no recipe is a less clear fail state than setting to common, because at least you know something has happened - the signal has been received. If I sent a set recipe signal and nothing happened, I could easily assume there was a problem with the signal or settings on the machine.

[zig1000]

* Failing to set is more consistent. Machines already set no recipe if given an item they cannot create.

* Failing to set is more visible. This sort of circuitry is often fulfilling random logistic requests, not necessarily something the player directly set and is checking the status on. If I run by my mall and see it stuck not making anything, I'll know something is wrong. If it sets the wrong recipe, I'll see the mall 'doing work' and not notice that it's actually stuck endlessly making the wrong item.

* Failing to set is more automatable. By checking if Read Ingredients has no signal, the system can detect this error case. If the wrong recipe is set, the system only sees that some ingredients were indeed correspondingly set, and has no practical way to know that those ingredients are for the wrong recipe.

[zig1000]

Upon further reflection, failing to set even when quality modules are present is more consistent, because any intentional-gambling setup would already have to set machine recipes to one quality tier lower than what they're gambling for - so any machine setting a different tier than they send would cause bad edge cases.