Add assembler "Finish current craft when disabled" circuit behavior

[Milichip]

(This is an alternate suggestion of thread viewtopic.php?t=126752 after being told cancelling cannot exist due to infinite crafting)

TL;DR
Add this option:

factorio_Gv5jPdDeE1.png (80.03 KiB) Viewed 1265 times

What?
The "finish craft" option would finish the current craft even when the assembler is disabled, but would NOT start another craft while disabled.


Why?
If the "set recipe" signal is turned off while the machine is disabled and hasn't started a craft, it will immediately switch to the recipe since there is no craft to finish.
This allows being able to read the output of the machine to decide if you wish to continue the craft or stop: this can be useful in cases where you use quality modules and want to continue producing until you've made a rare product, or if you wish to make a specific count of items with probabilistic recipes or recipes that produce multiple products at once.
Currently, this is not possible without completely removing the recipe and setting it back with "set recipe", or by starving the machine of items so that it doesn't immediately start a craft.

[computeraddict]

This seems like it could be done with a decider and Read Recipe (F)inished, Read (W)orking, (E)nable/Disable and an external Request (D)isable When Finished signal.

Condition on assembler is enable if E > 0

Condition on Decider is:

(D=0)or((D>0)and(W>0)and(F=0)) -> 1 E

Assembler is wired to the input and output of the decider, Disable signal is wired to the input.

[Milichip]

This seems like it could be done with a decider and Read Recipe (F)inished, Read (W)orking, (E)nable/Disable and an external Request (D)isable When Finished signal.

Condition on assembler is enable if E > 0

Condition on Decider is:

(D=0)or((D>0)and(W>0)and(F=0)) -> 1 E

Assembler is wired to the input and output of the decider, Disable signal is wired to the input.

As shown on the linked thread, the fastest possible disable based on finished products does NOT stop the next craft from occuring:

factorio_g07y98hTrw.png (79.05 KiB) Viewed 1231 times

So adding an extra decider to the delay would not help matters.

As said in the original post, you HAVE to know you want to disable the machine ahead of time, or starve it of ingredients.

[computeraddict]

As shown on the linked thread, the fastest possible disable based on finished products does NOT stop the next craft from occuring:
factorio_g07y98hTrw.png

So adding an extra decider to the delay would not help matters.

As said in the original post, you HAVE to know you want to disable the machine ahead of time, or starve it of ingredients.

What's the objective of preventing it from ingesting the next set of materials...?

[Milichip]

As shown on the linked thread, the fastest possible disable based on finished products does NOT stop the next craft from occuring:
factorio_g07y98hTrw.png

So adding an extra decider to the delay would not help matters.

As said in the original post, you HAVE to know you want to disable the machine ahead of time, or starve it of ingredients.

What's the objective of preventing it from ingesting the next set of materials...?

Making an exact amount of items.
For example, if you want exactly 1 uranium-235, and you want to stop IMMEDIATELY once you get a single one, then currently it is not possible to do so without starving the machine of input items.
This doesn't sound very useful in isolation, but there are greater stakes when you are upcycling rare/legendary quality earlier in the game with expensive ingredients, or in my current use case, making an exact amount of items in a programmable mall - WITHOUT having to hard-code the # of products a recipe produces.

If you don't know, once the machine has "hidden" the ingredients, you cannot switch recipe with "set recipe" anymore until it is finished, which is relevant to my mall which always overproduces by 1 craft.
And yes, I could just fix it by adding a decider on every single assembler that checks if the machine is working and if so substract 1 craft from the signal, however, "1 craft" can mean "1 item" but it can also mean "2 items" in the case of underground belts or "10 items" in the case of concrete, and specifying all the data manually for every rarity is a pain in the ass, and also not possible for probabilistic recipes if you wished to have an exact amount of uranium-235 produced in your mall.

[computeraddict]

