Factorio Forums

TL;DR

The default output quality should be determined by the minimum quality of all available inputs, and nothing else, including no selection in an assembler.

What?

Currently, the target quality has to be selected in assemblers. This determines which inputs are accepted; they must match exactly (no worse and no better).
I propose that higher quality input should always be accepted as valid input to a lower tier recipe.
Assemblers should not offer to select a target quality. Instead, they should always produce items of the lowest common quality among its inputs.

Why?

In another post, someone wrote:

> Treat items of a different Quality as a belt contaminant. Remove it with a Splitter filtered to that contaminant. Put it either into a box, or route it to where you want it used.

Now, it does work. It is easy to have quality be a separate line, to build closed loops to produce good quality items. But it simply does not make sense that we have to do that.

Imagine you're working at an assembly line in a factory. You job is to take an A thing, cut it in half and drop it in a box. Usually the A thing is kind of scratched up and has sharp edges, but you don't care, you are careful about the edges and the resulting product is still good enough. But one day, you get an A thing that is not scratched. In fact, it looks like it was lovingly polished, so you handle it easily without gloves. Now what do you do? Answer: You refuse to use it because it does not pose a danger to your health, like usual items would. Makes sense? Certainly not!

Higher quality input should always be accepted as valid input to a lower tier recipe. This way good quality items do not "contaminate" a belt. The worst case is now that their quality is lost uselessly, but at least they do not nonsensically clog everything up. Note that, to get better quality, the player would have to do custom item routing anyway, so there is no difference if the player does want to do that. So this is easier and more robust with no downside at all.

In the same tune, also change assemblers to always produce items of the lowest common quality among its inputs. That way, you don't need to specify the target quality. You simply put it lots of quality input, and the result will have the same quality without need to change anything. I found it annoying to keep selecting qualities over and over again when I simply wanted to get something built. I can figure out which quality input to request or route to the assembler later, and I can change the output simply by changing the input, but not the recipe. So I either don't care about quality and it still works; or if I want quality, I have to do the same work as I would have to do anyway. Again, easier with no downside.

To reiterate, these changes would not change the complexity of builds that use quality. It may break existing builds but is reasonably easy to implement. It would not affect builds that do not use quality. What it does is to make quality more fluent, easier to use, with fewer clicks and less UI clutter.

I think this can be somewhat annoying to implement, as it deviates from usual recipes and requires a notable change to the game engine. But many players have a love-hate relationship with quality, and felt forced to separate instead of integrate it. I think it is fair to say that it is one of the least polished interactions the game currently offers.

What you're suggesting likely will not be done, as it allows productivity to be exploited by running lower quality crafts on a machine until the productivity bar is nearly full, then running a higher quality craft to complete the productivity bar and get two items of the higher quality for the price of one. Forcing the recipes to be different prevents this, as switching recipes clears the productivity bar.

Possible solutions for the productivity exploit:
- Productivity meter remembers the lowest quality it produced. The extra is at that low productivity.
- The quality setting on recipes is used as minimum accepted ingredient. Productivity bonus produces minimum.
- Dedicated "any quality" recipe which disallows the use of productivity modules

I suggested this already in a previous thread.

There's no productivity exploit. Just gave a different productivity bar for each quality output.

No reason not to implement this in the game. But the devs may not be open to new ideas.

facm wrote: ↑Sun Nov 03, 2024 2:11 am To reiterate, these changes would not affect planned or existing builds that use quality, and it would not affect builds that do not use quality. It would not change the complexity of builds - everything remains.

This is not true, it absolutely would break existing builds. I have plenty of single-assembler setups that make their own ingredients and have quality modules. I am relying on inserters only inserting what is requested by the recipe: normal quality items. If the assembler happens to produce quality ingredients, these will stay in the box/wagon and eventually get taken from there by me or by an inserter with a quality filter.

If assembler suddenly started accepting ingredients in all qualities, the inserters feeding these assembler would start wasting these quality ingredients on mixed quality products. Similarly, I would expect people to have sushi belts with assemblers making high quality items by grabbing the necessary high-quality ingredients that happen to pass by. This will break if assemblers suddenly start to accept any quality.

Granted, it shouldn't be too hard to fix by setting a filter on these inserters, but it still is unexpected breakage for existing builds. (It also sucks that you can't set a quality filter via circuits, so this could end up creating complexity for some builds). I would also expect it to break anything that makes a request for specific ingredients by using the "read ingredients" feature of assemblers.

Perhaps it could be fixed by adding a new "any quality" recipe for assemblers, which would be the new default. Existing builds would still use whatever their configured quality is.

Btw, there is another proposal going around: to make assemblers use items from their trash slots as ingredients when the recipe is switched. This is to offset the massive performance penalty we got when the bug of infinite trash slots was fixed... that's another thing that would break and cause quality items to be wasted if assemblers suddenly started accepting any quality.

nzer wrote: ↑Sun Nov 03, 2024 8:13 am What you're suggesting likely will not be done, as it allows productivity to be exploited by running lower quality crafts on a machine until the productivity bar is nearly full, then running a higher quality craft to complete the productivity bar and get two items of the higher quality for the price of one. Forcing the recipes to be different prevents this, as switching recipes clears the productivity bar.

