Assembler "read amount per craft" circuit network option

[Milichip]

TL;DR
This:

factorio_rSHas9XQlA.png (454.29 KiB) Viewed 396 times

What?
Allow assemblers to read the amount of items created per craft and output that to a specified signal.
For instance, yellow belts, pipes, copper wire, rails and many others have 2 items created per batch of ingredients supplied. Concrete creates 10 instead.
Other recipes that only produce 1 item should still output "1" on that signal of course.


Why?
In short, so I can avoid doing this:

factorio_52INf1zFvI.png (46.33 KiB) Viewed 396 times

Why do I need this? Because I want to automate an assembling machine, and when I request 2 yellow belts to be made, I only need one batch of ingredients, not 2. As a result, I need to divide the requested ingredients by 2 after multiplying by the amount of belts requested (e.g. if I need 6 belts, I would need to multiply the amount of ingredients by 6, then divide by 2).
The selector combinator would also be another valid candidate for this, although personally I would prefer it to be on the assembler itself, or in both.

[Milichip]

Actually, I've been thinking about it, and this would not work for any recipe with multiple outputs, so perhaps it would be best to give it to selector combinators after all.

Perhaps taking in one wire as the recipe, and the other wire as the product you would want the output of.

For example, "Metallic asteroid crushing" on the selector's red input wire and "Iron ore" on the selector's green input wire would make it output 20.

You could also add a built-in "multiplier" setting since some products only have a chance of appearing.
For example, "Metallic asteroid crushing" on the selector's red input wire and "Metallic asteroid chunk" on the selector's green input wire would make it output 0 (from 0.2), but if the selector's multiplier was set to 10 it would output 2.

[Muche]

"Read products", similar to Read ingredients would solve the multiple signals issue.

Regarding asteroids crushings, Uranium processing and other probabilistic recipes, it would have to be decided, what the amount of products means.
Is it the maximum of items produced per craft (so 1 / 1), or is it the average (so 0.20 / 0.007)?
Also, as it is possible to have a modded recipe with, e.g., amount=10, probability=0.1, the answer in this case could be 10 or 1.

[Milichip]

Was thinking more about this, and I also would like to suggest adding "read recipe crafting time" as an option.

It could specify its crafting time in milliseconds, in order to be able to output things like 0.5 seconds (500 milliseconds).

Why?
To automate a mall which would set more assemblers to work if the craft time is high, as well as send the exact rate of items needed per second on a mixed-item conveyor belt.

[Muche]

Was thinking more about this, and I also would like to suggest adding "read recipe crafting time" as an option.

It could specify its crafting time in milliseconds, in order to be able to output things like 0.5 seconds (500 milliseconds).

Why?
To automate a mall which would set more assemblers to work if the craft time is high, as well as send the exact rate of items needed per second on a mixed-item conveyor belt.

This is currently vague as well.
It seems you mean the actual crafting time (so for a fully beaconed SA-legendary foundry crafting belts it would be 2.75 ms or 0.148 ticks). For a modded-quality one even milliseconds unit is too large.
It could also mean the base crafting time (30 ticks).

Note that adding the speed for machines would induct demand for knowing the speed for other entities involved - inserters, belts.
Their current transfer speed can be measured even now (see Creations subforum).
But for your purpose you might want the maximum thoughput. For inserters it's infamously complicated.

[Milichip]

This is currently vague as well.
It seems you mean the actual crafting time (so for a fully beaconed SA-legendary foundry crafting belts it would be 2.75 ms or 0.148 ticks). For a modded-quality one even milliseconds unit is too large.
It could also mean the base crafting time (30 ticks).

Note that adding the speed for machines would induct demand for knowing the speed for other entities involved - inserters, belts.
Their current transfer speed can be measured even now (see Creations subforum).
But for your purpose you might want the maximum thoughput. For inserters it's infamously complicated.

I personally believe milliseconds is good enough for a large majority of uses, but I'm not against specifying your own unit for other more crazy uses.

And no, I don't need any of the other stuff you mentioned.