Making an exact amount of items.
For example, if you want exactly 1 uranium-235, and you want to stop IMMEDIATELY once you get a single one, then currently it is not possible to do so without starving the machine of input items.
This doesn't sound very useful in isolation, but there are greater stakes when you are upcycling rare/legendary quality earlier in the game with expensive ingredients, or in my current use case, making an exact amount of items in a programmable mall - WITHOUT having to hard-code the # of products a recipe produces.

If you don't know, once the machine has "hidden" the ingredients, you cannot switch recipe with "set recipe" anymore until it is finished, which is relevant to my mall which always overproduces by 1 craft.
And yes, I could just fix it by adding a decider on every single assembler that checks if the machine is working and if so substract 1 craft from the signal, however, "1 craft" can mean "1 item" but it can also mean "2 items" in the case of underground belts or "10 items" in the case of concrete, and specifying all the data manually for every rarity is a pain in the ass, and also not possible for probabilistic recipes if you wished to have an exact amount of uranium-235 produced in your mall.

Are you going to disassemble it after making that exact amount and never make another ever again? If so, it doesn't matter that it grabs another set of ingredients because you get them back when the craft is canceled. If not, then it doesn't matter if it starts on the next craft but gets stalled partway because it was just going to do that later.

Perhaps you missed some part of the explanation? Because I can't see why this matters.

[Milichip]

Making an exact amount of items.
For example, if you want exactly 1 uranium-235, and you want to stop IMMEDIATELY once you get a single one, then currently it is not possible to do so without starving the machine of input items.
This doesn't sound very useful in isolation, but there are greater stakes when you are upcycling rare/legendary quality earlier in the game with expensive ingredients, or in my current use case, making an exact amount of items in a programmable mall - WITHOUT having to hard-code the # of products a recipe produces.

If you don't know, once the machine has "hidden" the ingredients, you cannot switch recipe with "set recipe" anymore until it is finished, which is relevant to my mall which always overproduces by 1 craft.
And yes, I could just fix it by adding a decider on every single assembler that checks if the machine is working and if so substract 1 craft from the signal, however, "1 craft" can mean "1 item" but it can also mean "2 items" in the case of underground belts or "10 items" in the case of concrete, and specifying all the data manually for every rarity is a pain in the ass, and also not possible for probabilistic recipes if you wished to have an exact amount of uranium-235 produced in your mall.

Are you going to disassemble it after making that exact amount and never make another ever again? If so, it doesn't matter that it grabs another set of ingredients because you get them back when the craft is canceled. If not, then it doesn't matter if it starts on the next craft but gets stalled partway because it was just going to do that later.

Perhaps you missed some part of the explanation? Because I can't see why this matters.

If you don't care about this, that's fine. But it does matter.
If you want to craft modular armor, you want 1 modular armor. You don't want 2 (in this context at least). And if you do not wish to hardcode the fact that the modular armor recipe makes 1 ingredient and not 2, then you must read the amount of products it will produce.
However, while you are reading the amount of products, it will have already started another craft. That is a problem because now you cannot switch that assembler's recipe via "set recipe", and if you want the ingredients back you will have to deconstruct it.

You might say "that's fine, since it crafts one you can predict how many it will make and send the signal BEFORE it finishes the last item and after it has started working". And that'll work fine.
Now take the same example, but with uranium fuel cells. One craft of uranium fuel cell produces 10 cells. So if you only want 8 to make 2 portable fission reactors, what do you do? Do you also hardcode the fact that the recipe produces 10 items, and remove 10 from the signal once it has started working?
And now take into account literally every recipe. All underground belts and pipes craft 2 at once. Superconductors, mines, a lot of the sciences have multiple products too.

If you want it to be neat and tidy without hardcoding the # of products created by every single recipe into a constant combinator for every possible rarity they have, not to mention the recipes for which it is impossible to do so (probabilistic recipes), then this is a valid solution for the problem.

