Factorio Forums

I'd like to ask for a way to turn off the chance of getting a better quality item from a recipes outputs, because it can massively intefere with any item-based catalysts in mods.
Using this recipe as an example - this is the only way to get barium nitrate (and by extension, barium) in my mod and as you can see, it takes a special catalyst item and has a chance to output the same catalyst or the container it uses. If someone puts quality modules in this recipe (for quality barium), they have a chance of getting unloopable quality catalysts; which either means they need to build a quality handler for the catalysts or just stuff them in a box until they start using an above common recipe that require catalysts.

This is why i'd like an `ignored_by_quality` parameter or something similar on the ItemProductPrototype that would force the item its on to only be produced as the same quality as the recipe itself. (so if its a common recipe, it can only output common products. if its a rare recipe, it can only output rare products, etc)

In currently version we can use "RecipePrototype::allow_quality" to disable it, tho I tend to agree it should also have a parameter in product entry...
I mean just like machine innative productivity is unaffected by "RecipePrototype::allow_productivity", machines with innative quality will be also unaffected thus create high quality trash version of catelyst.

https://lua-api.factorio.com/latest/typ ... otype.html

Seems like a ignored_by_quality property that defaults to the value set by ignored_by_productivity would solve this

+1, this would be a good usecase for the ignored_by_quality flag on results

Proposed solution of "ignored_by_quality" being an integer has a fundamental flaw that makes it impossible to add: if a recipe would finish, due to value of this field it coukd happen that X items of better quality and Y items of original quality would be given but they would have to be both given through a single item stack, and that is impossible.

At most what i could make is a quality_behavior on item product prototype with 3 options: "default" (for current behavior), "no_bump" for product not affected by quality but preserving input quality, and "set_normal" that would always give normal quality product regardless of ingredients quality.

boskid wrote: Mon Sep 29, 2025 5:28 am Proposed solution of "ignored_by_quality" being an integer has a fundamental flaw that makes it impossible to add: if a recipe would finish, due to value of this field it coukd happen that X items of better quality and Y items of original quality would be given but they would have to be both given through a single item stack, and that is impossible.

At most what i could make is a quality_behavior on item product prototype with 3 options: "default" (for current behavior), "no_bump" for product not affected by quality but preserving input quality, and "set_normal" that would always give normal quality product regardless of ingredients quality.

That seems reasonable, tbh i thought the suggestion was a boolean for the "no_bump" you mentioned

boskid wrote: Mon Sep 29, 2025 5:28 am Proposed solution of "ignored_by_quality" being an integer has a fundamental flaw that makes it impossible to add: if a recipe would finish, due to value of this field it coukd happen that X items of better quality and Y items of original quality would be given but they would have to be both given through a single item stack, and that is impossible.

At most what i could make is a quality_behavior on item product prototype with 3 options: "default" (for current behavior), "no_bump" for product not affected by quality but preserving input quality, and "set_normal" that would always give normal quality product regardless of ingredients quality.

