Factorio Forums

Explanation:
It used to be possible to make a smart mall that could build pretty much any number of intermediaries with just one constant combinator and one arithmetic combinator. However, The devs changed how the "set recipe" function works due to a bug they where trying to fix.

Before, If a machine recieved a different "set recipe" command for item B while it was in the process of building item A, it would ignore item B and continue building it's current iteration of item A. This makes sense, changing recipes is innefecient and slows down your factory, and changing recipes mid build could result in infinite recipe-changing-thrashing like seen in the video

However, the devs changed it so that now a machine will switch recipes right away and dump it's inventory, destroying the production speed of these machines (they just constantly thrash around, and spend their time loading and unloading instead of crafting ). not only this, but now it requires significantly more circuitry to actual make these smart malls work at all if they craft intermediates (ex, crafting yellow and blue inserters like in the video). They have destroyed the simplicity, accessibility, speed, and appeal of small smart malls.

I really like this game and respect the devs, but this is not a correct bugfix. A better solution might be to give us an "allow interupt" tickbox under the "set recipe" tickbox. This tickbox should forbid the machine from changing recipes except after finishing it's current recipe. this would allow us to choose between the old functionality and the new functionality.

also, machines now do not run at all if there are any items in the machines trash slot. This should be changed, and instead the machines should stop running if the items in the trash slot are greater than some value. Its completely natural for items to exist in the trash slots temporarily upon changing a recipe. my machine throughput should not be strangled just because the machine is switching recipes on occasion. I understand the devs might consider having large number of items in the trash slot as exploity though, So I won't die on this hill.

Video of how the set recipe function used to work:
https://www.reddit.com/r/factorio/comme ... simple_as/

Video of the new functionality causing havok and endless loops of shuffling around items:

https://www.reddit.com/r/factorio/comme ... plest_and/



edit: this quote from the friday facts 394 states the intended behavior.

"Another important part about setting the recipe, is that it will only check the 'Set recipe' signal when it finishes crafting, so it won't cancel any in-progress crafts, and you don't have to worry about precise timing."

this rule is not being followed in order to fix a different bug, which is really throwing out the baby with the bathwater!

I'm not able to reproduce assemblers interrupting their own crafts when switching recipes. You are correct though that assemblers now stop working while there are items in their trash slots, which severely hurts throughput. Given there's no practical way to stop assemblers from being overfilled, this behavior is not workable at all and should be reverted.

I have the same issue as OP. The recipe is changed immediately after the conditional logic sees that there is e.g. now too few intermediate products (because they were taken to be used in the previous recipe).

The problem is i think exaggerated because the logic of inserting ingredients was also possibly changed (?). Now the inserter is inserting maximum number of each ingredient in their order from left to right. This does not make sense, as for example >50 steel will be inserted before any copper wires are in, during which the product cannot be made.

Check the video and copy my design. Set inserter stack size to 1 to guarantee it happens.

Thanks for the report however nothing here is broken. The recipe will not be set *if a craft is in progress* this is still true and unchanged with the recent changes.

Specifically, you can see in the video linked the crafting for the recipe has not started and so the recipe signal changing changes the active recipe. In the old behavior, it would also get blocked on the trash slots having items and also wouldn't change the recipe in that state.

I'm sure devs are really busy right now but i really hope they will find a solution for this more 'advanced' problem later, maybe can be put on a fix-later list?

Rseding91 wrote: ↑

Wed Oct 30, 2024 12:48 pm

Specifically, you can see in the video linked the crafting for the recipe has not started and so the recipe signal changing changes the active recipe. In the old behavior, it would also get blocked on the trash slots having items and also wouldn't change the recipe in that state.

I'm sorry, but this is simply not true that it got blocked on the old behavior. I linked one video displaying the old functionality, and one video displaying the new functionality.

With the old functionality, I built an automated mall that can build almost any item with just a handful of assemblers.

With the new functionality, my beautiful mall no longer works, and would require significantly more circuitry to work right.

I can share the exact blueprints with you if you like, or send additional videos. The new system is simply much less intuitive and simple to work with.

jojojay wrote: ↑

Wed Oct 30, 2024 4:50 pm

Rseding91 wrote: ↑

Wed Oct 30, 2024 12:48 pm

Specifically, you can see in the video linked the crafting for the recipe has not started and so the recipe signal changing changes the active recipe. In the old behavior, it would also get blocked on the trash slots having items and also wouldn't change the recipe in that state.

I'm sorry, but this is simply not true that it got blocked on the old behavior.

Yes it is. The old behavior would not set-recipe if the input slots had items and the trash inventory had items. That is what made it work in your videos. If the output inserters were too slow, or the input inserters were too slow, it would set-recipe with half of the ingredients put into the machine in the old behavior.

Although thinking about it more I think you are misunderstanding what I'm referring to by "get stuck". I mean "get stuck" as in: it would not set-recipe to a new recipe if the trash inventory had items and the source inventory had items. In that sense the set-recipe stuck from being able to set the new desired recipe. That is the behavior you relied on in the past.

I think I have found a solution that still makes it possible to build different things in the assembler with just one combinator. The items in the assembler and inserter can be read out and added to the items from the chest. This means that the held items are not considered missing when they are in the machine, but only when it is actually processed. So the recipe does not change during the load/unload phase.
Copy blueprint