, computers.
The circuit is technically capable of handling any number of belts in parallel, but there are a couple of requirements that make it cumbersome to build a sushi bus with more than two belts. Firstly, lane balancers (belt balancers that also balance the left & right lanes of each belt) are actually required to use all available throughput. Secondly, if a sub factory only pulls from one belt of a two belt sushi bus, then you effectively only have a one belt sushi bus for the item that the sub factory produces, as well as for any recipe or recipe chain that uses that item, so all assemblers or sub factories need to be able to pull items from all belts of a sushi bus.
For those reasons, I made a set of blueprints for setting up a factory with a two belt sushi bus. If more throughput is required, you can build multiple two belt sushi factories.
Example Mall
- Example Sushi Mall v1_8.jpg (767.91 KiB) Viewed 5348 times
Quick Start
- DSC Quick Start v1_10.jpg (336.55 KiB) Viewed 5065 times
Factory Segment
- DSC Factory Segment v1_10.jpg (231.01 KiB) Viewed 5065 times
The factory is connected to the circuit with two wires. Only what moves items to/from the sushi bus should be connected. The red wire is for counting the items taken from the sushi bus, anything connected to this wire just needs to be set to pulse read. The green wire is for controlling what items get added to the bus, a positive number for an item signal means that there are enough of that item in the warehouse to meet the current demand, while a negative number indicates a demand for more of that item. Inserters connected to the green wire should be set to Enable if ITEM <= 0, pulse read. When controlling belts with the green wire like with the external inputs, use two belt tiles. The first tile should have the enable condition, and the immediate next tile should pulse read.
Warehouse
- DSC Warehouse v1_10.jpg (162.79 KiB) Viewed 5065 times
The warehouse is necessary to actively clean out the sushi bus of items that aren't being used. New items will not be requested if there are enough in the warehouse. The reason why the sushi bus isn't a real loop is because it made the logic much simpler if all unused items just get dumped in the warehouse.
Input Expansion
- DSC External Input Expansion v1_10.jpg (119.13 KiB) Viewed 5065 times
Circuit
- Dynamic Sushi Controller v1_10.jpg (278.87 KiB) Viewed 5065 times
"C" is the cycle time in ticks. I recommend at least 1200 ticks (20 seconds). This constant combinator is also the on/off switch for the circuit.
There needs to be at least one of every item on the bus for the circuit to detect if those items get taken, so the circuit will periodically request one of every item from the warehouse as a sample. The "or equal to zero" part of the item source enable condition is how samples of items that aren't in the warehouse are added. The cycle time is the time between each request for more samples, as well as the time between updating the proportions to use, progressing the moving average of what was taken, and clearing a few memory cells.
If factory intermediates don't have buffer chests, then the circuit seems to forget about the demand needed to make those intermediates unless a cycle is at least as long as it takes for an item to travel all the way around a bus, including the middle section. Using a bigger value for "S" might also work, as it kind of has the effect of multiplying cycle time.
"I" is the total number of items to be requested per cycle. It can at most be the items per second of the bus * cycle time in seconds ("C" / 60 converts from ticks to seconds). For a two belt sushi bus where "C" = 1200, "I" can at most be 600 for normal belts, 1200 for fast belts, and 1800 for express belts.
Instead of controlling the amount of space on the bus used for each item, the circuit controls the amount of throughput used for each item. The total throughput is set as items per cycle, and the circuit scales the average number of items taken (plus the defaults) so that the total equals "I". This result is then gradually revealed 1/128th at a time as the cycle progresses to avoid flooding the bus. The circuit requests one of each item at the start of every cycle, so this setting also limits how precise the proportions can be. For example: if "I" = 100, and there are two different items to control, then the proportion can at most be ~99:1.
Control over supply isn't precise, so the total items added to the bus often exceeds "I". The total excess is subtracted from "I" for the next cycle to avoid the bus getting backed up. Or rather, the next next cycle, since timing restrictions mean it can't take effect immediately. The error correction repeatedly falls behind, then catches up over six cycles due to the way it's set up. This is interesting to watch as the bus looks like it's backing up, but then clears out, then backs up again, almost like the factory is breathing (or maybe I've spent way too much time thinking about this thing).
"S" is the smoothing factor for the moving average. Must be negative. It's not really necessary to change this from the default (-3). Setting to -1 will disable the moving average without breaking the circuit.
The moving average circuit is based on vanatteveldt's design, but modified to progress once every cycle. Instead of directly using the items taken during the last cycle as the proportions of the next, a moving average of items taken is used so changes in supply are less drastic. This is beneficial when supply points are far apart as the bus can temporarily back up if the proportions change too quickly, though I think this is more of an aesthetic issue.
There is a constant combinator where you can set what the proportions should default to when the factory is idle. It's not at all necessary to set these, it's just a way to offset the latency problem this design has. It's basically artificial demand. Only use positive numbers.
Want a bit of everything in equal amounts? Set a 1 for every item. Want twice as much iron as copper? Make the iron value twice as big as the copper value. The values for each item can be whatever you want, but the greater the total is, the less it can deviate from these proportions. This doesn't work perfectly if you set default proportions for factory intermediates as it'll bounce between producing those intermediates and being idle until there are enough items to fill the bus.
Integer overflow is a thing, so here is a formula for figuring out if your chosen settings are safe to use:
Code: Select all
|S * I * 128| + (Sum of defaults) < 2,147,483,648Example of the core idea
Change log