Factorio Forums

This *is not* a bug report. I am interested in the opinion of other players before even considering submitting a bug report or enhancement suggestion.

Scenario:

- Inserting multiple items (either due to using a stack inserter, or due to having an inserter bonus).
- The receiving chest (or wagon) can only accept part of the items in the inserter hand.
- What can be placed goes in, what can't remains in the inserter hand.

Problem:

- Until the hand empties, the inserter will not move, even if the recieving chest/wagon can receive other items but not the one in hand.
- Once understood, this can be worked around. But it is clunky and not intuitive at all. Many a new player get frustrated and think that the game is broken.

Question:

- So... should this be considered broken? A bug or a flawed design?
- Or is there a valid reason to *want* this type of behavior?

Possible solutions:

These are the ones I could think of, I am sure there are many others. Please contribute.

- The simplest solution would be for the inserter to have a "buffer" where it can keep leftover items of each kind.
- Another solution could be for the inserter to return (or better... not retrieve) items that can't fit at destination, before anything else feeds more stuff into the source. This could (or could not depending on how it is implemented) have a delay implication.

Screenshots:
(An example of a situation caused by this problem. I solved it by using a separate source chest and inserters for each type of item, works but it is not a good solution.)

This screenshot shows a wagon with lots of free space for items. This screeshot shows the contents of one of the source chests. The items are there waiting. This screeshot shows the contents of the other source chest. The items are also there waiting.

The biggest reason IMO is that enforcing checks on the inserter every cycle will have to be done for all potential insert events, even those that are from a single item type source (as is normally the case) and therefore will decrease the performance of inserters for all players.

I experienced the exact same issue while trying to load multiple item trains (for base building) recently, and worked around it by forcing each inserter to work from an independent requester chest.

Yeah, you need to use one item per chest. For most of them you don't need stack inserters anyways, so that's fine

zOldBulldog wrote: ↑Tue Apr 23, 2019 10:23 pm - So... should this be considered broken? A bug or a flawed design?
- Or is there a valid reason to *want* this type of behavior?[/b]

I think that the reason is good old speed of computation. Factorio is optimized for effective straightforward high throughput systems at cost of shenanigans in small complex systems.

- The simplest solution would be for the inserter to have a "buffer" where it can keep leftover items of each kind.

In my opinion this is far from simple. Or at least needs compromises how to handle the buffer. Probably inserter should give priority to buffered items, but what if there is some items in buffer but inserter loads different items to next wagon and there is again excess items. Should buffer handle all kind of items and have possibly hundreds of scrap items after long run?

- Another solution could be for the inserter to return (or better... not retrieve) items that can't fit at destination, before anything else feeds more stuff into the source. This could (or could not depending on how it is implemented) have a delay implication.

This is very complicated and time consuming test if there is for example 11 other inserters to feed same wagon from various sources.

I would suggest that when the inserter takes items from chest (or whatever inventory), room stay reserved until inserter actually gives items away. If there were excess the inserter could return them to chest. This would not need crazy number of CPU work or strange programming tricks, but not work if the inserter takes items from belt. But probably most problem cases are in inventory to inventory transports.

Ok, if those solutions are no good and the current one isn't either... What will work reliably and intuitively?

zOldBulldog wrote: ↑Wed Apr 24, 2019 1:14 pm Ok, if those solutions are no good and the current one isn't either... What will work reliably and intuitively?

I did not say that they are not good. But they are not very simple or at least there are always some complex implications.

That buffer would probably work practically very well and my suggestion too (except with belts). But it is not enough that something is reliable and intuitive. It must be fast to calculate. Maybe there could be some kind of "intelligent things" for those players who do not need million things. At least better inserters, special bots (with collision avoidance and effective work queuing) etc. They would have big warning (at least 30 % of screen area) that this entity kills your UPS and damages your brain, and ugly picture of UPS/FPS 5.3/5.3, so that megabase builders could avoid them. That would give more interest to those who have different playstyles than billion spm fully robotized and beaconized megabase without damaging megabase builders peace of mind.

Hannu wrote: ↑Wed Apr 24, 2019 1:26 pm

zOldBulldog wrote: ↑Wed Apr 24, 2019 1:14 pm Ok, if those solutions are no good and the current one isn't either... What will work reliably and intuitively?

I did not say that they are not good. But they are not very simple or at least there are always some complex implications.

