[0.12.26] Inserters get stuck feeding stone to furnace

Bugs that are actually features.
User avatar
nightingale
Burner Inserter
Burner Inserter
Posts: 18
Joined: Wed Jan 13, 2016 3:25 pm
Contact:

Re: 0.12.26 alpha - Inserters get stuck feeding stone to furnace

Post by nightingale »

Okay, I'll bite on this one. Here's another way that we can get the same behaviour (stuck inserter):

* Have a belt with different items on each side.
* Set up an assembler that takes only one of the items
* Blueprint it
* Lay the blueprint down

Now, the following may occur, and result in a stuck inserter:
* The robots place the inserter and belt before the assembler
* The belt fills up before the assembler is placed
* The inserter picks up the "wrong" item before the assembler goes down

If the above occurs, you get the same situation.

Loewchen
Global Moderator
Global Moderator
Posts: 8354
Joined: Wed Jan 07, 2015 5:53 pm
Contact:

Re: 0.12.26 alpha - Inserters get stuck feeding stone to furnace

Post by Loewchen »

daniel34 wrote:This is not a bug. The furnace has 'generic' inputs, where the item in the slot determines what's being created, so the inserter can't know it shouldn't insert the copper ore.
I would still argue that it is a bug as the inserter is able to determine if it can insert if the target is a chest or cargo wagon which have generic slots as well. To me the behavior with furnaces is inconsistent. But I would agree that it is questionable if it is worth fixing.

GotLag
Filter Inserter
Filter Inserter
Posts: 532
Joined: Sat May 03, 2014 3:32 pm
Contact:

Re: [0.12.26] Inserters get stuck feeding stone to furnace

Post by GotLag »

I've discovered some... interesting furnace/inserter interaction with one of my mods.
The incinerator uses the furnace type, and has its own dedicated pool of recipes (a recipe for each item type in the game, taking one item as input, and producing 0 water as output - effectively consuming the item to produce nothing).

What I've found is that if the inserter's cycle time is not significantly slower than the incinerator operation time, it shuts down on mixed belts. As best I can tell, this is the sequence of events:

0. Inserter has been happily feeding copper ore into the incinerator for some time.
1. Inserter picks up a piece of copper ore.
2. Inserter rotates and places copper ore in the incinerator.
3. The incinerator starts processing and the inserter begins rotating back.
4. The inserter reaches its pickup position, queries the incinerator, and is told the incinerator will accept copper ore (as that is what it is processing).
5. There is no copper ore in reach of the inserter, only a belt full of stationary iron ore. The inserter waits.
6. The incinerator finishes its operation, clears its recipe.
7. The inserter waits forever.

Now here's the problem: at this point a regular furnace would have its output inventory modified, and this would trigger an update to the inserter. But my incinerator has no output, so no update is sent. Anything that causes the inserter to update will break the lock: modifying the fuel/input inventories of the incinerator, or movement on the belt in front of the inserter. But if the belt is stationary, the inserter will never move, waiting in front of an empty incinerator forever.

There's something missing in my understanding of the sequence of events though, as it is possible to have the inserter stuck holding an item over the top of the empty incinerator. To do this, have an incinerator fed by a fast inserter, and use a yellow belt to bring it two distinct items at the same time.
Video

GotLag
Filter Inserter
Filter Inserter
Posts: 532
Joined: Sat May 03, 2014 3:32 pm
Contact:

Re: [0.12.26] Inserters get stuck feeding stone to furnace

Post by GotLag »

On the original topic of this thread, I think there's a good reason to change the way furnaces interact with inserters: it's different from how other entities behave.
If a chest has no empty slots, but does have partially-filled ones, an inserter will only pick up items that can be placed in it. If an assembler has a recipe set, inserters will only pick up items that can go in the (filtered) input slots.

If the furnace doesn't yet have a recipe selected, inserters should only load it with whatever will actually fit in its input slot(s): if the slot is empty, anything smeltable. If there are items in the slot(s) already, then only matching items. If I limit a chest to a single slot, and I put one stone in it, an inserter is not going to then pick up a piece of iron ore and attempt to put that in it as well. So why does it do that for a furnace? It's a very irritating inconsistency.

If I have a mixed belt of stone and iron ore, and my furnace has one stone in it and gets stuck because the belt in front of the inserter has only iron ore, I can accept that. That's a reasonable planning failure - and getting the belt moving again will clear it.
If the same furnace with a single stone inside gets stuck because the inserter is trying to load a piece of iron ore even though there's stone rolling past it, that's incredibly frustrating, not just because it's a counter-intuitive and inconsistent behaviour, but because it also requires removing/replacing inserters or clearing furnace inventories.

zolcsika71
Manual Inserter
Manual Inserter
Posts: 1
Joined: Wed Jun 08, 2016 11:55 am
Contact:

Re: [0.12.26] Inserters get stuck feeding stone to furnace

Post by zolcsika71 »

I think its a bug with the furnaces, but i found out a bigger one. I have furnaces which feeding only from iron mines, but time to time the iron mines make STONE and NOT IRON. However there is no stone at that area.
It will lead the situation u mentioned.

loganb
Inserter
Inserter
Posts: 44
Joined: Mon Jul 25, 2016 3:58 am
Contact:

Re: [0.12.26] Inserters get stuck feeding stone to furnace

Post by loganb »

viewtopic.php?f=47&t=33342

So, I think there is still an issue here. As I posted on that other thread, the inserters clearly respect whatever is in the output slot of the furnace (i.e. it won't load copper ore into a furnace with iron plate in the output buffer), but they don't respect what's in the input buffer.

On one hand, I can understand the intent of not making the inserters too smart, but on the other, they're already half as smart as they need to be and since furnaces can't be connected to the circuit network, it seems to make for more compelling gameplay to fix this issue.

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12888
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: 0.12.26 alpha - Inserters get stuck feeding stone to furnace

Post by ssilk »

nightingale wrote:Okay, I'll bite on this one. Here's another way that we can get the same behaviour (stuck inserter):

* Have a belt with different items on each side.
* Set up an assembler that takes only one of the items
* Blueprint it
* Lay the blueprint down

Now, the following may occur, and result in a stuck inserter:
* The robots place the inserter and belt before the assembler
* The belt fills up before the assembler is placed
* The inserter picks up the "wrong" item before the assembler goes down

If the above occurs, you get the same situation.
Ah, that one is the interesting one! I haven been fallen into that situation many times now and it is really a mess, cause you don't see, that it is broken. Because of that I think that is a bug, cause my opinion about blueprints is, that they need to be very reliable. There is currently really no way to be sure, that the blueprint is really working (but there are many other issues with the blueprints and I think they will be fixed in one of the next versions).

PS: This topic isn't a bug. As explained: It's part of the challenge. There are tons of threads about how to feed the furnaces automated (see viewforum.php?f=193 Combinator Creations) and you can always change the whole construction in a way where mixed furnaces aren't needed. It's just part of the game. :)
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

Post Reply

Return to “Not a bug”