What does a sushi belt do ? i was/am under the impression that it helps to not overflow your belt and keep a constant number of items on it (science packs for example).
I Coppied the example :Six( I only used 4 bc i only have 4 science pacs atm) belts in a row are connected with Red wire and set to Read belts contents and Hold
This Red wire is then connected to the inserters that insert onto the belt.
Read hand contents is unselected for all inserters.
Mode of operation is set to Enable/Disable on all inserters.
The first inserter is enabled when Science pack 1 = 0
The other inserters are set similarly for the other science packs.
I have coppied the design but it doesn't do anything.
Shushi Belt?
-
kidney killer
- Manual Inserter
- Posts: 1
- Joined: Sat Apr 13, 2019 1:07 pm
- Contact:
Re: Shushi Belt?
If something is too complicated, just build one yourself, then it will be easier.
In Factorio, other player designs, often could be used as a guide, not for direct copy. Ofc, you can direct blueprint copy 12*12 mixer or 4x4 railway cross, just because it's boring to create same thing by hands.
In Shushi Belt you count amount of pots on a belt part just before inserter, and add a few more pots of that color if not enough. Kinda easy.
In Factorio, other player designs, often could be used as a guide, not for direct copy. Ofc, you can direct blueprint copy 12*12 mixer or 4x4 railway cross, just because it's boring to create same thing by hands.
In Shushi Belt you count amount of pots on a belt part just before inserter, and add a few more pots of that color if not enough. Kinda easy.
-
Mathematician
- Inserter
- Posts: 36
- Joined: Fri Jan 18, 2019 6:58 pm
- Contact:
Re: Shushi Belt?
Let's look at an example of science pack sushi belt I built recently.
What does it do?
- It provides all science packs for the labs with every lab taking from a single belt.
- It makes sure the belt is not overflown with single type of science pack, so there is space for each of them.
- It (pseudo-)randomizes science packs so the longer they stay on the belt, the more evenly they are ditributed along the whole belt (and thus every lab has 'better' access to them).
Let's see step-by-step how this is accomplished (see numbers on the image):
1. Constant combiator requests science packs. Number of each color can be customized. Currently set to 60. Arithmetic combirator multiplies this by -2. We will see why in a moment.
2. Now we would want to simply inject 60 of each science pack, wouldn't we? The answer is 'no'. We want to have total of 60 of each color on the belt.
So we have to know how many is on the belt at the moment. The problem is the science packs are not only injected onto the belt, they also get consumed by labs. We could wire every single inserter and count consumed ones, but we do something funnier.
3. There is a single handgun on the belt.
4. Every time it passes this point it start a new 'cycle'.
5. We use a simple memory to count how many science pack has passed through since the begining of the cycle. This is a good approximate of how many packs there are total on the belt.
5.1 Well, its an approximate only at the end of a cycle but that's the only moment when we need it, so cool.
5.2 In case a single outcome is not too precise, it auto-corrects in the next cycle.
6. At the end of a cycle we send the number to the second memory (green global wire). This one is constant between cycles so we use it to calculate how many more science packs we need.
7. Now we can send science packs into the system. We of course inject a number of sent packs into second memory.
7.1 Note that we have second memory output into both red and green wire nets. That's why we needed 2* multiplication at requesting part.
8. Splitters, belts of uneven length and memory-based delay make sure our belt looks nice and random.
Sort of summary
- First of all I didn't copied the built from forums. I built it myself. I've come across some sushi belt ideas here and I spent some time reading basic circuit tutorials in the past. But the best part of learning is coming up with your own solutions.
- That only an example, different than your's. Sushi belt with: enclosed loop, item count request/balance, no backpressure,... and so on. It's not how every thing that can be called 'sushi belt' should look like. Always consider what you need and what is easier/funnier to implement.
- Side note: In rare cases, when the handgun passes the counter at the right time relative to when last research ended, we could get even +/-20% science packs in next cycle. Of course research is being started by player. It makes our sushi belt truly random (not just pseudo-random).
- Kinda easy.
Going back to the schema that you posted: it's quite same with only few differences:
- no memory (so we omit points 2-6), it only counts how many packs there is on six consecutive belt spaces (different kind of 'randomization' - we inject what we can see that we don't have under the nose
)
- packs are put into system with inserters, not belts (less efficient?)
- it does not work because you disconnected 2 belts. Belts are the determinator of how many packs we need to put into system (equivalent of memory). Six was just an arbitrary number, not correlated with number of packs that you use. You could connect less (or more) belts. In fact you could get the best results if you covered the whole belt with belts reading their contents and adjusted inserters' conditions.
Blueprint (only important stuff: belts and combinators)
- Zrzut ekranu (84).png (4.08 MiB) Viewed 2387 times
- It provides all science packs for the labs with every lab taking from a single belt.
- It makes sure the belt is not overflown with single type of science pack, so there is space for each of them.
- It (pseudo-)randomizes science packs so the longer they stay on the belt, the more evenly they are ditributed along the whole belt (and thus every lab has 'better' access to them).
Let's see step-by-step how this is accomplished (see numbers on the image):
1. Constant combiator requests science packs. Number of each color can be customized. Currently set to 60. Arithmetic combirator multiplies this by -2. We will see why in a moment.
2. Now we would want to simply inject 60 of each science pack, wouldn't we? The answer is 'no'. We want to have total of 60 of each color on the belt.
So we have to know how many is on the belt at the moment. The problem is the science packs are not only injected onto the belt, they also get consumed by labs. We could wire every single inserter and count consumed ones, but we do something funnier.
3. There is a single handgun on the belt.
4. Every time it passes this point it start a new 'cycle'.
5. We use a simple memory to count how many science pack has passed through since the begining of the cycle. This is a good approximate of how many packs there are total on the belt.
5.1 Well, its an approximate only at the end of a cycle but that's the only moment when we need it, so cool.
5.2 In case a single outcome is not too precise, it auto-corrects in the next cycle.
6. At the end of a cycle we send the number to the second memory (green global wire). This one is constant between cycles so we use it to calculate how many more science packs we need.
7. Now we can send science packs into the system. We of course inject a number of sent packs into second memory.
7.1 Note that we have second memory output into both red and green wire nets. That's why we needed 2* multiplication at requesting part.
8. Splitters, belts of uneven length and memory-based delay make sure our belt looks nice and random.
Sort of summary
- First of all I didn't copied the built from forums. I built it myself. I've come across some sushi belt ideas here and I spent some time reading basic circuit tutorials in the past. But the best part of learning is coming up with your own solutions.
- That only an example, different than your's. Sushi belt with: enclosed loop, item count request/balance, no backpressure,... and so on. It's not how every thing that can be called 'sushi belt' should look like. Always consider what you need and what is easier/funnier to implement.
- Side note: In rare cases, when the handgun passes the counter at the right time relative to when last research ended, we could get even +/-20% science packs in next cycle. Of course research is being started by player. It makes our sushi belt truly random (not just pseudo-random).
- Kinda easy.
Going back to the schema that you posted: it's quite same with only few differences:
- no memory (so we omit points 2-6), it only counts how many packs there is on six consecutive belt spaces (different kind of 'randomization' - we inject what we can see that we don't have under the nose
)- packs are put into system with inserters, not belts (less efficient?)
- it does not work because you disconnected 2 belts. Belts are the determinator of how many packs we need to put into system (equivalent of memory). Six was just an arbitrary number, not correlated with number of packs that you use. You could connect less (or more) belts. In fact you could get the best results if you covered the whole belt with belts reading their contents and adjusted inserters' conditions.
Blueprint (only important stuff: belts and combinators)
Some people say math is useless in life. I say life is useless in math.
Re: Shushi Belt?
In whole I've found Shushi Belt somewhat fun but not so useful design.
Because it has limited throughput, does not support well lab number increase, and have to be fine tuned many times (if you making one by yourself). So I usually skip it and go directly to dedicated area bot supplied research. This one you can feed with belts. One blue belt for each color is enough for 2k SPM, at least.
Because it has limited throughput, does not support well lab number increase, and have to be fine tuned many times (if you making one by yourself). So I usually skip it and go directly to dedicated area bot supplied research. This one you can feed with belts. One blue belt for each color is enough for 2k SPM, at least.
Re: Shushi Belt?
Sushi belt are used whenever you need want more then 2 items on a single belt:
- Screen Shot 2018-12-02 at 7.22.52 AM.png (615.93 KiB) Viewed 2325 times
- Screen Shot 2018-11-14 at 5.41.33 PM.png (738.36 KiB) Viewed 2325 times
-
5thHorseman
- Smart Inserter
- Posts: 1193
- Joined: Fri Jun 10, 2016 11:21 pm
- Contact:
Re: Shushi Belt?
I was working on a sushi-fed mall, but it got annoying fast.
Here's an early WIP shot.
Here's an early WIP shot.
Re: Shushi Belt?
Working with sushi belts requires thinking a little differently. First all sushi belts should be loops or you risk jamming/starving. Also it's a good idea to control how much of each item you put on the belts. And finally if you are not grabbing directly from the belt it requires special handling of splitters.I was working on a sushi-fed mall, but it got annoying fast.
- Screen Shot 2019-04-14 at 8.25.56 PM.png (1.06 MiB) Viewed 2314 times
- Screen Shot 2019-04-14 at 8.35.35 PM.png (651.56 KiB) Viewed 2314 times
-
5thHorseman
- Smart Inserter
- Posts: 1193
- Joined: Fri Jun 10, 2016 11:21 pm
- Contact:
Re: Shushi Belt?
Oh that never jammed. I purposefully kept it full to start, but the ratios of the items was consistent so everything was 1/x of a full blue belt. The big items were actually a full red belt, and the lesser items were half a yellow belt, and there were a couple items that were a full yellow belt.Trebor wrote: ↑Mon Apr 15, 2019 12:56 amWorking with sushi belts requires thinking a little differently. First all sushi belts should be loops or you risk jamming/starving. Also it's a good idea to control how much of each item you put on the belts. And finally if you are not grabbing directly from the belt it requires special handling of splitters.I was working on a sushi-fed mall, but it got annoying fast.
The annoying part was splitting the belt at the end to re-sort all 10 raw ingredients back to their input belts to re-apportion them onto the sushi bus. Turns out it was MUCH simpler to just make a 6-belt regular bus with shared lanes. And I didn't stress test it but I think it was faster, too.
