Write handler for LuaEntity::pickup_target/drop_target
Posted: Mon Jul 09, 2018 5:07 am
I'm working on implementing 3-way splitters as discussed here. The idea is as follows:
Input side: 3x inserters picking items off belts associated with 3x loaders (for belt connectivity).
Output side: 6x inserters dropping items into left/right lanes of 3x loaders (for belt connectivity).
Internal: container as a buffer, allowing distribution between the output belts.
Unfortunately it is not currently possible to do this in a 3x1 footprint, because when an inserter's pickup/drop_position is set to a tile containing multiple valid entities, the entity selected as the target is semi-random. (I surmise it is the first in internal iteration order.)
Being able to designate a pickup/drop_target directly would enable the above use case. Other possible interesting use cases:
Machines/buildings with direct belt interaction, a.k.a. integral "loaders," as in TheBigFurnace or Factorissimo, but using inserters for better performance, circuit/logistic network control, and/or lane-specific output.
This would also allow Miniloaders to work around the issue of insufficient inserter throughput when picking up from a fast modded belt. I could use a loader to move items from a belt to a container in the same map tile as the loader, then use an inserter to transfer from the container to the target cargo wagon. Currently, it is impossible to reliably set up an inserter with the container as its pickup_target, instead of accidentally having it select the loader or other belt entity in the same tile.
Input side: 3x inserters picking items off belts associated with 3x loaders (for belt connectivity).
Output side: 6x inserters dropping items into left/right lanes of 3x loaders (for belt connectivity).
Internal: container as a buffer, allowing distribution between the output belts.
Unfortunately it is not currently possible to do this in a 3x1 footprint, because when an inserter's pickup/drop_position is set to a tile containing multiple valid entities, the entity selected as the target is semi-random. (I surmise it is the first in internal iteration order.)
Being able to designate a pickup/drop_target directly would enable the above use case. Other possible interesting use cases:
Machines/buildings with direct belt interaction, a.k.a. integral "loaders," as in TheBigFurnace or Factorissimo, but using inserters for better performance, circuit/logistic network control, and/or lane-specific output.
This would also allow Miniloaders to work around the issue of insufficient inserter throughput when picking up from a fast modded belt. I could use a loader to move items from a belt to a container in the same map tile as the loader, then use an inserter to transfer from the container to the target cargo wagon. Currently, it is impossible to reliably set up an inserter with the container as its pickup_target, instead of accidentally having it select the loader or other belt entity in the same tile.