I can also just open the console and spawn a tank. If someone wants to waste their time watching a progress bar, let them...

myridium wrote: ↑Sun Nov 03, 2024 9:02 am No reason not to implement this in the game. But the devs may not be open to new ideas.

I understand why this may be a rather bothersome implementation - it changes from the simple "recipe determines everything" to "recipe has one or more variables". This would still be rather easy to change in a regular application, but this game is highly optimized. I know that I'm a bit reluctant to change my assembler code if I don't *really* need to ^^;;

clarity wrote: ↑Sun Nov 03, 2024 12:03 pm This is not true, it absolutely would break existing builds.

Yea, I was sloppy. I meant that the complexity is kept, which you seem to agree with. But you're right that it would break many existing builds that rely on fixed recipes. I've fixed this in the original post. So, the best time to implement a change like this was before release, and the second best time is now

facm wrote: ↑Mon Nov 04, 2024 2:23 am I can also just open the console and spawn a tank. If someone wants to waste their time watching a progress bar, let them...

"Why bother having restrictions when I can just cheat?" isn't the compelling argument you think it is, and even if it was, if it was possible to get double rare/epic/legendary crafts on things by just babysitting a machine for 30 seconds literally everyone would do it at least some of the time. Never mind that it can be trivially automated with circuits.

This is especially problematic for things like copper wires that you produce very close to circuits because you replenish them along the line. You will never get quality intermediates in exactly the needed ratio, so any loops will get clogged eventually if you aren't pulling stuff into chests and finding ways to deal with full chests. Keeping it balanced and unclogged becomes as complicated as managing sushi belts.

I would be happy enough with a "accept higher quality ingredients" option on recipes so I can have an assembler at the end of the line "eat" anything not otherwise filtered out or used. This would allow you to opt-in to leveraging the quality items at a more granular level. I can sprinkle quality modules around through different areas making intermediates, but largely ignore them except in places where i care enough the fuss with it. Of course this is suboptimal cause some quality intermediates might end up in areas that "eat" them, but that's how it becomes an optimization problem instead of something that breaks my factory. I can gradually refine areas to better manage and take advantage of quality items incrementally.

I like the happy accidents nature of quality that you get some randomly. I hoped this would trickle through the layers of intermediates though, and was disappointed when I realized how something like wires is gonna become a mess.

The problem that I can see with the suggested implementation here is that it doesn't actually change anything about the accessibility of the feature.

Lets say you slap a bunch of quality modules on your wire production for your circuits. Cool; now if you don't fully split them off entirely you basically just reduced the speed of your copper cables for zero benefit. The module is basically just a no-op at that point. So in either scenario you have to treat them as contamination. Nothing has changed; as there is still no incentive to participate with quality unless you are planning to build a full setup for it.

=============================================

In order to make quality more accessible, you will have to design a system in which adding quality modules to intermediate materials does not completely break an existing factory or require it to be designed initially with this in mind from the beginning (No belt contamination). BUT ALSO it has to provide an actual benefit so as to not just be pointless.

My suggestion would be to remove the "all or nothing" way that quality currently works and replace it with something where it is more gradual gains.

Essentially:
If you have some recipe that takes 4 inputs. If 2 of those 4 inputs are uncommon quality instead of common; then the machine would have a 50/50 chance of outputting an uncommon without any quality modules.

If in the same example you have one rare component and 2 uncommons; then you would have two separate quality rolls that happen. First would be for rare, which would be a 25% chance. Then a second roll for uncommon, which would be 75% chance (the rare counting for uncommon).

Productivity simply rolls an average of every output the machine makes while it builds and is unaffected by quality modules (so if you have 10% productivity, and your 10 outputs are 8 common and 2 uncommon, you have a 20% chance to produce an extra uncommon).

Quality modules would be the only way to go beyond the quality of the parts included and could basically function exactly how they do now.

=======================================================

With this implementation the rough output of everything should basically be unchanged only now you have no reason to treat quality components as contamination, you can just let them be free in your belts without a care in the world.

Can probably still keep the mechanism where you can set machines to only operate on some minimum level of quality parts too so old builds are basically unchanged.

Maybe to encourage the pattern of off-ramping components to their own dedicated (quality) sub-factories you could just make it so quality modules will only boost things based on the minimum quality of a component in a machine. (So if your machine uses 99% rares and a single common, the quality modules in it will only roll odds as though it were common rather than rare). The Productivity module averages thing would also mean that only working with a certain level of material makes productivity yet another reason to do this.

Keep in mind this proposed solution here is also just maximizing accessibility and not attempting to maintain complexity or balance or anything of the sort. Those are different questions.

========================================================

The technical meat of trying to implement something like the above though gets messy fast. It could very easily break optimization patterns and would require an entirely new system for allowing inventory slots in machines/players/etc to be capable of sub-dividing themselves into parts of different quality. This would also require a way to /open up/ the stacks to pull out each quality component separately. Probably the main reason things are implemented the way they are is specifically because this particular can of worms was seen as way too much to try and do.

