Hi,
I´m mildly annoyed by the Inserter behaviour. I´m supporting my defensives by burner inserters with a mixed belt of coal and ammo. Each time a turret gets blown up, my robots replace it, but that damn inserter is holding a piece of coal for the turret and therefor gets stuck
Possible change: Inserters should only start working, if there is something that "consumes" the Item (like, chests, another Inserter picking up from that possition, belts, etc).
Or in my special case: Consider ghost-prints like there is already the entity.
Inserters shouldn´t work without "output"
Moderator: ickputzdirwech
-
- Fast Inserter
- Posts: 117
- Joined: Wed Apr 06, 2016 4:01 am
- Contact:
Re: Inserters shouldn´t work without "output"
Well, this is the "residual item" problem with inserters, that not only plagues burner-inserter based designs. It's also a problem with smart loading of train wagons and smart furnaces. In all these cases good solutions are difficult or even impossible due to this.terror_gnom wrote:Possible change: Inserters should only start working, if there is something that "consumes" the Item (like, chests, another Inserter picking up from that possition, belts, etc).
Or in my special case: Consider ghost-prints like there is already the entity.
The problem with your proposed solution: there could be more than one inserter outputting to the same sink, and then neither of them can decide when if it's still OK to pick up an item for insertion.
Another proposal could be to allow the inserter to return the item to the item source when it finds that it cannot drop it for a short while. However, that might fail too, because the item source could be refilling constantly.
It's really very difficult to find a sound approach that removes this very annoying "residual item" behaviour.
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick
-
- Fast Inserter
- Posts: 117
- Joined: Wed Apr 06, 2016 4:01 am
- Contact:
Re: Inserters shouldn´t work without "output"
I didn´t explain it clearly: It shouldn´t check if there´s space (eg on a belt or chest) but if there is a possible sink. That way, it wont change much for running setups. If 2 Inserters try to work on the same sink, the game wont change.
Re: Inserters shouldn´t work without "output"
The problem happens also, if you have big blueprints and not enough furnaces, but much inserters and belts. The inserter grabs the wrong item from belt and the furnace will be never filled. And you don't see it, cause your blueprint contains 150 furnaces.
I think this is near to a bug.
My solution would that of terror_gnom: An inserter works for ghost prints as for real entities.
I think this is near to a bug.
My solution would that of terror_gnom: An inserter works for ghost prints as for real entities.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...
-
- Fast Inserter
- Posts: 117
- Joined: Wed Apr 06, 2016 4:01 am
- Contact:
Re: Inserters shouldn´t work without "output"
My problem is less the actual construction, but the ongoing problems when biter blow up my turrets which are supported by burner inserters (therefor its a mixed belt of coal and ammo). Sometimes, when a turret gets destroyed, the inserter picks up a piece coal and tries to insert it into the ghostimage. So I have to take a walk around my defense-walls every couple of hours to fix blocked inserters
*edit* an other solution would be, that the construction robots pick up the item, the inserter is currently holding (like in manual placement)
*edit* an other solution would be, that the construction robots pick up the item, the inserter is currently holding (like in manual placement)
Last edited by terror_gnom on Sat Aug 27, 2016 12:44 pm, edited 1 time in total.
Re: Inserters shouldn´t work without "output"
It's sometimes useful to make an inserter chain, where one inserter hands the item right into the next (without a sink in between). That would not work any longer if the inserter required an entity at the end point.terror_gnom wrote:I didn´t explain it clearly: It shouldn´t check if there´s space (eg on a belt or chest) but if there is a possible sink.
However, I could probably live with that. The current behaviour is more than just ugly. The inserter should not really operate while there's no drop-off location.
I don't really see how this will get the furnace stuck. The inserter will either pick a piece of ore or a piece of coal; both can be inserted into the furnace when it gets placed by the robot.The inserter grabs the wrong item from belt and the furnace will be never filled. And you don't see it, cause your blueprint contains 150 furnaces.
I can give an example, though, where it actually caused a problem: I have a blueprint for a nuclear facility (using the Nucular mod). The belt with the nuclear fuel contains both fresh as well as depleted fuel rods. When there is no reactor (yet), because it has not been placed yet, but the belt is already running with fuel, then the inserters will get stuck with the wrong item type in their hands.
So, as ssilk said, it can be problem with big blueprints that are not immediately completed. The inserters simply don't know what to do.
It would probably not hurt if the inserters recognized the ghost entity and behaved as if it was a real entity.
Is your railroad worrying you? Doctor T-Junction recommends: Smart, dynamic train deliveries with combinator Magick
-
- Fast Inserter
- Posts: 117
- Joined: Wed Apr 06, 2016 4:01 am
- Contact:
Re: Inserters shouldn´t work without "output"
I considered the pickup place of an Inserter as sink so it wouldnt change. A sink is everything that is capable of moving an item laying on the ground out of that tile or consumes it.siggboy wrote: It's sometimes useful to make an inserter chain, where one inserter hands the item right into the next (without a sink in between). That would not work any longer if the inserter required an entity at the end point.