Disable quality chances per item in a recipes results

[MrSmoothieHuman]

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.

09-27-2025, 10-54-42.png (56.66 KiB) Viewed 1069 times

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)

[meifray]

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.

[computeraddict]

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

[protocol_1903]

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

[boskid]

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.

[protocol_1903]

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

[MrSmoothieHuman]

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)

[Osmo]

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)

[curiosity]

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.

[boskid]

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.

[Quorken]

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.

[Laxai]

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?

11-07-2025, 16-06-47.png (2.29 KiB) Viewed 173 times

11-07-2025, 15-58-02.png (4.41 KiB) Viewed 173 times

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.

[curiosity]

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

[protocol_1903]

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

[curiosity]

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.

[protocol_1903]

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.