Crafting machines output needed ingredients.

[Alfonse215]

TL;DR

Crafting machines should be able to output how much of which ingredients the machine is lacking to start a new crafting cycle.

What?

Crafting machines can currently output how many ingredients are consumed in one craft of the current recipe, but they cannot output how many ingredients this particular machine needs to start a craft.

Why?

It would be useful to request precisely one craft worth of ingredients, for things like rocket silos and similar recipes that consume lots of resources.

This is one of the most common use-cases for more fine-grained red/green input/output splitting. You use one wire to get the ingredients needed for one craft, and the other wire to get the current ingredients. Do some subtraction, and you have the value above.

But since more fine-grained wire splitting is unlikely to happen, I suggest simply giving us the value(s) outright.

[mmmPI]

If you want to request precisely "one craft" worth of ressources, you can read the machine receipe and request that as a one time thing, you don't really need to know the currently loaded amount.

But for things like rocket silo, that need a lot of ressources, that's typically where you wouldn't imo request the whole silo worth of ressources, instead you would request a bit of every material and stop loading the machine when its content is above the amount required for the receipe of that particular material. You can do that by either storing the receipe in a combinator when it is set in the machine if you are using dynamic mall, or you can hardcode the receipe in a constant combinator otherwise.

The problem i see with the suggestion is that there's only 2 color of wires, you can use them for "read content" and "set receipe" already. The only way i see you could use the new tickbox being suggested would then be as a replacement of one of those two.

You use one wire to get the ingredients needed for one craft, and the other wire to get the current ingredients. Do some subtraction, and you have the value above.

If you do that then you can't use a wire to set receipe anymore, you are trying to read 2 different things on 2 different wire, but one of them, the ingredient needed for one craft is either hardcoded and thus don't strictly need reading via wire. Or is set dynamically, for which you need a wire , and you can use this for the purpose of comparing with the "current ingredient" in the machine to have the information about the missing ingredients to avoid loading too much in case of a assembly that makes rocket Silo.

[Alfonse215]

But for things like rocket silo, that need a lot of ressources, that's typically where you wouldn't imo request the whole silo worth of ressources, instead you would request a bit of every material and stop loading the machine when its content is above the amount required for the receipe of that particular material. You can do that by either storing the receipe in a combinator when it is set in the machine if you are using dynamic mall, or you can hardcode the receipe in a constant combinator otherwise.