Rykuta wrote: ↑Mon Nov 04, 2024 5:29 pm The problem that I can see with the suggested implementation here is that it doesn't actually change anything about the accessibility of the feature.

Lets say you slap a bunch of quality modules on your wire production for your circuits. Cool; now if you don't fully split them off entirely you basically just reduced the speed of your copper cables for zero benefit. The module is basically just a no-op at that point. So in either scenario you have to treat them as contamination. Nothing has changed; as there is still no incentive to participate with quality unless you are planning to build a full setup for it.

I'm happy to clarify the benefits and what the resulting changes are in this scenario.

1) In the wires scenario, I can begin by setting some green chips along the line intermittently to an Uncommon recipe, and maybe one further down to Rare, and consume what quality ingredients happen to make it to this part of the factory. I can have a sacrificial "consume higher quality ingredients as common" green chip assembler at the very end of the line that consumes excess ingredients of any quality not used by the earlier assemblers, and this keeps things flowing, keeping common ingredients moving past the uncommon/rare consumers, and eating excess out-of-ratio quality ingredients.

- You can start getting "happy occurrence" of benefits of quality intermediate ingredients
- Leaving room to further optimization without having to perfect it the first go around
- Allow quality intermediates to flow through the factory without breaking areas you are not ready to devote attention to.

2) Optionally, independent of the above, I can go ahead and start producing quality intermediates in other areas, and let my trains ship them anywhere without regard intermixed with common, and the recipe option will prevent them from "breaking" other areas of the factory where they end up. I don't need to do any special routing. I just set the sacrificial "consume higher quality" option in downstream areas.

It's not a no-op, because it's an important step that allows me to then gracefully go to a specific downstream area where quality is important, and set some quality recipes at the beginning of a line, and get marginal benefits from occurrences of quality intermediates. So it's going to drop some quality output from the quality inputs into its normal output line. This line can also get some quality modules as well, and again I don't have to worry about them breaking anything downstream.

So I can put quality modules in my copper miners, and I don't need to spend time setting up an additional train nor robots(quality modules come before robots). Quality ingredients is already a pretty marginal chance of occurring, so not that far of a stretch to roll the dice on them ending up in the right place.

The positive result: I've sprinkled some quality modules in plastics, green chips, wires, copper ore... multiple layers and quality ingredients are gonna really accumulate. Set a few recipes to consume intermediates to guarantee quality, etc. This is very low effort, and no risk of clogging with the any out-of-ratio ingredients getting used as normal quality. No need for special routing etc. Just like I can sprinkle around some production/speed modules and maybe disregard perfect ratios for the time being, I could opt instead to sprinkle around quality modules without it feeling like a trap that requires a bunch more effort to get the benefit from something I already put effort into producing.

Now I've increased the amount of quality intermediates I'm getting significantly, without breaking anything, and if I want to take the time, I can route that last output layer of green and red chips to do some quality modules. Fun times, I'm making more quality modules of a higher quality, and then I can go back and sprinkle some more of those around, and the extra quality ingredients will be trickling in.

Now I have that classic problem of, oops this is suboptimal. I've got more quality intermediates coming in, and this line is wasting alot of the higher quality stuff. Either I do the submoptimal incremental improvement of changing another common assembly to uncommon/rare, or I really start thinking about improving the logistics and routing those quality ingredients.

Having these options to me is fun. Do I do the quick and dirty fix? Or do I really devote some time into doing it properly, and have the reward of that hard work?

Absolutely not optimal but that's the point, you don't need to perfect it. It makes it a very approachable benefit, the main points are:
A) It makes it very easy to start getting marginal benefit of quality intermediates without breaking your factory in the absence of having time to deal with logistics.
B) You can incrementally focus on areas where you want to better manage quality ingredients to start maximizing their usage.
C) Gives you a choice of WHERE to focus those optimizations. You can improve handling in a downstream area, routing quality ingredients to a dedicated line along side the common line. Or I can opt to begin creating dedicated logistics upstream to only ship quality intermediates to certain areas specializing in quality. In the current implementation, I can't start producing intermediates upstream if I don't deal with them upstream. The latter implementation allows me to sprinkle quality modules as I please upstream, ignore logistics upstream, and choose to focus on leveraging them in a different downstream area, without risking them breaking other areas where they trickle down to.

This is similar to the concept of rolling upgrades, where you can roll out nonbreaking changes that get half the job done of implementing an improvement.

As it is now, unlocking quality is one of those things that feels like a honey trap. You really want multiple layers of intermediates producing quality, so that you can be building up to having some rare locked recipes in final products.

KeepGridButton wrote: ↑Wed Nov 06, 2024 12:43 am ---snip---

Ahhhh wait I see. The benefit here is that you don't have to retool your factory immediately whenever you want to slap quality modules into something; you can just extend whatever production lines slightly.

Yeah okay, I can see that. Also on the technical side if it downgrades the quality on insertion you don't actually have to implement a way of stacking different quality items on the same slot either (from a technical development side of things).

I think I'd still prefer the idea where the machine just operates on whatever quality ingredients it gets and then that quality translates to output; but I will happily take this suggested solution too as an improvement for sure; nice. I dig it.