And maybe that's useless to you, that's fine. If you don't care that you overproduce by 1 craft, or if you don't care to hardcode the # of products per recipe, that's completely fine.
In the meantime, I have made a recursive automated mall operated by "set recipe", and it works great but spews out an extra craft all of the time. And while it is not a major problem to have 101 or 102 belts instead of 100, it is not as satisfying, it is not "machine-like", hence why I am asking for this feature.
And I would rather not have to put in a constant combinator "2 yellow underground belts, 2 yellow uncommon underground belts, 2 yellow rare underground belts..." for every single item that has multiple products. And then the same for every item that produces 1 product too, if I want to avoid needing an extra decider combinator everywhere too.

Again, if you don't need the feature, that's completely fine, but that doesn't mean you should be telling me it is a useless feature because that is simply ignorant to the uses it could have.

[computeraddict]

If you don't care about this, that's fine. But it does matter.
If you want to craft modular armor, you want 1 modular armor. You don't want 2 (in this context at least). And if you do not wish to hardcode the fact that the modular armor recipe makes 1 ingredient and not 2, then you must read the amount of products it will produce.
However, while you are reading the amount of products, it will have already started another craft. That is a problem because now you cannot switch that assembler's recipe via "set recipe", and if you want the ingredients back you will have to deconstruct it.

Or manually clear the recipe.

You might say "that's fine, since it crafts one you can predict how many it will make and send the signal BEFORE it finishes the last item and after it has started working". And that'll work fine.
Now take the same example, but with uranium fuel cells. One craft of uranium fuel cell produces 10 cells. So if you only want 8 to make 2 portable fission reactors, what do you do? Do you also hardcode the fact that the recipe produces 10 items, and remove 10 from the signal once it has started working?

Why not just have it learn the recipes and store them in a memory cell if you don't want to manually set a finite number of non-standard recipes? Even just hand coding them once would be less work than the feature you're requesting, btw.

And now take into account literally every recipe. All underground belts and pipes craft 2 at once. Superconductors, mines, a lot of the sciences have multiple products too.
If you want it to be neat and tidy without hardcoding the # of products created by every single recipe into a constant combinator for every possible rarity they have, not to mention the recipes for which it is impossible to do so (probabilistic recipes), then this is a valid solution for the problem.

You haven't even cracked the surface, though! What about productivity? Do you want it to disable after a bonus craft? Or only after a standard craft? Or only when the productivity bonus is less than some configurable percentage?

And maybe that's useless to you, that's fine. If you don't care that you overproduce by 1 craft, or if you don't care to hardcode the # of products per recipe, that's completely fine.
In the meantime, I have made a recursive automated mall operated by "set recipe", and it works great but spews out an extra craft all of the time. And while it is not a major problem to have 101 or 102 belts instead of 100, it is not as satisfying, it is not "machine-like", hence why I am asking for this feature.

Again, if you don't need the feature, that's completely fine, but that doesn't mean you should be telling me it is a useless feature because that is simply ignorant to the uses it could have.

Of course it's useless. There's so few things in this game that you only need finite numbers of, and nearly everything else is "produce this constantly, forever." That includes all the sciences, concrete which is used by the thousands, fuel cells for reactors, belts, underground pipes, etc. etc. The tiny number of things you really only need a handful of ever is tiny and you could just feed the materials by hand.

And if you don't care about preserving productivity progress you can just change recipe during the craft, wait for the assembler's contents to be empty, then queue another craft if you're below your target quantity.

[Muche]

As I see it, this option would be usable only in the case of fixed recipe + circuit controlled enabling.
With it, the currect craft cycle can end, its result evaluated, and if it was not desired, enable the machine back immediately, as ingredients have been already inserted.
If the result was indeed desired, the machine then sits unused until the next time the product is needed.
As computeraddict alluded to, it doesn't matter that the required ingredients were "pre-consumed" a while ago.

If the machine is utilizing dynamic recipe setting, unused ingredients moving to trash slots upon recipe changes will have to be handled anyways.
Then pre-emptively clearing the recipe signal when crafting the last item will make sure only one item is crafted, making this suggested option redundant.
Yes, it does mean that if the desired product has lower than 100% chance to be obtained (as is the case with Uranium processing or quality crafting), this would lead to a loop of setting the recipe, loading the ingredients, crafting one cycle, clearing the recipe and all ingredients.
That's the trade-off of making sure only one product is crafted. The machine utilization goes down.

