Found while running FLE's Lua stack in an unusual regime: a persistent multiplayer server where an LLM agent cohabits the map with a human player in real time (no fast-mode, real walking). Setup: https://github.com/bdambrosio/Cognitive_workbench (factorio/). We carry build-time patches for each of the issues we're filing; happy to turn any into a PR.
fle/env/mods/alerts.lua: the on_tick scanner writes alerts into
storage.alerts; storage.get_alerts(seconds) drains entries older than
the age window when read. There is no check that the underlying condition
still holds, so a line that has been refueled/unblocked keeps reporting
"out of fuel" / "no sink" / "result full" until the age window passes —
and in a long-running server the agent keeps acting on contradicted
alerts.
Two healthy steady states are especially noisy: a drill in
waiting_for_space_in_destination while its drop-target is working is
normal direct-insert behavior, not a fault.
Suggestion: on read (or on a slow tick), drop alerts whose entity's
current status contradicts them (working, or the over-feeding case
above). We run this as a host-side revalidation pass and it eliminated
the false-positive stream entirely.
Found while running FLE's Lua stack in an unusual regime: a persistent multiplayer server where an LLM agent cohabits the map with a human player in real time (no fast-mode, real walking). Setup: https://github.com/bdambrosio/Cognitive_workbench (
factorio/). We carry build-time patches for each of the issues we're filing; happy to turn any into a PR.fle/env/mods/alerts.lua: the on_tick scanner writes alerts intostorage.alerts;storage.get_alerts(seconds)drains entries older thanthe age window when read. There is no check that the underlying condition
still holds, so a line that has been refueled/unblocked keeps reporting
"out of fuel" / "no sink" / "result full" until the age window passes —
and in a long-running server the agent keeps acting on contradicted
alerts.
Two healthy steady states are especially noisy: a drill in
waiting_for_space_in_destinationwhile its drop-target isworkingisnormal direct-insert behavior, not a fault.
Suggestion: on read (or on a slow tick), drop alerts whose entity's
current
statuscontradicts them (working, or the over-feeding caseabove). We run this as a host-side revalidation pass and it eliminated
the false-positive stream entirely.