Ah, so you meant "The callback is only called once per item". And I assume you meant to say "Input", not "Output".
Not the same as explicit removal though, an item being handled by lane-to-lane transfer later in the filter list would also be removed, just not explicitly.
And that still means a call into the mod code for each single passing item, regardless of whether the modded entity is internally clogged (or output restricted) or not.
The ideal however is to have a cost linear in the number of actually processed items, not in the number of arriving ones.
Otherwise, the pass through functionality brings no performance benefits as soon as there is any callback registered at all.
Let me try to model a few scenarios. Let's say we have a 1x1-entity with. And for simplicity, let's enumerate the lanes by cardinal direction, with the input in the south such as lane<side><lane>. I'm going to omit the explicit notion of input and output lanes.
An sieve for stones, dropping stones from each lane to the sides and routing everything else straight through, would then look like this:
Code: Select all
laneSW.set_auto_connection([
{items: ["Stone"], outputs: [laneWN, laneWS]},
{items: ["*"], outputs: [laneNW]}
]);
laneSE.set_auto_connection([
{items: ["Stone"], outputs: [laneEN, laneES]},
{items: ["*"], outputs: [laneEW]}
]);
Lane balancer:
Code: Select all
laneSW.set_auto_connection([
{items: ["*"], outputs: [laneNW, laneNE]}
]);
laneSE.set_auto_connection([
{items: ["*"], outputs: [laneNE, laneNW]}
]);
The belt splitter from the OP:
Code: Select all
laneEN.set_auto_connection([{items: ["*"], outputs: [laneNE]}]);
laneES.set_auto_connection([{items: ["*"], outputs: [laneSE]}]);
laneWN.set_auto_connection([{items: ["*"], outputs: [laneNW]}]);
laneWS.set_auto_connection([{items: ["*"], outputs: [laneNS]}]);
Belt-fed smelter:
Code: Select all
function takeOre(lane)
-- This is called way to often....
if hasOre then return false end
item = lane.pop_next_item()
-- Do stuff with item
return true
end
function takeFuel(lane)
-- This is called way to often....
if hasFuel then return false end
item = lane.pop_next_item()
-- Do stuff with item
return true
end
function smelt()
end
function smeltFinished()
for lane in [laneNW, laneNE] do
if lane.can_push_item() then
lane.push_next_item(output)
return
end
end
-- This is now a problematic situation, this entity got output stalled!
end
for lane in [laneSW, laneSE] do
laneSW.set_auto_connection([
{items: ["Ore"], callback: takeOre},
{items: ["Coal"], callback: takeFuel}
]);
end
If a callback happens to store a reference an item without actually returning true, then it would cause possibly invalid references.
And a callback returning true without actually destroying or storing the item results in leaking that item.
A callback when a clogged output lane becomes free is inevitable.
Well, no, actually you would want to be able to wait on multiple output lanes at once, and just be informed which the first free one was. E.g.:
Code: Select all
-- Just a draft
function on_can_push(lane_list, callback)
for lane in lane_list do
if lane.can_push_item() then
callback(lane)
return
end
end
-- And now the nasty bookkeeping would begin...
-- The hackjob solution would be to repeat this now every single game tick...
end
-- Example use
on_can_push([lane1, lane2], function (lane) lane.push_next_item(item) end)
It's essentially the same requirement as on the output lane for set_auto_connection().
I am not sure about leaving this callback permanently registered though. Respectively what the logic for "no polling" would be. You wouldn't actually want to keep this callback to be triggered on every single gap, but only if the callback could have an effect in the first place. So one-shot is more reasonable.
However, worst case scenario would actually be to splice a dense belt onto two half-clogged belts via logic with a minor backlog, as that would mean a fast toggle between input- and output stalled. And for that, you wouldn't want to re-register all the time either...
That's no good, there are legit arguments pro and contra one-shot callbacks.
Trinary return values could be the solution, "I took the item / filled the slot", "I did nothing, but keep me posted", "I'm done, sign me of". Whereby the first one can actually be turned into an explicit choice, by explicitly calling push/pop on the corresponding lane. The first callback modifying the lane would then stop the bubbling, while the return value only designates if the callback is to be re-used ASAP.
Positive side effect: That provides also the ability to build belt throughput counters, as requested multiple times.
I'm actually quite curios, how the handover from items onto stop and go belts is currently handled internally. With a bit of luck, there is already some suitable structure in place which only needs to be exposed.
