I just love blueprints. But sometimes they cause unindendet behaviours with inserters when they are placed early.
Specifically I have problems with 2 cases:
1) the inserter picks up anything from it's source tile and then can't deliver it and is stuck.
I had burning inserters pick up copper while their target (e.g. a boiler) only accepts coal. The boiler will then never get any coal. The burning inserter then has to be removed and placed again. Other cases I had inserters pick up alien artefacts and try to insert them into gun turrets. Not working right.
2) the inserting inserter handing things to the exerting inserter due to lack of furnace/assembler
I have a few blueprints where the inserting and exerting happens from the same tile, e.g. for a furnace. Now if the furnace is not placed early on the inserting inserter will pick up iron ore, move it to where the furnace will be and hand it to the exerting inserter. That will then place it on the output belt. Now suddenly instead or iron plates the belt carries iron ore and I have to track down where it all went when I notice.
My suggestion for a fix would be that ghosted items should already change the pickup behaviour of inserters as if they where placed.already. So a inserter in front of a ghosted boiler should only pick up fuel. And an exerting inserter should not pick anothers inserters hand. The current behaviour makes automation fragile.
PS: Not sure if this falls into the same category of "bug" but an electric miner will output ore onto a deconstructed belt. I had construction robots continiously fly to pick up the ore from a belt so it can be removed and it always getting replaced before they could actually remove the belt. Would be nice if a deconstruction counts as the tile being blocked.
Unindendet behaviour for inserters with blueprinting
Re: Unindendet behaviour for inserters with blueprinting
This is not a bug, the best method to avoid all of that, is to not connect the belts to the BP setup before it is finished.
Re: Unindendet behaviour for inserters with blueprinting
That creates the problem of burner inserters picking up non-fuel before fuel when the belts get connected and then they get stuck without energy.
Re: Unindendet behaviour for inserters with blueprinting
Then it would be a good idea to not connect the non fuel belts first...mrvn wrote:That creates the problem of burner inserters picking up non-fuel before fuel when the belts get connected and then they get stuck without energy.
Re: Unindendet behaviour for inserters with blueprinting
Or we could fix the inserters in such a way that things can be automated more. Think of a giant blueprint for an outpost where you only build a starting seed and it builds the materials to complete the blueprint locally.Loewchen wrote:Then it would be a good idea to not connect the non fuel belts first...mrvn wrote:That creates the problem of burner inserters picking up non-fuel before fuel when the belts get connected and then they get stuck without energy.
Re: Unindendet behaviour for inserters with blueprinting
Feel free to make a development suggestion for that.mrvn wrote:Or we could fix the inserters in such a way that things can be automated more. Think of a giant blueprint for an outpost where you only build a starting seed and it builds the materials to complete the blueprint locally.
Re: Unindendet behaviour for inserters with blueprinting
Well, I considered it a bug because it breaks automation. Feel free to move this thread to Ideas & Suggestions instead.Loewchen wrote:Feel free to make a development suggestion for that.mrvn wrote:Or we could fix the inserters in such a way that things can be automated more. Think of a giant blueprint for an outpost where you only build a starting seed and it builds the materials to complete the blueprint locally.