[Milichip]

If the result was indeed desired, the machine then sits unused until the next time the product is needed.

No, the machine does not sit unused -at least in my use case- it instead switches recipe. As I've already mentioned multiple times, you cannot switch recipes (via "set recipe" AKA automatically) if the current craft is not finished.

Then pre-emptively clearing the recipe signal when crafting the last item will make sure only one item is crafted, making this suggested option redundant.

The entire point is that you don't know it is the last item until it is crafted. Either because it's probabilistic or because you don't want to hardcode the # of products of every item.

Yes, it does mean that if the desired product has lower than 100% chance to be obtained (as is the case with Uranium processing or quality crafting), this would lead to a loop of setting the recipe, loading the ingredients, crafting one cycle, clearing the recipe and all ingredients.
That's the trade-off of making sure only one product is crafted. The machine utilization goes down.

First of all, if you are setting assemblers via "set recipe" automatically, then the % of the machines that are actively being used vs how many you have in total can easily be SIGNIFICANTLY higher than a normal mall or your base in general as assemblers very often sit with empty input or full output, so if you think "machine utilization" is the tradeoff that is completely incorrect.
Second, if you do what I said of setting every nº of products per recipe in a constant combinator, this tradeoff will not exist either except for probabilistic recipes.
And lastly, even with this suggested change, the machines would still be disabled for a few ticks after every craft anyway, so that would still be a drawback. The only difference is it wouldn't spew items out after every craft.

Why not just have it learn the recipes and store them in a memory cell if you don't want to manually set a finite number of non-standard recipes? Even just hand coding them once would be less work than the feature you're requesting, btw.

"Learn the recipes"? That sounds annoying as hell to implement, at that point you might as well hardcode it.
And also, yes it is less work, but hardcoding the products is very ugly and a "gimmicky" solution to the problem. I have also suggested a way to obtain the # of products in another thread, so that is unrelated here.
This solution is also more robust as it not only handles the mentioned recipes, but probabilistic ones also, which is a lot more future-proof and mod-friendly (if some psycho wants to make a mod where every recipe has a 50% chance of failing).

You haven't even cracked the surface, though! What about productivity? Do you want it to disable after a bonus craft? Or only after a standard craft? Or only when the productivity bonus is less than some configurable percentage?

I don't see how this feature would make it harder to detect than it currently is? If anything it would help it by providing another option? Sounds pretty good to me.

Of course it's useless. There's so few things in this game that you only need finite numbers of, and nearly everything else is "produce this constantly, forever." That includes all the sciences, concrete which is used by the thousands, fuel cells for reactors, belts, underground pipes, etc. etc. The tiny number of things you really only need a handful of ever is tiny and you could just feed the materials by hand.

Ok, you don't care about making exact amounts of items, and you don't care about the elegance of having a machine craft EXACTLY the amount of items you asked for and no more. Got it. You do you, but since this feature does not hinder you whatsoever and you cannot deny that it has a use even if you don't care about the use, then please go complain about other suggestions instead, thanks.

[computeraddict]

Ok, you don't care about making exact amounts of items, and you don't care about the elegance of having a machine craft EXACTLY the amount of items you asked for and no more. Got it. You do you, but since this feature does not hinder you whatsoever and you cannot deny that it has a use even if you don't care about the use, then please go complain about other suggestions instead, thanks.

It's already possible, you've said so, you're just too lazy to enter the requisite data to your machine or implement an automatic way to collect it.

The hindrance is it's dev time not spent fixing bugs or adding features that actually have use for more than one dude.

[Tertius]

What about a "start craft" option in the assembler?

You feed it some signal. Function: start crafting only if this signal is > 0.