That buffer would probably work practically very well and my suggestion too (except with belts). But it is not enough that something is reliable and intuitive. It must be fast to calculate. Maybe there could be some kind of "intelligent things" for those players who do not need million things. At least better inserters, special bots (with collision avoidance and effective work queuing) etc. They would have big warning (at least 30 % of screen area) that this entity kills your UPS and damages your brain, and ugly picture of UPS/FPS 5.3/5.3, so that megabase builders could avoid them. That would give more interest to those who have different playstyles than billion spm fully robotized and beaconized megabase without damaging megabase builders peace of mind.

Based on my programming experience I would not anticipate the buffer - even if it stores information for each type of item - to have a significant impact on UPS. Basically because it stores the information for all of those items that are stuck in it, but only needs to do calculations for the one being worked on at the moment.

You could have a noticeable impact if there were a lot of items in this state, but that could be avoided by only implementing the buffer if there is more than one item type being handled by the inserter. In all of the other cases it could default to the current behavior. That would massively reduce the number of inserters in the map that have a buffer. One scenario that needs to be figured out is inserters feeding assemblers (multiple products from one belt or chest) and the production line getting backed up so that an inserter with multi-item cache might hold each type), but I suspect there is an answer hiding there.

I wonder if the available tools are sufficient to allow someone to do a mod for this and perhaps solve the problem before the developers get involved to solve it for the main game.

I was facing the same issue not a long time : i don't think there is a ups efficient way to have a code or behaviour like you are asking for (or it got to be like a option for only selected inserter, like in the inserter setting window). Like they said, use one chest per item to keep the stack size bonus, if you want to have multiple itemin the same chest, the stack size have to be set to 1 (so a blue inserter is enough) to be sure that every item on the box will correcly filled the cargo wagon without the inserter block with some object left.

Tekillaa wrote: ↑Wed Apr 24, 2019 3:55 pm I was facing the same issue not a long time : i don't think there is a ups efficient way to have a code or behaviour like you are asking for (or it got to be like a option for only selected inserter, like in the inserter setting window). Like they said, use one chest per item to keep the stack size bonus, if you want to have multiple itemin the same chest, the stack size have to be set to 1 (so a blue inserter is enough) to be sure that every item on the box will correcly filled the cargo wagon without the inserter block with some object left.

LOL, that is exactly what I did to band-aid the problem before I started this thread.

It just feels so wrong:

- One chest per item type works fine, but it is sooooo inefficient.
- Setting stack size to 1 totally defeats the stack bonuses and even using a stack inserter.

But, as we all know... it works, even if it is ugly. TBH, I was hoping that there could be something better. I am starting to suspect it is a lost cause.

It is part of the game that you have to solve those logistic problems. For example you could easily solve this with a few combinators. There are probably much more options.

But adding a check for every inserter on the map to see if the inserter can insert the items is definitely horrible for UPS considering that inserters are one of the entities that effect UPS the most. It is not going to happen.

DerGraue wrote: ↑Wed Apr 24, 2019 4:18 pm For example you could easily solve this with a few combinators.

Is there a way to do this with combinators? The apparent use case is loading a train with filtered slots. Circuit network can see the number of a given type of items in a train car, but it can't (AFAIK) see the number of items that would fit given the filtered slots.

The only way I see is to replace the filtered slots with a constant combinator which gives the loading limits for each item type, but it would be nice to be able to keep using the filters.

I often use a stack inserter loading into assemblers when an item wants 6+ and it has a short build time, and there are times with trying to make things compact it is the only inserter dual feed line.

I use the solution of overriding stack sizes. I max sure it puts it into where it will evenly divide.

It is not just wagons and chests.

at this point, it probably needs to stay as it is and you build around it.
Any check will add more cpu cycles which you cannot do when you have thousands of inserters.

Selvek wrote: ↑Wed Apr 24, 2019 6:05 pm

DerGraue wrote: ↑Wed Apr 24, 2019 4:18 pm For example you could easily solve this with a few combinators.

Is there a way to do this with combinators? The apparent use case is loading a train with filtered slots. Circuit network can see the number of a given type of items in a train car, but it can't (AFAIK) see the number of items that would fit given the filtered slots.

The only way I see is to replace the filtered slots with a constant combinator which gives the loading limits for each item type, but it would be nice to be able to keep using the filters.

You basically answered your question yourself. Just make sure that the constant combinator requesting the items requests 11 items less than the actual maximum capacity so that the last swing of the filter stack inserter does not get stuck. Also disable the inserter while there is no train in the station to prevent loading items on the first tick the train arrives and the information in the train is not yet been processed.

I think a usual design is to have a constant combinator with the desired contents of the train; subtract current contents of train from desired contents, send that to a set of filter stack inserters which are configured to set filter and set stack size; if you're moving lots of stuff, each swing will move the maximum the inserter can handle, and when you're close to the desired amount it should move one final short stack that's just the right size to reach the desired amount.

