Hi, thanks for keeping this mod alive — the 5.8.x performance work is noticeable.
Reporting a repeating script error on 5.8.8.
Environment
- Factorio 2.0.77 (build 84539, win64, steam, space-age)
- Nanobots3 5.8.8
- stdlib2 2.0.1
- Space Age enabled
Error (repeats whenever a Roboport Interface is polled)
Script @__stdlib2__/stdlib/core.lua:45: Nanobots3:LuaConstantCombinatorControlBehavior doesn't contain key parameters.
Cause
scripts/roboport-interface.lua line 199:
local parameters = get_parameters(behaviour.parameters)
LuaConstantCombinatorControlBehavior::parameters was removed in the 2.0 API. Signals now live in logistic sections — behaviour.sections, each LuaLogisticSection having filters, where each filter has .value (SignalFilter) and .min (the count).
Because get_parameters receives nil, the interface reads no signals at all, so its network jobs (find items, chop trees, gather fish, deconstruct depleted miners) silently do nothing. Construction and repair are unaffected.
This looks like the sibling of the two calls handled in 5.8.1 under "Factorio 2.0 API Compatibility" — get_upgrade_direction() and get_upgrade_quality() were both addressed there, but this one wasn't.
Suggested patch
scripts/roboport-interface.lua, replacing get_parameters at line 70:
local function get_parameters(behaviour)
local parameters = {}
if not (behaviour and behaviour.valid) then
return parameters
end
for _, section in pairs(behaviour.sections or {}) do
if section.valid and section.active then
local multiplier = section.multiplier or 1
for _, filter in pairs(section.filters or {}) do
local signal = filter.value
if signal and signal.name then
parameters[signal.name] = (parameters[signal.name] or 0) + ((filter.min or 0) * multiplier)
end
end
end
end
return parameters
end
And at line 199:
local parameters = get_parameters(behaviour)
The section.active and section.multiplier handling is new behaviour with no 1.1 equivalent; drop it if you'd rather keep the change minimal.
I've been running this locally without the error returning, though I haven't stress-tested the interface's job scheduling.
Note that 5.8.9 and 5.9.0 both target 2.1, so 2.0.x users are currently on 5.8.8 with no path to a release containing this change.
