Having spent a lot of time working on some circuit controlled quality crafting blueprints recently, I started to run into some annoyances with dealing with quality parameters. This might not be a bug exactly since I can see how this behavior might have been intended at some point, but in my opinion its unintuitive and annoying either way.
Case 1: same parameter, same quality. Quality is not preserved.
Case 2: same parameter, different quality. Quality is preserved.
Case 3: different parameters, same quality. Quality is not preserved.
Case 4: different parameters, different quality. Quality is not preserved.
The behavior I expect from these tests is that any parameter with a quality specified should retain that quality after user selection, unless the user specifies a different quality. This would possibly require an additional UI element to make it clear what you're selecting, maybe the "any quality" symbol could be included in the quality selection bar and selected by default to show that it will use the quality provided by the parameters.
For a concrete example of how this was bothering me, I included a speaker in my quality crafter which made an alert when parameter 0 (legendary) > 0. Within the whole blueprint this was fine because case 2 would be fulfilled by the other combinators involved, but sometimes when cutting and pasting to move certain sections around while designing it case 2 would not be fulfilled and the speaker condition would lose its quality, which could go unnoticed for a long time since the speaker wasn't something I was opening up often.
[2.0.69] Parameters with quality behave inconsistently
-
supremecool
- Burner Inserter

- Posts: 16
- Joined: Thu Sep 03, 2020 5:15 pm
- Contact:
Re: [2.0.69-0] Parameters with quality behave inconsistently
This is Not a bug.
Cases 3 and 4 are essentially non existent: when using different parameters, there is no quality coupling between parameters so this behaves exactly as case 1.
Case 2 is intended: if you have a blueprint with for example 3 assemblers, one crafting normal quality recipe, second crafting uncommon quality recipe and third crafting rare quality recipe, if all of those machines are using same parameter then when selecting a recipe you will not be able to select quality because it will be taken from a blueprint (there are multiple qualities present). However if you only ever have 1 of a quality (case 1), then you can change quality of that parameter because there is no loss of details by changing quality of a parameter.
Cases 3 and 4 are essentially non existent: when using different parameters, there is no quality coupling between parameters so this behaves exactly as case 1.
Case 2 is intended: if you have a blueprint with for example 3 assemblers, one crafting normal quality recipe, second crafting uncommon quality recipe and third crafting rare quality recipe, if all of those machines are using same parameter then when selecting a recipe you will not be able to select quality because it will be taken from a blueprint (there are multiple qualities present). However if you only ever have 1 of a quality (case 1), then you can change quality of that parameter because there is no loss of details by changing quality of a parameter.
-
supremecool
- Burner Inserter

- Posts: 16
- Joined: Thu Sep 03, 2020 5:15 pm
- Contact:
Re: [2.0.69] Parameters with quality behave inconsistently
Thank you for clarifying. I agree that you should be able to select a new quality for a parameter that only has 1 quality present. However adding quality to a parameter essentially does nothing at all until you have another quality of that parameter present. Considering that you have to go out of your way to add quality to a parameter in the first place (especially when parameterizing through the blueprint creation menu) I think that it could at least set the default selected quality when filling in the parameter. In fact since quality selection only happens when the parameter has only a single quality present, that quality could be used to set the default quality selection without needing the extra UI element I suggested.
