Assembler #17: "I need 5 plates, please."
Moderator: ickputzdirwech
-
ajm.nethunt
- Burner Inserter
- Posts: 12
- Joined: Fri Apr 01, 2016 1:21 pm
- Contact:
Assembler #17: "I need 5 plates, please."
I wish assemblers (et al, like research stations) would broadcast what they currently need for their current recipe on the circuit network. The ability to accomplish "Unload from storage and send 5 iron plates and 5 copper plates down the main bus to assembler #17" would be...exciting.
Re: Assembler #17: "I need 5 plates, please."
[Koub] Moved to Ideas and Suggestions
Koub - Please consider English is not my native language.
Re: Assembler #17: "I need 5 plates, please."
This would be a mix of robo-net (you can do this with blue / red chests) an the usual transport system.
What you wrote is much more complicated as you might think.
You have a sender, a transport and a receiver and a time between them.
So when assembler #17 asks for items and you send them from far far a away you loose 90% of productivity due to transport times. To avoid this you need a buffer ... so it´s basically a sushi belt, which is solved and already known ? When connecting input sushi and output together this works really fine, without materials which aren´t used on every belt.
Or are you thinking in the possibility to package things before use ?
Like 5 iron + 3 copper -> package -> transport -> depackage -> 5 iron + 3 copper ?
This feature is something I would really enjoy.
Like "a package could increase the capacity of your belts by 100% but you need wood for this (cardboards) and a depackaging (with seperate handling for cardboards) - at least for the T1 products like copper wire, modules, circuits, ...
Or a simply connection to the assembler which sends out the actual needed materials for the recipes ? to construct a huge - autmatic filled sushi belt ?
What you wrote is much more complicated as you might think.
You have a sender, a transport and a receiver and a time between them.
So when assembler #17 asks for items and you send them from far far a away you loose 90% of productivity due to transport times. To avoid this you need a buffer ... so it´s basically a sushi belt, which is solved and already known ? When connecting input sushi and output together this works really fine, without materials which aren´t used on every belt.
Or are you thinking in the possibility to package things before use ?
Like 5 iron + 3 copper -> package -> transport -> depackage -> 5 iron + 3 copper ?
This feature is something I would really enjoy.
Like "a package could increase the capacity of your belts by 100% but you need wood for this (cardboards) and a depackaging (with seperate handling for cardboards) - at least for the T1 products like copper wire, modules, circuits, ...
Or a simply connection to the assembler which sends out the actual needed materials for the recipes ? to construct a huge - autmatic filled sushi belt ?
Re: Assembler #17: "I need 5 plates, please."
I think this is mend to simplify setting up a sushi belt.
Currently at each assembler you need a constant combinator that you program to the items needed in the assembler. You have to program that constant combinator by hand individually for every recipe. The rest of the setup for buffer chests and sushi belt and such is all generic and you can easily blueprint. But the constant providers are a pain.
PS: I made a tree based setup for this. A bunch of assemblers around a chest representing the leafs. Multiple such clusters are then connected to another chest. and so on till it connects to a LTN train station. The idea is that each leaf cluster only buffers a tiny amount and gets quickly refilled from the next higher chest that buffers a bit more. This cuts down on the amount buffered while keeping the time between recipe runs low.
Currently at each assembler you need a constant combinator that you program to the items needed in the assembler. You have to program that constant combinator by hand individually for every recipe. The rest of the setup for buffer chests and sushi belt and such is all generic and you can easily blueprint. But the constant providers are a pain.
PS: I made a tree based setup for this. A bunch of assemblers around a chest representing the leafs. Multiple such clusters are then connected to another chest. and so on till it connects to a LTN train station. The idea is that each leaf cluster only buffers a tiny amount and gets quickly refilled from the next higher chest that buffers a bit more. This cuts down on the amount buffered while keeping the time between recipe runs low.
-
ajm.nethunt
- Burner Inserter
- Posts: 12
- Joined: Fri Apr 01, 2016 1:21 pm
- Contact:
Re: Assembler #17: "I need 5 plates, please."
I'd love to see a picture of that, mrvn.
What I was thinking, In other words, is that it would really nice to tag a piece of steel on a belt for a specific factory - like the assembler can send a signal over to some inserter that unloads 5 plates, and those 5 plates are tagged (when unloaded onto the belt by the source inserter) for the destination inserter that also carries the same signal as that assembler, like a mailing address.
Even a sushi belt doesn't really accomplish this: the first inserter that can grab, does grab - there's no ability to simply send a particular plate to a particular inserter.
What I was thinking, In other words, is that it would really nice to tag a piece of steel on a belt for a specific factory - like the assembler can send a signal over to some inserter that unloads 5 plates, and those 5 plates are tagged (when unloaded onto the belt by the source inserter) for the destination inserter that also carries the same signal as that assembler, like a mailing address.
Even a sushi belt doesn't really accomplish this: the first inserter that can grab, does grab - there's no ability to simply send a particular plate to a particular inserter.