What kind of issue is this?
What is the problem?
Used a combination of loader utils and deadlock's stackboxes and loaders. The loaders do not upgrade via upgrade planner, both with a blank planner and with a specified upgrade target. They do work under a couple of unusual conditions. One is through a blueprint sandbox (https://mods.factorio.com/mod/blueprint-sandboxes?from=search). The other is by turning off lane filtering.
I used claude to help troubleshoot and this is what it had to say:
"Let me dig into the actual source code of these mods — that's a much better bet than the log for this kind of interaction bug.This is looking very promising. Let me verify a couple more things — whether the "lf-"/"rl-"/"fs-" variant prototypes get their own placeable items, and how Deadlock defines its loader tiers/next_upgrade chain.I found it — and it's a genuinely subtle interaction, not something you'd catch from a log. I cloned all three mods and traced through the actual logic.
What's happening
Loader Utilities doesn't just watch loaders — it silently replaces them. Every time a loader is built (control.lua, on_built_entity/on_robot_built_entity), it calls a replace() function that mines the entity you just placed and spawns a different hidden prototype in its place, based on three per-player settings: lane filtering, respecting machine limits, and full-stack-only.
The catch: lu-lf-default ("Loaders are lane filtered by default") ships set to true. So unless you've turned that off, every single loader you place — including Deadlock's — gets immediately swapped from e.g. transport-belt-loader to a hidden clone named lf-transport-belt-loader.
Those hidden clones are created in data-final-fixes.lua via table.deepcopy() for every combination of the three settings (8 variants per tier). Critically, loader-utils never creates an item prototype for any of them — I checked, there's no data:extend{{type="item",...}} anywhere for these. Deadlock's real loaders each have exactly one backing item with place_result pointing at the real entity. The lf-/rl-/fs- clones have none — they only exist because the mod's script conjures them directly with surface.create_entity.
That's the actual bug: the loader sitting in your world is a script-only phantom prototype with no item behind it. The Upgrade Planner — whether blank (which walks next_upgrade) or explicitly mapped — ultimately needs an item to hand to a construction bot or pull from your inventory to build the upgrade target. There isn't one, so the upgrade silently can't execute. I found a Factorio forum thread from a mod author with the exact same architecture (hidden hot-swapped prototype clones) independently describing this as a known limitation of the upgrade planner.
This also explains your other two data points perfectly:
- Beltboxes upgrade fine because loader-utils only touches
type = "loader"/"loader-1x1" entities — beltboxes are furnace-type, completely invisible to it.
- It works in Blueprint Sandboxes because that mod puts you in Factorio's editor/god controller mode on its sandbox surfaces (confirmed in its
scripts/controllers.lua), and editor mode bypasses normal item/inventory requirements for construction entirely — so the missing-item problem never surfaces there."
Immediate workaround
Go to Settings → Mod Settings → Per Player and turn off "Loaders are lane filtered by default." With all three defaults off, freshly-placed loaders stay as Deadlock's real, item-backed prototypes, and the upgrade planner should work exactly as it does with loader-utils disabled. You can still manually re-enable lane filtering per loader afterward via the checkbox that appears when you open a loader's GUI — you'll just lose the "on by default" convenience.
For the developer
If you want to go back to protocol-1903, the precise, actionable bug report is: "The lf/rl/fs variant loader prototypes created in data-final-fixes.lua have no backing item, so the Upgrade Planner can't build them — not even via the next_upgrade chain you set up correctly for them." The clean fix would be listening for defines.events.on_marked_for_upgrade in control.lua and performing the swap themselves (using the same replace() logic they already use for building), rather than relying on vanilla's engine-level upgrade mechanism, since that mechanism assumes every upgrade target has a real item.
Steps to reproduce
- install both deadlock's stacking beltboxes and loaders (https://mods.factorio.com/mod/deadlock-beltboxes-loaders) and loader utils
- Go ingame and try to upgrade them with the upgrade planner. Uncheck lane filtering to verify that it does work without lane filtering.
Additional context
No response
Log file
factorio-current.log
What kind of issue is this?
What is the problem?
Used a combination of loader utils and deadlock's stackboxes and loaders. The loaders do not upgrade via upgrade planner, both with a blank planner and with a specified upgrade target. They do work under a couple of unusual conditions. One is through a blueprint sandbox (https://mods.factorio.com/mod/blueprint-sandboxes?from=search). The other is by turning off lane filtering.
I used claude to help troubleshoot and this is what it had to say:
"Let me dig into the actual source code of these mods — that's a much better bet than the log for this kind of interaction bug.This is looking very promising. Let me verify a couple more things — whether the "lf-"/"rl-"/"fs-" variant prototypes get their own placeable items, and how Deadlock defines its loader tiers/next_upgrade chain.I found it — and it's a genuinely subtle interaction, not something you'd catch from a log. I cloned all three mods and traced through the actual logic.
What's happening
Loader Utilities doesn't just watch loaders — it silently replaces them. Every time a loader is built (
control.lua,on_built_entity/on_robot_built_entity), it calls areplace()function that mines the entity you just placed and spawns a different hidden prototype in its place, based on three per-player settings: lane filtering, respecting machine limits, and full-stack-only.The catch:
lu-lf-default("Loaders are lane filtered by default") ships set totrue. So unless you've turned that off, every single loader you place — including Deadlock's — gets immediately swapped from e.g.transport-belt-loaderto a hidden clone namedlf-transport-belt-loader.Those hidden clones are created in
data-final-fixes.luaviatable.deepcopy()for every combination of the three settings (8 variants per tier). Critically, loader-utils never creates anitemprototype for any of them — I checked, there's nodata:extend{{type="item",...}}anywhere for these. Deadlock's real loaders each have exactly one backing item withplace_resultpointing at the real entity. Thelf-/rl-/fs-clones have none — they only exist because the mod's script conjures them directly withsurface.create_entity.That's the actual bug: the loader sitting in your world is a script-only phantom prototype with no item behind it. The Upgrade Planner — whether blank (which walks
next_upgrade) or explicitly mapped — ultimately needs an item to hand to a construction bot or pull from your inventory to build the upgrade target. There isn't one, so the upgrade silently can't execute. I found a Factorio forum thread from a mod author with the exact same architecture (hidden hot-swapped prototype clones) independently describing this as a known limitation of the upgrade planner.This also explains your other two data points perfectly:
type = "loader"/"loader-1x1"entities — beltboxes arefurnace-type, completely invisible to it.scripts/controllers.lua), and editor mode bypasses normal item/inventory requirements for construction entirely — so the missing-item problem never surfaces there."Immediate workaround
Go to Settings → Mod Settings → Per Player and turn off "Loaders are lane filtered by default." With all three defaults off, freshly-placed loaders stay as Deadlock's real, item-backed prototypes, and the upgrade planner should work exactly as it does with loader-utils disabled. You can still manually re-enable lane filtering per loader afterward via the checkbox that appears when you open a loader's GUI — you'll just lose the "on by default" convenience.
For the developer
If you want to go back to protocol-1903, the precise, actionable bug report is: "The lf/rl/fs variant loader prototypes created in
data-final-fixes.luahave no backing item, so the Upgrade Planner can't build them — not even via thenext_upgradechain you set up correctly for them." The clean fix would be listening fordefines.events.on_marked_for_upgradeincontrol.luaand performing the swap themselves (using the samereplace()logic they already use for building), rather than relying on vanilla's engine-level upgrade mechanism, since that mechanism assumes every upgrade target has a real item.Steps to reproduce
Additional context
No response
Log file
factorio-current.log