Don't trash shared ingredients on recipe change / Improve 'Set Recipe' throughput

Post your ideas and suggestions how to improve the game.

Moderator: ickputzdirwech

Soul-Burn
Long Handed Inserter
Long Handed Inserter
Posts: 56
Joined: Sun Jan 31, 2021 9:07 pm
Contact:

Keep same items when setting recipe to a similar recipe

Post by Soul-Burn »

TL;DR
When switching recipes automatically, items which are shared between the recipes should remain in the machine

What?
When switching recipes, all ingredients and results are put into the dump inventory and have to be removed before the recipe changes.
Many times, the other recipe uses similar items e.g. switching between modules or medium/large power poles.
It would be more efficient if items that exist in both the old and the new recipe would be placed in their respective inventories.
At the minimum, for ingredients, but possibly also for products.
Why?
Simplifies certain builds (modules, poles) and more efficient as it does not require pulling out so many items.
Dreepa
Long Handed Inserter
Long Handed Inserter
Posts: 84
Joined: Sat Nov 18, 2017 11:36 am
Contact:

Re: Improve 'Set Recipe' throughput/simplicity

Post by Dreepa »

I was also confused by this.

I made all 5 logistic chests in one assembler, switching recipes, and I was like: "Why the heck does it not work?"

Until I realized, that I need to remove the trash from the assembler, before it starts another recipe, but it didn't occur to me that this would be necessary, because they all have the same ingredients.

What I intuitively expected was that the assembler already has the required items for the other recipe, since they are same.
Made no sense to me that I have to unload these ingredients, just to load them again from and into the same machine.
Koub
Global Moderator
Global Moderator
Posts: 7937
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Improve 'Set Recipe' throughput/simplicity

Post by Koub »

[Koub] Merged into an older thread with the same suggestion.
Koub - Please consider English is not my native language.
Scyth3
Burner Inserter
Burner Inserter
Posts: 11
Joined: Thu Jul 30, 2015 11:47 pm
Contact:

Re: Improve 'Set Recipe' throughput/simplicity

Post by Scyth3 »

I think this is bugged. Or definitely a regression.

For example when switching the recipe manually (ie the gear icon) inserters now remove ingredients as "trash" even if it shares the same ingredients, for example assembly 1 to repair packs.

Also switching using circuits on a Foundry wastes all input molten metal input with the result that using foundries with "Set Recipe" circuit results in a huge waste or much more complex circuits than necessary. Related it flickers the pipe input resulting in visual "glitches".

Honestly I'd revert the change, seems against the current objective of reducing unecessary complexity (temp on Nuclear Reactors, simplified Decider combinator, selector combinator).

I simply avoid using "Set Recipe" as I find it not fun as it is now.
zig1000
Inserter
Inserter
Posts: 20
Joined: Fri Oct 25, 2024 9:57 pm
Contact:

Re: Improve 'Set Recipe' throughput/simplicity

Post by zig1000 »

Scyth3 wrote: Fri Nov 22, 2024 10:09 pm Also switching using circuits on a Foundry wastes all input molten metal input with the result that using foundries with "Set Recipe" circuit results in a huge waste or much more complex circuits than necessary.
I believe this is only true if the attached pipe contains a different fluid / is full. When possible machines changing recipes instantly push both in/out fluids into any attached pipe, only deleting it as a last resort if there's literally nowhere to put it. That's WAI in my eyes (an entire class of sushi-pipe-based builds would suffer badly otherwise).

Let's please keep this thread on-topic to the original throughput-related requests and not mix in miscellaneous bugs or get into the weeds of whether ingredient-shuffling is inconvenient or an actual bug. I created this thread because several others lumped multiple issues together which lead to them being closed as fixed/WAI, and creates extra work for mods.
Scyth3
Burner Inserter
Burner Inserter
Posts: 11
Joined: Thu Jul 30, 2015 11:47 pm
Contact:

Re: Improve 'Set Recipe' throughput/simplicity

Post by Scyth3 »

I disagree, it's related to a Set Recipe change and seems mods decided to merge the topics (including the bug threads) so they seem to agree on that too.

On the foundry deleting it's true, it will only delete when the pipe is full, yet moving the ingredients back to the pipe I would expect not to delete them and instead place them back to the ingredient slot when it's the same liquid with the same quantity.