This overlaps with the "activate/deactivate" function but is different. It makes the machine start a craft only if this signal is >0. It can be pulsed to an idle machine with enough ingredients to actively start a craft and prevent it from starting automatically. As long as it is 0, the machine will not start another craft after the previous has finished. Since no other craft is started, you can change a recipe and get it changed immediately while this signal is 0.
With this signal, you can postpone starting the next craft until your lengthy decision process finished whether you want another craft or not.

Can replace the activate/deactivate option, in my opinion. It's how the activate/deactivate option should work in the first place. The deactivate option stops the machine mid-craft, which is strange and of no real use, in my opinion. If I started a craft, I want the result. Not having the ingredients in limbo for an undecided time. For machine control I want an option to control the starting of the craft, not the crafting process itself.

The only use of the deactivate option I see is if I absolutely not want a result now. However, in all my years of playing I never need that. But I did need an option to control the start of a craft.

[Milichip]

What about a "start craft" option in the assembler?

You feed it some signal. Function: start crafting only if this signal is > 0.

This overlaps with the "activate/deactivate" function but is different. It makes the machine start a craft only if this signal is >0. It can be pulsed to an idle machine with enough ingredients to actively start a craft and prevent it from starting automatically. As long as it is 0, the machine will not start another craft after the previous has finished. Since no other craft is started, you can change a recipe and get it changed immediately while this signal is 0.
With this signal, you can postpone starting the next craft until your lengthy decision process finished whether you want another craft or not.

Can replace the activate/deactivate option, in my opinion. It's how the activate/deactivate option should work in the first place. The deactivate option stops the machine mid-craft, which is strange and of no real use, in my opinion. If I started a craft, I want the result. Not having the ingredients in limbo for an undecided time. For machine control I want an option to control the starting of the craft, not the crafting process itself.

The only use of the deactivate option I see is if I absolutely not want a result now. However, in all my years of playing I never need that. But I did need an option to control the start of a craft.

Works for me as well, yeah.

Also the "disable" option may be useful to save power in some extremely niche cases, so I don't think it should necessarily be completely gone even if I don't have a use for it.
Then again, electric furnaces and recyclers and other machines don't have an option to disable, and they consume a lot more power, so I also wouldn't be sad to see it gone or having more consistency on having that option.

Either way, I only care about not starting crafts, so whether it's a replacement or it's having both, I'm happy with it.

[Tertius]

I just brought up an alternative to your proposal, because I feel your proposal is not generalized enough. It's too specific, so it could lead to unexpected edge cases. It handles one specific case you're not happy about.

The proposal to control starting a craft is generic, because it enables the player to just control a currently automatic functionality. Nothing more.

[Milichip]

I just brought up an alternative to your proposal, because I feel your proposal is not generalized enough. It's too specific, so it could lead to unexpected edge cases. It handles one specific case you're not happy about.

The proposal to control starting a craft is generic, because it enables the player to just control a currently automatic functionality. Nothing more.

I'm pretty sure my feature does the exact same as what you suggested. A "Finish current craft when disabled" checkbox is effectively the exact same as turning the disable into a "don't start next craft". It's just the opposite signal of a "start next craft", but it's the same feature.
I do agree it should be generic and go beyond my use, I have thought about that also but that's not what people were pushing me on.

[Tertius]

I feel you proposal is valid, since it's not feasible to do a workaround. As I stated in another thread, I've given up to craft exact amounts, but a change like these in this thread would definitely make me try to update my automatic mall to produce exact amounts.

It's difficult to say in advance if this would be successful. I guess it would be half successful. Currently, I stuff the assemblers with as many ingredients as possible to ensure continuous production. If a surplus is generated, the surplus is detected but crafting cannot stop because I cannot deactivate the corresponding machine (would hold items mid craft), neither could the recipe be changed because this would eject all items, and if it is decided to craft this item again (if it is an intermediate of high demand - the mall produces all dependent intermediates at the same time to ensure continuous production of the end item), all the items have to be loaded again, which is a prohibitive performance loss.

With the "start craft" functionality, I could just postpone further crafts if there is a (temporary) surplus. A surplus is still generated, but only one craft. It would prevent from all ingredients being used up, which creates much surplus for some items.