My suggestion was for it to be a boolean (and act identical to “no_bump”
(however having those options would be very nice)

boskid wrote: Mon Sep 29, 2025 5:28 am At most what i could make is a quality_behavior on item product prototype with 3 options: "default" (for current behavior), "no_bump" for product not affected by quality but preserving input quality, and "set_normal" that would always give normal quality product regardless of ingredients quality.

That would be great, "set_normal" too for some mods would be very useful to downgrade items (or "upgrade" them as is currently done by scripts in Inverted Quality)

boskid wrote: Mon Sep 29, 2025 5:28 am At most what i could make is a quality_behavior on item product prototype with 3 options: "default" (for current behavior), "no_bump" for product not affected by quality but preserving input quality, and "set_normal" that would always give normal quality product regardless of ingredients quality.

Why only normal, not a specific quality? That would close another request too, IIRC.

Because i do not want to allow other qualities to be specified. I was already attempting that and it always creates issues near crafting queue which is unable to handle quality. I would have to add a lot of safeguards such recipes never appear in the crafting queue, not even indirectly through recipe decomposition.

boskid wrote: Mon Sep 29, 2025 6:01 pm Because i do not want to allow other qualities to be specified. I was already attempting that and it always creates issues near crafting queue which is unable to handle quality. I would have to add a lot of safeguards such recipes never appear in the crafting queue, not even indirectly through recipe decomposition.

That makes sense. The behavior you suggested - default/no_bump/set_normal seems pretty useful as is.

boskid wrote: Mon Sep 29, 2025 6:01 pm Because i do not want to allow other qualities to be specified. I was already attempting that and it always creates issues near crafting queue which is unable to handle quality. I would have to add a lot of safeguards such recipes never appear in the crafting queue, not even indirectly through recipe decomposition.

would it be possible/sufficient to force these off when loading recipie prototypes that have any qualities defined? maybe give an error message saying its unsuported so modders who stumble into it dont get confused as to why their recipie isnt being decomposed.

On the second thought, just checking that no character shares the crafting category with the recipe might be enough.

Another option for the quality settings per output (although unlikely due to the handcrafting issues mentioned, but they could be ignored as intermediates when considered for the crafting queue) would be an int 'bump_level' which would be the change to the current quality level. 0 would operate like the 'no_bump', 1 would make it jump up a level regardless, and -1 would have it jump down a level regardless. Of course these would need to respect what quality levels are supported (and possibly unlocked) so a normal quality recipe bumped by -1 would result in normal items, and a legendary recipe bumped +1 would result in legendary items.

EDIT honestly it kinda sounds like 'additional quality' sortof like 'additional probability' where it's a float added to the 'quality' bonus calculated from effects and the quality prototype and the RNG output... but thats a bit far fetched

protocol_1903 wrote: Sun Nov 09, 2025 12:14 am Of course these would need to respect what quality levels are supported (and possibly unlocked) so a normal quality recipe bumped by -1 would result in normal items, and a legendary recipe bumped +1 would result in legendary items.

Or those recipe variants just aren't available. To reduce confusion.

curiosity wrote: Sun Nov 09, 2025 4:01 am

protocol_1903 wrote: Sun Nov 09, 2025 12:14 am Of course these would need to respect what quality levels are supported (and possibly unlocked) so a normal quality recipe bumped by -1 would result in normal items, and a legendary recipe bumped +1 would result in legendary items.

Or those recipe variants just aren't available. To reduce confusion.

That would be a design opinion. You can still see fluid based recipes in the handcrafting GUI even though they aren't selectable, I see no reason why these couldn't be visible and locked.

boskid wrote: Mon Sep 29, 2025 5:28 am Proposed solution of "ignored_by_quality" being an integer has a fundamental flaw that makes it impossible to add: if a recipe would finish, due to value of this field it coukd happen that X items of better quality and Y items of original quality would be given but they would have to be both given through a single item stack, and that is impossible.

Couldn't the differing quality items just go to different slots?

boskid wrote: Mon Sep 29, 2025 5:28 am At most what i could make is a quality_behavior on item product prototype with 3 options: "default" (for current behavior), "no_bump" for product not affected by quality but preserving input quality, and "set_normal" that would always give normal quality product regardless of ingredients quality.

Then why can't you implement this? It would pretty much just be a more extensive version of this same API allowing for the quality of a result to depend on the quality of the ingredients in more ways than just "default", "no_bump" and "set_normal". These recipes can just not be crafted if you're worried about handcrafting. (and besides, handcrafting only being able to output normal quality items seems like an unnecessary restriction which you could just remove)

Quorken wrote: Thu Oct 09, 2025 5:31 am

boskid wrote: Mon Sep 29, 2025 6:01 pm Because i do not want to allow other qualities to be specified. I was already attempting that and it always creates issues near crafting queue which is unable to handle quality. I would have to add a lot of safeguards such recipes never appear in the crafting queue, not even indirectly through recipe decomposition.

That makes sense. The behavior you suggested - default/no_bump/set_normal seems pretty useful as is.

Yes, but not useful enough, as I wouldn't be able to make recipes which decrement or increment the quality of the input unless the quality of the output can be dependent on the quality of the input.

BraveCaperCat wrote: Sun Nov 09, 2025 6:48 pm

boskid wrote: Mon Sep 29, 2025 5:28 am Proposed solution of "ignored_by_quality" being an integer has a fundamental flaw that makes it impossible to add: if a recipe would finish, due to value of this field it coukd happen that X items of better quality and Y items of original quality would be given but they would have to be both given through a single item stack, and that is impossible.

Couldn't the differing quality items just go to different slots?

I'm wondering if you could take it a step further, and always have outputs that are of a different quality (relative to the "expected" quality) go into special "different quality" slots. So even in the base game, if a recipe's output is bumped up a quality, it will go into the special "different quality" slots, instead of the normal "same quality" slots.

I.e. if a machine is set to produce uncommon beacons, and it produces a legendary beacon, that legendary beacon would go into the "different quality" slots, instead of the "same quality" slots.

So if you then have a recipe that produces 4 advanced circuits, with two of them ignored by quality, any that are bumped/dropped in quality would go into the "different quality" slots, while all others would go into the "same quality" slots.

Edit: That said, if you need ignored_by_quality to be an integer, couldn't you instead create a separate product entry with amount=<to be ignored by quality> and ignored_by_quality=true? Except if the product count can be less than the desired "ignored_by_quality" - same reason ignored_by_productivity is an integer, instead of a boolean.

Edit2: UI for the different slots would be a duplicate of the output slots, but with the wildcard quality icon on each possible output - or perhaps the recipe's "base quality" with a greater-than/less-than next to it. An additional advantage of this is that it could clearly communicate what items are affected by quality, and how - if a product cannot have its quality bumped (e.g. fluids, the catalysts in the original post), it would not appear in these "different slots". If the machine has no net quality effect (no modules, no inherent bonus, no transmitted effects...), it would not show these slots at all, as it cannot produce quality items.

Quorken wrote: Sun Nov 09, 2025 6:58 pm

BraveCaperCat wrote: Sun Nov 09, 2025 6:48 pm

boskid wrote: Mon Sep 29, 2025 5:28 am Proposed solution of "ignored_by_quality" being an integer has a fundamental flaw that makes it impossible to add: if a recipe would finish, due to value of this field it coukd happen that X items of better quality and Y items of original quality would be given but they would have to be both given through a single item stack, and that is impossible.

Couldn't the differing quality items just go to different slots?

I'm wondering if you could take it a step further, and always have outputs that are of a different quality (relative to the "expected" quality) go into special "different quality" slots. So even in the base game, if a recipe's output is bumped up a quality, it will go into the special "different quality" slots, instead of the normal "same quality" slots.

I.e. if a machine is set to produce uncommon beacons, and it produces a legendary beacon, that legendary beacon would go into the "different quality" slots, instead of the "same quality" slots.

So if you then have a recipe that produces 4 advanced circuits, with two of them ignored by quality, any that are bumped/dropped in quality would go into the "different quality" slots, while all others would go into the "same quality" slots.

No, I think this "different slot" thing should only apply to differing quality items created as a byproduct/catalyst. I even think it would make sense for byproducts/catalysts to have a different slot even when the quality doesn't differ to other resulting items.

Quorken wrote: Sun Nov 09, 2025 6:58 pm Edit: That said, if you need ignored_by_quality to be an integer, couldn't you instead create a separate product entry with amount=<to be ignored by quality> and ignored_by_quality=true?

I actually don't need ignored_by_quality to be an integer, I just think that the other people who have posted in this topic might find it useful. Also, I'm not sure you can have two product entries with the same name and type properties.

Quorken wrote: Sun Nov 09, 2025 6:58 pm Edit2: UI for the different slots would be a duplicate of the output slots, but with the wildcard quality icon on each possible output - or perhaps the recipe's "base quality" with a greater-than/less-than next to it. An additional advantage of this is that it could clearly communicate what items are affected by quality, and how - if a product cannot have its quality bumped (e.g. fluids, the catalysts in the original post), it would not appear in these "different slots". If the machine has no net quality effect (no modules, no inherent bonus, no transmitted effects...), it would not show these slots at all, as it cannot produce quality items.

The game can already handle adding extra output slots to machines. It already does so when you change the recipe of the machine via the circuit network.

BraveCaperCat wrote: Sun Nov 09, 2025 7:12 pm

Quorken wrote: Sun Nov 09, 2025 6:58 pm
I'm wondering if you could take it a step further, and always have outputs that are of a different quality (relative to the "expected" quality) go into special "different quality" slots. So even in the base game, if a recipe's output is bumped up a quality, it will go into the special "different quality" slots, instead of the normal "same quality" slots.

I.e. if a machine is set to produce uncommon beacons, and it produces a legendary beacon, that legendary beacon would go into the "different quality" slots, instead of the "same quality" slots.

So if you then have a recipe that produces 4 advanced circuits, with two of them ignored by quality, any that are bumped/dropped in quality would go into the "different quality" slots, while all others would go into the "same quality" slots.

No, I think this "different slot" thing should only apply to differing quality items created as a byproduct/catalyst. I even think it would make sense for byproducts/catalysts to have a different slot even when the quality doesn't differ to other resulting items.

I'm not sure what you mean by a byproduct in this context.

The reason I suggested pushing all "different quality" items into these slots was to give uniform behavior - the player knows that if a recipe normally produces a product B at quality X, but some effect/probability means it is produced at quality X', it will be in these other slots. So if there isn't such a slot for a product B, the player knows it can only be produced at quality X, and they do not need to handle any other quality for that item.

BraveCaperCat wrote: Sun Nov 09, 2025 7:12 pm

Quorken wrote: Sun Nov 09, 2025 6:58 pm Edit: That said, if you need ignored_by_quality to be an integer, couldn't you instead create a separate product entry with amount=<to be ignored by quality> and ignored_by_quality=true?

I actually don't need ignored_by_quality to be an integer, I just think that the other people who have posted in this topic might find it useful. Also, I'm not sure you can have two product entries with the same name and type properties.

You can have duplicate product entries, likely for this kind of stuff (say, 20%, 5%, and 1% chance of a product) - just not duplicate ingredient entries.

From the wiki (https://lua-api.factorio.com/latest/pro ... ml#results):

Can be set to an empty table to create a recipe that produces nothing. Duplicate results, e.g. two entries with the same name, are allowed.

Also, I actually edited my previous post while you were typing out yours, I think.

Edit: A side benefit of separate slots for quality outputs is if the machine works very quickly, with a quality chance - in the base game, if the machine produces a quality result, and produces a normal result before an inserter can remove the quality result (say, because of the swing time of its arm, since an inserter would need to make a separate trip if the quality is different), it will stall until the inserter can remove said quality item. If you have separate slots for "different" and "same" quality results, this becomes much less likely - it would only happen if two different quality results were produced back-to-back.