Long Handed(?) Inserter Bug

[jonbrave]

Even though I'm only a noob, I'm confident there is some bug to do with inserters failing to insert into my Assemblers. I am unsure of the exactitudes, but I think it may be to do with Long Handed Inserters failing to insert into my Assembler even though an input is available. It may be that my situation is a bit unusual compared to what you guys normally do, so perhaps it does not affect you.

I am set to use the latest 16.x. I don't know if the problem has always been there, but it certainly is now.

Here is a screenshot:

http://steamcommunity.com/sharedfiles/filedetails/?id=1298166530

Unfortunately, it's a bit after I have had the bug and rectified it, but let me describe what happened.

I keep noticing that an Assembler is not receiving a certain input even though it is available for the inserter to fetch. In the example, the Assembler "highlighted" needs Steel Plates & Pipes from the bottom belt, and Cogs from the upper belt.

I newly built the Assembler a few minutes ago. At that time the bottom belt was perfectly full of both Steel Plates & Pipes (I promise!). And the top belt was full of Cogs.

I cannot be sure whether I placed the Assembler first and then the Inserters (that's the most likely), though it's possible I placed an Inserter before the Assembler. Simialrly I cannot be ceratin exactly when I chose its output to be Engines.

What then happens is that the bottom inserter does pull both inputs, but the top, long handed inserter just sits there not pulling any cogs, so my Assembler does not build anything.

The solution is always to delete the long handed inserter and put it back exactly the same as it was. (And btw, yes, I am certain I did not have the inserter originally facing the wrong way round, promise!) Then miraculously it jumps into life and starts fetching the Cogs. I cannot recall whether changing what the Assembler builds back to same thing also sorts it out.

This seems to have happend to me multiple times with different Assemblers (though not always). I cannot be sure of the pattern.

• It may only happen when I build a new Assembler.
  
• It may only happen if a long-handed inserter is involved.
  
• It may only happen if the long-handed inserter has to fetch from the far side of the far belt.
  
• It may only happen if at the time the Assembler/Inserter is placed the belt is already full of necessary inputs (as opposed to a new input arrives for the inserter to see). I have a vague feeling that this may need to be the case.

That's all I can think of at present. It's particularly irritating because if you don't notice it you just end up with an Assembler which is not producing anything even though all the required inputs are available, which can take a while till I happen to notice it.

I trust you expert guys are clever enough to be able to figure out what the precise situation must be from the description I've given!

[Killcreek2]

Was the output slot of the assembler full?
I have often noticed that if the output slot is backed-up, then no further input resources will be added even if the assembler is (almost) empty of those input materials. Once the blocked output slot is cleared, the input inserter(s) then activate to restock the machine as normal.


If you notice it happening again: make a new save file immediately, then try loading that save to see if the issue persists. If so, you can upload it somewhere (dropbox, google drive, etc) & put a link to it here, so others can verify / check it out.

[jonbrave]

Yep, understood. No, I do not believe the output slot of the assembler was full. Once it happens it sits there never doing anything forever, till seemingly I delete and replace it, whereupon it immediately behaves correctly from then on.

This has happened to me several times over my game. Different assembler inputs/outputs, I believe. As I said, it is possible they always involve a long hand inserter.

I will save next time if it happens, and follow your advice.

[denebarry]

If you placed the long inserter before the assembler it probably picked up an iron plate off the top belt & had no where to place it?

[jonbrave]

Hmm, interesting possibility, that would presumably explain the behaviour.

Why would the LHI pick up a plate --- or indeed anything --- if I placed it before the Assembler? Is it just bored and it picks up something/anything randomly before I have put the Assembler down?

And for the record, if it does pick up something wrong is the correct/only way to "clear" it to remove it and rebuild it?

[Killcreek2]

Originally posted by jonbrave:

Hmm, interesting possibility, that would presumably explain the behaviour.

Why would the LHI pick up a plate --- or indeed anything --- if I placed it before the Assembler? Is it just bored and it picks up something/anything randomly before I have put the Assembler down?

If it has a valid destination target, it will dutifully grab whatever is available to place it there ~ an empty ground tile counts. If you then place the assembler down before the arm completes the swing, it may well be stuck holding that item with nowhere to put it.

And for the record, if it does pick up something wrong is the correct/only way to "clear" it to remove it and rebuild it?

Pretty much. Sometimes you can rotate it 90deg (if there is an empty tile nearby), then rotate it back instead. Or if it has already completed the swing & is hovering over the destination tile, building something on that tile (eg; assembler) will clean both the tile & inserter hand of any loose items.

[jonbrave]

Thanks, Kill & dene.

Despite my originally claiming this was a deffo bug, the above sounds so plausible that I fear it may be the case. (Presumably it might have grabbed either thing from the top-belt, so plate vs cog was just random.)

In this sense, it would be better to put down the Assembler before the inserters when building.

More to the point, presumably the following too: I have an Assembler building something presently. I go in and change over to a different output. It so happens that when I changed an input inserter was already in mid-fetch, so its hand is holding something. If that thing is no longer wanted by the new recipe, it won't drop what it's holding and so it blocks? I would have thought that might happen by accident all the time.

[Killcreek2]

Originally posted by jonbrave:

Presumably it might have grabbed either thing from the top-belt, so plate vs cog was just random.

It will try to pick from closest belt lane first if there are items on it ~ in your picture, that would indeed be the iron plates side of the belt.

In this sense, it would be better to put down the Assembler before the inserters when building.

Yes, but as inserters no longer try to place items into ghost structures, a ghost assembler would work just as well (devs fixed this recently, yay!).

More to the point, presumably the following too: I have an Assembler building something presently. I go in and change over to a different output. It so happens that when I changed an input inserter was already in mid-fetch, so its hand is holding something. If that thing is no longer wanted by the new recipe, it won't drop what it's holding and so it blocks? I would have thought that might happen by accident all the time.

You are correct: I have seen this happen before, exactly as you have just described.
A good habit to get into is to take a moment to double-check the in & out inserters if you change a recipe in an existing machine.
Though, other than during early game or when doing a Lazy Ba---rd cheevie run, there is little reason to change recipes outside of the player shoppe area.

[jonbrave]

Yep, thanks again, this will doubtless turn out to be the root of what I have been seeing.

I thought about it too: You professionals will rarely change what an Assembler is manufacturing once you've placed it 'coz your factories are all layed out logically with separate areas. Bumbling noob like me is playing with changing what certain assemblers are producing in random places, trying to test out a new balance or squeeze an extra producer in. That's probably why I'm more likely to see this problem than you guys :)