I've been trying to design a mall circuit that delivers the exact amount of items requested. So if 7 belts are requested, it won't deliver 8 or 9, but exactly 7. Similar to this topic.
Here's my current design:
2024-06-29 19_44_06-Factorio 1.1.107.png (989.59 KiB) Viewed 3430 times
The gist of it: A constant combinator defines the required number of items. The bottom left memory stores the items in transport. The inserters next to the producers are informed of the current need, as the difference between required items and items in transport + items in chest.
The only problem here is bridging the gap between the circuit which counts all items in chests, and the circuit which counts all items currently in transport to the chests. When an inserter next to a chest picks up an item, it triggers a pulse to subtract the item from the items currently in transport. But it will take a couple ticks until the item is placed in the chest. So during the time when the inserter is moving the item, it will count as neither in transport nor in chest.
I've solved this problem with a 35-tick timer that is started shortly before any of the chest inserters can pick up an item. While the timer is active, the number or required items is temporarily set to 0, which deactivates all inserters next to producers.
Am I overlooking something? Is there an easier solution?
Edit: My latest iteration doesn't set the required items to 0, as this blocks all producer inserters. It only subtracts 3 instead (the inserter capacity).
2024-06-30 11_30_08-Factorio 1.1.107.png (910.91 KiB) Viewed 3345 times
Whether there is an easier solution depends on your point of view and the research progress.
In all of my malls, the output of assembling machines is directly put into a chest. Intermediate belts are used only, if an item is an intermediate item such as engine units. This way you don't need to count items on some belt, you only need to count chest content and deactivate an output inserter if there is enough in the corresponding chest next to it.
Some central control point to set the amount of items I want in storage is feasible only for more advanced and near-endgame malls. Notably, if the logistics network is available. As soon as it is available, I replace the output chests with storage chests or passive provider chests. The unified amount of all items in all logistics chests is then available by reading a roboport. This is the amount of items I have. In constant combinators, I define the items I want. With an arithmetic combinator I multiply the items I want with EACH * -1 and connect this negated demand with the items I have. This is (items I have) - (items I want), so for every Item the mall should produce the corresponding item has a negative amount. So I connect every output inserter with this wire and set <item> < 0 as activation condition. This way the inserter is active if there are not enough items in the logistics network and is deactivated if there are more than wanted items.
Requires just 1 arithmetic combinator for the whole mall (and even none, if you accept to use negative numbers in the constant combinators). The condition to activate some output inserter is directly set in the inserters.
Output inserters for intermediate items such as engine units need some additional combinator logic to generate a negative signal of one of their consumers need to be produced. Or they can just produce without condition until the belt is full - that's not too much overproduction.
Using numbers from the logistics network is not exact, because robots will carry items in quantities of 4. But since a mall usually produces a huge number of items and building uses up huge number of items as well, 1-3 items too much in a chest is not a big deal. It's not always "perfect fulfillment", but somewhat accurate enough.
Re: Mall with perfect fulfillment
Posted: Sun Jun 30, 2024 9:23 am
by ndh
My main motivation was that I don't want three cars lying around in chests. I think the items that should be produced in small quantities should get special treatment.
But you're right, for most items it doesn't matter if there's three too many. It's more of an engineering challenge than of great practical value. Realistically it doesn't matter if you have three cars in chests.
Re: Mall with perfect fulfillment
Posted: Sun Jun 30, 2024 12:10 pm
by Tertius
You're correct of course, one doesn't want multiple versions of some items. The armor, the car, the tank, some of the expensive personal equipment grid items.
If you examine closer how assembling machines work, you see there are one or more input inserters. Then there is the input buffer within the assembling machine. Then there is what is currently being produced. Then the output buffer, and finally the output inserter.
All of these stations are some kind of buffer. For expensive one-time items, you want these buffers as small as possible and filled as little as possible.
We know input inserters will insert items into the input buffers until there is enough for 30 seconds of continuous production, and at least for 1 production cycle.
There's also the thing that's currently being produced. This thing will definitely appear shortly, but it cannot be counted by anything yet, because it doesn't exist yet. That's important for more expensive items such as the Spidertron. If you collected enough material and the spidertron is being produced, we don't need any more input item. But we cannot determine yet we don't need any more input items, so the input slots will be filled again for items we don't intend to ever produce. We could solve this by reproducing the recipes and input exactly the number of items the recipe is expected to use for the intended amount of output items. However, this is much too tedious for a larger amount of different items we produce in a mall.
So as small improvement, we can not only deactivate the output inserter if we determine we have enough, we can also deactivate the input inserters with the same condition. This way the buffers within the machine will not be filled so much and the overall amount of buffered items shrinks.
About your example, you created a means to determine if there is an item on the belt and limit the amount of items on the belt, so there is no overproduction. That's overengineering in my opinion, because the most simple yet practicable solution is to use no belt behind the output inserters at all but directly put the items into a chest.
This way you don't have a nice sorted row of chests for your items in your mall but instead have distributed chests all over the mall. But this is an issue only for the early game, only for a short amount of time. Later, you will use the logistics network and logistic robots to automatically refill your inventory. You just walk into the network range, then robots will come and your inventory gets filled magically. The actual chest locations don't matter any more. The only thing you need to check and limit is the amount of items generally available somewhere in the logistic network. That includes trashed items you bring back from deconstruction.
Re: Mall with perfect fulfillment
Posted: Sun Jun 30, 2024 12:10 pm
by Tertius
You're correct of course, one doesn't want multiple versions of some items. The armor, the car, the tank, some of the expensive personal equipment grid items.
If you examine closer how assembling machines work, you see there are one or more input inserters. Then there is the input buffer within the assembling machine. Then there is what is currently being produced. Then the output buffer, and finally the output inserter.
All of these stations are some kind of buffer. For expensive one-time items, you want these buffers as small as possible and filled as little as possible.
We know input inserters will insert items into the input buffers until there is enough for 30 seconds of continuous production, and at least for 1 production cycle.
There's also the thing that's currently being produced if the machine is currently working. This thing will definitely appear shortly, but it cannot be counted by anything yet, because it doesn't exist yet. That's important for more expensive items such as the Spidertron. If you collected enough material and the spidertron is being produced, we don't need any more input item. But we cannot determine yet we don't need any more input items, so the input slots will be filled again for items we don't intend to ever produce. We could solve this by reproducing the recipes and input exactly the number of items the recipe is expected to use for the intended amount of output items. However, this is much too tedious for a larger amount of different items we produce in a mall.
So as small improvement, we can not only deactivate the output inserter if we determine we have enough, we can also deactivate the input inserters with the same condition. This way the buffers within the machine will not be filled so much and the overall amount of buffered items shrinks.
About your example, you created a means to determine if there is an item on the belt and limit the amount of items on the belt, so there is no overproduction. That's overengineering in my opinion, because the most simple yet practicable solution is to use no belt behind the output inserters at all but directly put the items into a chest.
This way you don't have a nice sorted row of chests for your items in your mall but instead have distributed chests all over the mall. But this is an issue only for the early game, only for a short amount of time. Later, you will use the logistics network and logistic robots to automatically refill your inventory. You just walk into the network range, then robots will come and your inventory gets filled magically. The actual chest locations don't matter any more. The only thing you need to check and limit is the amount of items generally available somewhere in the logistic network. That includes trashed items you bring back from deconstruction.
Re: Mall with perfect fulfillment
Posted: Mon Jul 01, 2024 8:04 am
by r3nt5ch3r
I've built something that uses hold-mode on the right inserter. With a small trick the hold-signal can be converted into single pickup/drop signals. This is probably not perfect, but might give you another idea.