You wouldn't use a memory cell for the ingredients; those don't change until you change the recipe (since you're not reading the contents). And that's when you'd reset the memory cell anyway. You'd use a memory cell to track how many of which items you've inserted, subtracting that from the ingredient amount to determine how much of what to insert.

The problem i see with the suggestion is that there's only 2 color of wires, you can use them for "read content" and "set receipe" already. The only way i see you could use the new tickbox being suggested would then be as a replacement of one of those two.

... right. You'd just read the contents needed for the next craft instead of reading the contents. That's the goal here.

[mmmPI]

You wouldn't use a memory cell for the ingredients; those don't change until you change the recipe (since you're not reading the contents). And that's when you'd reset the memory cell anyway. You'd use a memory cell to track how many of which items you've inserted, subtracting that from the ingredient amount to determine how much of what to insert.

Why would you not read the content ? and use the memory cell to keep track of the number of ingredient that are required ? so that you can solve the use case you mention ?

[Alfonse215]

You wouldn't use a memory cell for the ingredients; those don't change until you change the recipe (since you're not reading the contents). And that's when you'd reset the memory cell anyway. You'd use a memory cell to track how many of which items you've inserted, subtracting that from the ingredient amount to determine how much of what to insert.

Why would you not read the content ? and use the memory cell to keep track of the number of ingredient that are required ? so that you can solve the use case you mention ?

How would the memory cell get the number of ingredients without asking the assembler for it? And if you're asking the assembler for the number of ingredients, it cannot also give you an accurate count of the current contents.

That's the whole issue: you cannot read both to do the subtraction, so you have to get the other information in another way.

[mmmPI]

0eNrtWM1y2zgMfpUdHnepjvVnW57ZPkVvGY+GlmCbE4nSklRSN+N3L0A5UuwyjbRtdnJYXwwLxAfwAwhQfmK7qoNWS2XZ5omVYAotWysbxTbsS6d3UsEftbgHzTiTRaMM29w9MSMPSlRkoUQNuFQYA/WukuoQ1KI4olUQszOaqBK+sk145h4j0+2MFc7ZuDQ6bzkDZaWV0DtzP0656uodhrEJucees7Yxso/7iSFMEK45O+F3HJ7J+Q1INIAILe2xBiuLoGhq3K+wjfbhJZ/SAZGzUmooej06QmKsbqp8B0fxINEejUbgHNWlAzOk2EttbD6yYU8tBfIgte3wybg9tyIA5JP4MUAwhIWbpnQtOGta0OKSrb/Qsuls283GRoLYP6hGglDVKeShdjn5gbZ4ACihkCXoqZxF2STOLqg3hL38dTefvwfQJ4sleSAWMd5WaBfvhv3NqNh60m4L+w3UEtSpx2tPGG6nbL7XTZ1LhVhssxeVAVfJ+J2PHrZnXzUmM2mNZ5bie9Aq1CukfsalL7FyBfax0ffOp4aSbazugLODBlDPTBEpMwMYM3CV0becO3+DdwplwID84lKo8t9Xxst6m1wB6fx+FF+drffsQM9Mv0cH6rG9nCyHtVBhgWtkBBTowynAaQV6Lwrw8nI5GmuMeNft91j3Rn5DmHAxfDzeVvMzEP0/EWirs1pX9AEmwm9uXb+jUaBuQqOa3E6y+cUcfrRiDsLrav7zF6rZQ1G4mFm54Qeo3Fdm3n87q8KpN/Bw6MQ+lPEKbixAFRRHMNYHsxgqc/kp9UKN11Kp9lKhbgoaDlD32tFb5AasRSIuB7BuHiDvUFfhqIEylxZqMxzK/nFP9sVzK1saR+4qiO8XKZZX3ZRuen0Vha1O7Ppt6Dlg3ajgAEIHj0dkYUTAaTUgCBtUINx+hrekEQKvoHhMgrYSFqbax+etl8nxJrrrqnsctAa0Bf1zIiNHpO8MuNvwxDvY5WxPabnoTOqik5aSlg/J6Fc+qzSIMj+KvqdY3KgZXHVY5VdWPirSyVRkVwV61Ruoyn+VmDc35It+vDx5X81/tonF3HR6M/RaOr1bpDQiZ3SELmhus9f7pOItqq4EfMnKCy32dFwHQGfQY+R0os1xDM3pcDEGIF/i3Syff2v1EL+a2NbWb3a19eQCXN3k7qYAx5tcBQdQpdAn31UuzCaGvrxyR3PjER1SN7wLecqx76dbfhfxiMTIiQlfOSnmIcqxkxKOM5geokArw4vY6xM0T3niJLRaOnVKmEtntMKna/dwPT5cj6AZgSZuQUYACyeSkuSklxNaQqvJPccjH/ZyRHK0xZ1R36cMDP+ScYYz0zg20mWUpUmUZMssi+PofP4OOLCRSg==

Copy blueprint

This machine is a Turbine maker, you put a turbine in the steel chest you flip the inserter and it causes the assembly machine to read the item "turbine" to set that as receipe, to read the ingredients, then store the amount of ingredient in a memory cell, then whenever material is added in the assembly it's removed from that memory cell, this way there is 1 turbine built, with not too much excess material put in the assembly, and when it's over, it reset.

0eNrtWNtu4zYQ/ZWCj126sHVxLAPtH/Spj4Eh0NLYJiJRXpLKrhv43ztD2bo4TCx1N0UempdMeDkzPHM4Q+WFbYsajloqy9YvTGaVMmz9+MKM3CtR0JgSJbA1E8ZAuS2k2s9KkR2kglnIzpxJlcN3tl6cuWeTqbfGCisr1VsanDecgbLSSmicuT9OqarLLWjE4p79nB0rI52J+AgzW8Scneh3dCbnNyBBCyK0tIcSrMxmWVVupRK20j68xW8dIme51JA18yvOkBirqyLdwkE8S9yPmzrgFKdzB2ZoYie1sWnHhj0dKZBnqW2NI93x3IoZIJ/EjwGCISw8NCVkzll1BN0QsGZfcGdV22M9GRsJYl9xGgnCqVohD6XLySvawhYgh0zmoEdzFozi7IJ6Q1j/r8fp/D2DPlmU5J5YxHiPQrt41+x3RmJrSLsV9h3UHNSpwTueMNxa2XSnqzKVCrHYeicKA07J+DvtPGzOPjVGE2mdT5TiR9Aq1Buk/oFL+1ipAvut0k/Op4acra2ugbO9BlBXpoiUiQF0GRhk9J5z56/1TqG0GJBeXAqV/3tl9PU2WgHx9Ho0H9ytj6xAV6Y/ogI12F5Olu1aKFDgGhkBBXp/mmE/Ar0TGXh5aVgJsOewbb3boe6N/BthFvP2x+PtYXIGkv8bAh11SuVKPkE/+MmF62eUCZwbUaZGF5NkspRXn03Ks8VQy7/+gJY9DFGRmKLb1SfQ7Rv97r/tU4uRr+9VW4R9IN3r21iAYpYdwFgPykNLOxYOL1L3IJVqJxXOjQBbIhhvN6QGrEUWLnevrJ4hrXGuwB4DeSotlKa9j81ww/TgCMdCWGpH7inY9BrOyip37eu7yGxxYsPPocv2o64yMIa+nGoMp4MI3kMIegi97rinD68JMGE/EHkcHuDtbVFvG4o60zD+7PF5481k9wbe1sUTtngDGql+N5GxS6TvArpn+MjH36WujKn26EzqrJaWRJO2YmhWXqc0iDw9iKaeWTynaV315XPVAr9JQNd4VaVLd3Fvrzxvd3c3qZeHSQgh9wt5EkiXvNdyngQU8zuqHoGGtazGUjbIjk9x8WjFLQd1aNAAqJb9qADvCscXffc69v7v5b1DhFOvjfcmvHVtvEek64KckcIvaO6ww3NSjciKOgf8ik4zLXZUlltAt6HBSKlym0MXmpvDxRiA7OPdLJ/8WXJFwAnU9RPYmZFFxVrgV2r0ZephZLeL73a71WjFRjfJvlFsF3cBe1C50Cdv6MnI0MOBO7qB39Ah1bnHBY85vhriDX8MeEBm4MyIPzgr5Au0Q2dFHB9mNBi1g2ThnoUzA8SKnIW7lm4wJsyl2/SAoys3uOoGVx1oQlCRW5AQwNyZNEl21NgRLaHV5JRjjVg0dkB2sMGT0YOAMtD+Z5SzQmwBVcX+wpJT/fKneHI5wfeVcRzFyyCJoyBKlkkShsH5/A8g2j7p

Copy blueprint

This is the same but with the infinity chest hardcoded to make "silo" , it's just kinda boring to watch as a test that's why i took turbine.

You can trigger the machine with pulse of any material. But then you should replace the infinity chest with a blue requester chest which would even be better because that's a really weird use case you are mentionning here imo when you try to not overfeed the machine, as mentionned earlier it's probably better to not request more than 1 craft at the requester chest level.

NONETHELESS it is possible to fine control precisely currently the amount of material you insert in an assembly to not overload too much doing this way imo.

How would the memory cell get the number of ingredients without asking the assembler for it? And if you're asking the assembler for the number of ingredients, it cannot also give you an accurate count of the current contents.

I used blueprint to answer the question and demonstrate i believe that the second statement is incorrect.

[Alfonse215]

This machine is a Turbine maker, you put a turbine in the steel chest you flip the inserter and it causes the assembly machine to read the item "turbine" to set that as receipe, to read the ingredients, then store the amount of ingredient in a memory cell, then whenever material is added in the assembly it's removed from that memory cell, this way there is 1 turbine built, with not too much excess material put in the assembly, and when it's over, it reset.

... that's just another way to do the thing I described. The way I described it, you store the amount you have inserted already in the memory cell. The way you implement it, you store the amount you have yet to insert into the memory cell. But it's fundamentally the same thing either way: you're keeping track of how much is in the machine without asking the machine how much is in it.

It should be noted that you can use memory cells to just remember the entire contents of a machine, thus making "read contents" as a feature unnecessary. Well, spoilage aside. Though... once you introduce spoilage into the mix, external memory cells of any kind become unreliable.

Alfonse215 wrote: Mon Oct 05, 2026 12:07 pm

How would the memory cell get the number of ingredients without asking the assembler for it? And if you're asking the assembler for the number of ingredients, it cannot also give you an accurate count of the current contents.

I used blueprint to answer the question and demonstrate i believe that the second statement is incorrect.

When I said "it cannot also give you...", the "it" is referring to "the assembler", not "a memory cell beside the assembler".

[mmmPI]

... that's just another way to do the thing I described. The way I described it, you store the amount you have inserted already in the memory cell. The way you implement it, you store the amount you have yet to insert into the memory cell. But it's fundamentally the same thing either way: you're keeping track of how much is in the machine without asking the machine how much is in it.

That's why i described it differently i guess x) So why don't you use that ? what the point of the suggestion and why were you saying it's not possible or something ?

[Alfonse215]

what the point of the suggestion

If we have the ability to just remember what we've already inserted into a machine, why do we have the ability to read its contents at all?

Because it makes it easier to get the information and therefore more viable for less skilled players to engage with. With the ability to directly read the amount to insert, you can implement a simple case of "don't insert more than one craft at a time" with zero combinators (you'll get up to a hand-size of excess, but it works). Just wire up the inserter and set its filters from that wire.

And being able to directly read the amount to insert also handles edge cases like spoiling, which no memory cell can handle.

and why were you saying it's not possible or something ?

I never said that it was impossible to implement it yourself with combinator machinery. I said that you can't get those values from the assembler directly.

This is all just a corner case; it's overall not that important. But it is a use case that everyone who asks for more fine-grained control over output/input wires brings up as a justification for said control.

[mmmPI]

Because it makes it easier to get the information and therefore more viable for less skilled players to engage with.

But you can already control the requester chest to make a precise request and trash the excess !