If you have the same item in multiple chests you can run into problems. If you really want to fill the train right up to the limit using stack inserters and have the same item in multiple chests, you would need to do some circuit network magic to send that last stack from just one chest, rather than all of them.

The easy solution is to subtract one item from your fill level for each extra chest that can supply the item, in which case you're have on average the last stack almost, but not quite, full.

If you're set on using filtered slots, you could fill the train by stopping at multiple different stations, each loading up to 12 items, before taking things where they need to go.


I believe that the inserter waiting until its hand is empty is an optimisation feature for placing items on belts; if the belt is, say, 50%, you take a severe hit to throughput if the stack inserter stopped dropping things if there's an item on the belt, then swings back to pick up more things, rather than waiting until it's finished dropping everything that's waiting to be dropped.

mrudat wrote: ↑Thu Apr 25, 2019 9:01 am I think a usual design is to have a constant combinator with the desired contents of the train; subtract current contents of train from desired contents, send that to a set of filter stack inserters which are configured to set filter and set stack size

That works nicely with one train car, but not with multiple ones

Serenity wrote: ↑Thu Apr 25, 2019 10:34 am

mrudat wrote: ↑Thu Apr 25, 2019 9:01 am I think a usual design is to have a constant combinator with the desired contents of the train; subtract current contents of train from desired contents, send that to a set of filter stack inserters which are configured to set filter and set stack size

That works nicely with one train car, but not with multiple ones

I'm not sure why it wouldn't? Ideally you would have distinct items in the wagons, in which case it should work identically to the case of having just one wagon.

If you need a wagon-and-a-bit of item x, the ideal would probably be to put exactly 1/n stacks of item x in each wagon, in which case it should still work.

It might run into problems if the source chests aren't balanced. Perhaps you would need to implement a chest balancer for your mixed goods station.

That sounds tricky; you want to have multiple items per chest, but, apart from requester chests, I'm not aware of any straight forward way of balancing more than perhaps 2 items per chest (deliver 1 item on each lane of a belt; use a filter inserter to fill chest).

Perhaps you would just need to sanity-check the chest contents before allowing a train to load?

DerGraue wrote: ↑Thu Apr 25, 2019 8:28 am Just make sure that the constant combinator requesting the items requests 11 items less than the actual maximum capacity so that the last swing of the filter stack inserter does not get stuck.

Just out of curiosity: How many items can a stack inserter move if that item has a stack size of 1, like artillery ammo? If you had completely researched all stack size upgrades, would it still pick up 12 items per swing, or would the item's stack size override the stack inserters capacity limit?

Pi-C wrote: ↑Thu Apr 25, 2019 1:09 pm

DerGraue wrote: ↑Thu Apr 25, 2019 8:28 am Just make sure that the constant combinator requesting the items requests 11 items less than the actual maximum capacity so that the last swing of the filter stack inserter does not get stuck.

Just out of curiosity: How many items can a stack inserter move if that item has a stack size of 1, like artillery ammo? If you had completely researched all stack size upgrades, would it still pick up 12 items per swing, or would the item's stack size override the stack inserters capacity limit?

An inserter can only move 1 item with stack size 1.

mrudat wrote: ↑Thu Apr 25, 2019 10:59 am

Serenity wrote: ↑Thu Apr 25, 2019 10:34 am

mrudat wrote: ↑Thu Apr 25, 2019 9:01 am I think a usual design is to have a constant combinator with the desired contents of the train; subtract current contents of train from desired contents, send that to a set of filter stack inserters which are configured to set filter and set stack size

That works nicely with one train car, but not with multiple ones

I'm not sure why it wouldn't? [...]

The only problem here is the "set stack size" part. If you use several items you need to calculate a minimum which is really, really hard to do with combinators. IMO it is not worth the effort.

In to say that this happens alot with requester chests and assemblers too. In that case, itd be cool if the order of item type was a bit different so the assembler can start earlier, consuming some resources.

mrudat wrote: ↑Thu Apr 25, 2019 9:01 am If you're set on using filtered slots, you could fill the train by stopping at multiple different stations, each loading up to 12 items, before taking things where they need to go.

You can have up to 24 chests feeding a single cargo wagon. To do going from the wagon outwards you put down two row of 6 long arm inserters, and then two rows of 6 chests for a total of 12 chests and inserters per side. So if you do that on both sides you can have 24 chests and inserters per wagon. It looks a bit strange but it does work.