Describe your enhancement

Currently, if I need to craft 1000 of a given item, and there's multiple steps to get there, we're given a total amount of each item. Let's say one of those items requires:

• 5 iron cooked
• 2 gold cooked
• and 10 sticks crafted, which let's say we already have in our system.

For a total of 5 000 iron cooked, 2000 gold cooked, and 10 000 sticks.

The Autocrafter currently attempt to cook 5 iron, then 2 gold, then crafts 1 item. Then, it cooks 5 more iron, 2 more gold, and crafts the next item, and so on 1000 times, making the crafting 3 000 steps to go through.

For large scale crafting, I've found that asking the system to craft every sub-item 1 task at a time is much faster than this looping process. AKA, it would be much faster to cook 5 000 iron, then 2 000 gold, and finally craft the 1 000 item.
On one side, I believe this might be lighter for the server/system to process. It wouldn't have to loop through 1 000s of steps/condition checks, just as many steps as items, repeated until all of them are sent to the crafting area (wherever the Autocrafter is pointed to). Which in this case (very simplified extrapolation, I know, but it still applies), the crafting would be 3 steps. 3 Large steps, but 3 steps.

I do also believe that in some less-large scale cases, the current system is better (take for example when we really want to have access to 1 of the items asap; or when the crafting area you're sending to is slow). So, I think we should have access to this option either in-game or in-config, instead of only one of the other.

try making the crafter go into a chest and then pulling items into your furnace(s) using pipes

That's already what I am doing. Another precise example is something that needs glass. If I don't have sand, I need to craft the sand, then make the glass.
If I make 50 000 glass, it'll craft ~ 16 sands, then cook 16 sands, until it gets to 50 000. Doing it separately is much faster (making the sand THEN making the glass). My smelting array can handle 100s of sand a second, and it is much slower to ask the system to do the whole job.
Again, this isn't an issue. If it wasn't for the current system, we wouldn't see items flowing it as time goes by/as the crafting gets done. Sometimes, crafting in batch is slower.
With the system I'm talking about, we'd only see the items are the very end of the processing of all ingredients.

Both logic have advantages. I'm just saying maybe we could choose which one we want. The processing logic should be pretty straight forward too; Keep in memory the required ingredients, find the lowest sub-crafting step (on the crafting tree), and craft only those at first. Once one ingredient is done crafting, move to the next instead (that's if we're talking about linear logic; parallel logic would only require to prioritize large batches over attempting to craft the whole tree at once)

ah. So it seems the issue isn't that it will send 16 gravel then 16 sand, the issue is that it will wait for 16 glass before sending 16 more *gravel

In other words, it should send as much gravel as it can until it has sent all of it, and while it's doing that, send as much sand as it can until it has sent all of it

Yes, that's a perfect/much clearer way to describe it!

It's because the treat the crafting tree as a deep down algo. They actually do the half the job already : calculating how many of everything that need to be done. But when it come to do it, they throw this part away and just go trought the tree instead. I'm pretty sure it's new to this version (RS2) and this is why I see a lot of comment about removing it from ATM10! It making crafting very painful! More, when it come to missing some ingredient in a deep recepies, you can't know what is missing and how much.... because it will show you the upper node that can't be craft instead of what is it missing in the end.

So yeah, the algo should be : build the tree, send to craft every node that have "leaf/ingredient" sub-nodes only. When you get the output, transform this "receipe" node into an ingredient node and trigger a check to the parent to check if it can proceed.

If the issue is the number of nodes, you can group all similar node together and have them a list of parents instead of one.

As a dev, I can provide a proof of concept if needed.

I offered to make a proof of concept for a crafting algorithm as well, I was told it would probably not be too useful unless it actually worked in the code, because a proof of concept usually misses a lot of important details that turn out to mess the whole thing up. You're welcome to try but it's probably a lot more complicated than you're thinking