Simple sushi belt automated mall
Posted: Thu Nov 21, 2024 4:40 pm
Hello everyone, it's been a while since I played with circuits, and seeing all the new possibilities I decided to try to do a simple botless mall. This would come very handy for unattended planet housekeeping.
The goals I set myself:
- Should handle building all the intermediaries necessary.
- Should not be crowded by intermediaries. (Only cogs needed for the current recipe should be built)
- Adding a new item to be built should not require setting new intermediaries.
All this is to ensure I will be able to set ghosts mindlessly and the setup will read directly from the roboport requests.
Here's the first iteration which only does total of 4 steps that only require assembling machines:
The top left assembler is crafting the needed object and the assembler on its right is crafting needed intermediary. The second line of assemblers are used to read the recipe ingredients. The ingredients list is passed to the next column and compared to the sushi belt inventory to figure what intermediary to craft.
The requested recipe only change when it needs to as to limit the amount of unloading.
The belt is also fed from the outside, currently there is a combinator that states the items and their amounts that should be put on the belt from the inserters. The inserters are filtered by needed items to be able to be fed by belts with 2 item types.
The next steps:
1. Find a way to introduce other building types in the loop, like to craft plastics
2. Provide ways to craft with fluids
I think that handling the intermediaries in cascade like this prevents using multiple machines in parallel for one recipe. I think that I could separate the second row of assemblers, make a bigger bunch to be able to provide a complete list of intermediaries needed and have the assemblers craft them in parallel by picking up a recipe that is do-able with what's available on the belt.
If assemblers work in parallel, I need to find a way to know what each is crafting or else I might end up with too many intermediaries being built. I could use a selector combinator to select input. That way only one machine would be given the task to produce a specific item but that would make some assemblers useless as not all recipe would need 10 different intermediary.
The goals I set myself:
- Should handle building all the intermediaries necessary.
- Should not be crowded by intermediaries. (Only cogs needed for the current recipe should be built)
- Adding a new item to be built should not require setting new intermediaries.
All this is to ensure I will be able to set ghosts mindlessly and the setup will read directly from the roboport requests.
Here's the first iteration which only does total of 4 steps that only require assembling machines:
- 11-21-2024, 17-08-30.png (1.1 MiB) Viewed 2081 times
The top left assembler is crafting the needed object and the assembler on its right is crafting needed intermediary. The second line of assemblers are used to read the recipe ingredients. The ingredients list is passed to the next column and compared to the sushi belt inventory to figure what intermediary to craft.
The requested recipe only change when it needs to as to limit the amount of unloading.
The belt is also fed from the outside, currently there is a combinator that states the items and their amounts that should be put on the belt from the inserters. The inserters are filtered by needed items to be able to be fed by belts with 2 item types.
The next steps:
1. Find a way to introduce other building types in the loop, like to craft plastics
2. Provide ways to craft with fluids
I think that handling the intermediaries in cascade like this prevents using multiple machines in parallel for one recipe. I think that I could separate the second row of assemblers, make a bigger bunch to be able to provide a complete list of intermediaries needed and have the assemblers craft them in parallel by picking up a recipe that is do-able with what's available on the belt.
If assemblers work in parallel, I need to find a way to know what each is crafting or else I might end up with too many intermediaries being built. I could use a selector combinator to select input. That way only one machine would be given the task to produce a specific item but that would make some assemblers useless as not all recipe would need 10 different intermediary.