Deleting means I need to specifically set some a tank for buffer and extra conditions (less simple) or else simply assume the cost of foundries working extra for the deleted products (less throughput).
Pharotek
Manual Inserter
Manual Inserter
Posts: 1
Joined: Thu Nov 28, 2024 11:48 am
Contact:

Re: Improve 'Set Recipe' throughput/simplicity

Post by Pharotek »

You have my support, this is needed for some tweaks in space stations
User avatar
MrGrim
Fast Inserter
Fast Inserter
Posts: 244
Joined: Sat Apr 09, 2016 7:58 pm
Contact:

Re: Improve throughput of 'Set Recipe'

Post by MrGrim »

zig1000 wrote: Thu Nov 07, 2024 11:04 pm Reworded one more time, hopefully it's clear now
The problem is that the subject doesn't address the cause, only a symptom. If a dev is skimming the active topics, it doesn't effectively describe what needs to change. If they're looking for possible things to work on, only mentioning a symptom raises the barrier to understanding what is being asked for.

Something like the following is more direct:

"Allow re-use of ingredients when changing assembler recipe via circuit network (a better fix for 117890)."

Also, as stated in the bug report, the devs are not interested in the throughput side effects (viewtopic.php?p=628238#p628238). So making that the primary talking point will not be very convincing.

This change in behavior has other problems such as making circuit based dynamic factories far more complex to design and is not intuitive behavior. Most anyone first attempting such designs will get confused about the lack of re-use as I've seen several confused posts on the community Discord server about it (e.g. https://discord.com/channels/1396775903 ... 0197652552).
spacedog
Long Handed Inserter
Long Handed Inserter
Posts: 65
Joined: Fri Mar 27, 2020 5:05 am
Contact:

Re: Don't trash shared ingredients on recipe change / Improve 'Set Recipe' throughput

Post by spacedog »

On a related note, this bug fix destroyed the throughput for switching recipes with fluid outputs. You can't quickly pump out the output fluids anymore because of this, and instead have to wait for them to slowly drain on their own.

Recipe switching as a whole has taken quite a beating since 2.0 launched, and is in pretty rough shape right now from a usability standpoint. I really hope it can get some love once the bug situation dies down a bit. :(
User avatar
Khazul
Fast Inserter
Fast Inserter
Posts: 152
Joined: Fri Sep 03, 2021 4:47 am
Contact:

Re: Don't trash shared ingredients on recipe change / Improve 'Set Recipe' throughput

Post by Khazul »

spacedog wrote: Tue Dec 10, 2024 7:09 pm On a related note, this bug fix destroyed the throughput for switching recipes with fluid outputs. You can't quickly pump out the output fluids anymore because of this, and instead have to wait for them to slowly drain on their own.

Recipe switching as a whole has taken quite a beating since 2.0 launched, and is in pretty rough shape right now from a usability standpoint. I really hope it can get some love once the bug situation dies down a bit. :(
I have high speed dynamic recipes on some machines with fluids in and out (epic/legendary production machines with beacons etc). I just surround the thing was enough pumps to clear out the fluids quickly and serve as flow direction values etc, for eg a foundry that uses most of the foundry recipes for both iron and copper. It works fine and change recipes quickly. The slow bit in changing recipes is the subject of this post and that is emptying the solid trash out, not the fluid change.

For switching input fluids I use a tanks and a pair of pumps for each fluid with one reversed - so one pump makes the fluid available, while the other pulls it back when the recipe changes to clear the machine's fluid input. Of course on the other side of the pumps from the machine, you need to have a tank with enough space to pump the fluid back. For fluid outputs I just have a pump again to clear the fluid away so that the machine can quickly switch to making another fluid.

I have a small ship that time-shares a single chemlabs for both fuel types and manages to support 1500unit/sec combine fuel use so basically the machine is making over 3k/sec combined fuels, while another switches between ice->water (out), explosives and coal which both need water in.
spacedog
Long Handed Inserter
Long Handed Inserter
Posts: 65
Joined: Fri Mar 27, 2020 5:05 am
Contact:

Re: Don't trash shared ingredients on recipe change / Improve 'Set Recipe' throughput

Post by spacedog »

Khazul wrote: Tue Dec 10, 2024 7:51 pm I have high speed dynamic recipes on some machines with fluids in and out (epic/legendary production machines with beacons etc). I just surround the thing was enough pumps to clear out the fluids quickly and serve as flow direction values etc, for eg a foundry that uses most of the foundry recipes for both iron and copper. It works fine and change recipes quickly.
It changes recipes quickly, but if you don't wait for all the output fluid to drain it's discarding a big chunk of the output fluid. And pumps no longer interact with the internal output buffer as of 2.0.13, so those pumps and tanks might not be doing everything you think they're doing. You might want to single-step through it in the editor and watch what's happening, unless you don't care about the waste.
Khazul wrote: Tue Dec 10, 2024 7:51 pm The slow bit in changing recipes is the subject of this post and that is emptying the solid trash out, not the fluid change.
You're right, there are multiple throughput challenges. I guess having to remove the outputs is a thing no matter what. If they at least fix it so things in the trash slots stay in the inputs (e.g. iron plates used for both gears and pipes) then that would be a big win. Sorry if this distracted from that ask in this thread.
Khazul wrote: Tue Dec 10, 2024 7:51 pm I have a small ship that time-shares a single chemlabs for both fuel types and manages to support 1500unit/sec combine fuel use so basically the machine is making over 3k/sec combined fuels, while another switches between ice->water (out), explosives and coal which both need water in.
I debated asking this but my curiosity is killing me: The only way to get that level of fuel production from a single chemical plant requires a speed beacon... so you essentially replaced a 3x3 chem plant with a 3x3 beacon. I can totally understand using recipe switching to get more out of an existing machine that's mostly idle, to avoid adding a second mostly idle machine. But I'm curious what is the point (other than over-engineering for over-engineering's sake) if it's not saving space?
nzer
Long Handed Inserter
Long Handed Inserter
Posts: 56
Joined: Sat Jun 24, 2023 11:30 pm
Contact:

Re: Don't trash shared ingredients on recipe change / Improve 'Set Recipe' throughput

Post by nzer »

spacedog wrote: Tue Dec 10, 2024 7:09 pm On a related note, this bug fix destroyed the throughput for switching recipes with fluid outputs. You can't quickly pump out the output fluids anymore because of this, and instead have to wait for them to slowly drain on their own.
Maybe I'm misunderstanding what's happening, but I'm 99% sure fluids are ejected from machines immediately when the recipe changes, and are discarded if there isn't space for them. You don't need to pump anything, just ensure the surrounding pipe system has enough empty space.
spacedog
Long Handed Inserter
Long Handed Inserter
Posts: 65
Joined: Fri Mar 27, 2020 5:05 am
Contact:

Re: Don't trash shared ingredients on recipe change / Improve 'Set Recipe' throughput

Post by spacedog »

nzer wrote: Wed Dec 11, 2024 4:26 am Maybe I'm misunderstanding what's happening, but I'm 99% sure fluids are ejected from machines immediately when the recipe changes, and are discarded if there isn't space for them. You don't need to pump anything, just ensure the surrounding pipe system has enough empty space.
Wow... you are right, and that was unexpected. I just never had enough extra pipe before the pump. This feels unintended, so I'm not sure if it's a good idea to rely on it, but thanks for pointing it out. Clearly I'm not doing a great job reverse engineering all the undocumented behavior. :(
User avatar
Khazul
Fast Inserter
Fast Inserter
Posts: 152
Joined: Fri Sep 03, 2021 4:47 am
Contact:

Re: Don't trash shared ingredients on recipe change / Improve 'Set Recipe' throughput

Post by Khazul »

spacedog wrote: Wed Dec 11, 2024 2:22 am
I debated asking this but my curiosity is killing me: The only way to get that level of fuel production from a single chemical plant requires a speed beacon... so you essentially replaced a 3x3 chem plant with a 3x3 beacon. I can totally understand using recipe switching to get more out of an existing machine that's mostly idle, to avoid adding a second mostly idle machine. But I'm curious what is the point (other than over-engineering for over-engineering's sake) if it's not saving space?
1 speed beacon, 3* modules, 1 chemlab, 3* productivity. All legendary. It would produce about 4.4k units/sec if it didnt switch, but manages to almost keep up with 2100 unit combined fuel use to fuel 7x legendary thruster (top speed just over 500Km/s). There is another similar setup doing water, explosive and coal. I did try time-sharing everything through one chemlab but that killed fuel supply reliability.

As for saving space - debatable as it needs additional pumps (2 x epic pump to output each per fluid into its correct tank to handle the throughput, so 4 pumps), but the speed beacon(s) would be needed anyway to get the required flow. But yes it was an engineering 'curiosity' and that is what the blueprint is named - 'Curiosity' :)
Post Reply

Return to “Ideas and Suggestions”