What did you do?
Loaded a save in Factorio 2.1.12 (Space Age) and attempted to connect a red or green circuit wire to a transport belt by clicking it, as normal.
What happened?
Nothing at all. No wire is created and no error is shown. This affects every transport belt in the save:
All belt tiers — basic, fast, express, and turbo
Belts that already existed in the world and belts placed fresh, on open ground, with nothing adjacent
Every surface in the save (Nauvis, and off-world surfaces)
Every control mode — direct character control, remote view, and map view
Both directions — clicking belt-first, and dragging from a power pole onto a belt
Other entity types in the same save wire up completely normally. Power poles, combinators and inserters all accept circuit wires without issue. The problem is specific to transport belts.
What did you expect to happen instead?
The belt should accept the circuit wire connection.
Why this is not a normal "belt isn't connectable" situation
The belts are fully wire-capable. The engine will connect them — it is only the UI click path that fails.
1. The belt displays the connection indicator. Holding a red wire and hovering the belt shows the connection point exactly as it should. The game is presenting the belt as a valid wire target and then declining to commit the connection on click.
2. The belt reports both circuit connectors present.
/c local e=game.player.selected; local r=e.get_wire_connector(defines.wire_connector_id.circuit_red,true); local g=e.get_wire_connector(defines.wire_connector_id.circuit_green,true); game.print(e.name.." red="..tostring(r~=nil).." green="..tostring(g~=nil))
Output in the failing save:
turbo-transport-belt red=true green=true
3. The same connection succeeds when made through the API.
/c local p=game.player; local b=p.surface.find_entities_filtered{position=p.position,radius=20,type="transport-belt"}; game.print("belts="..#b); if #b>=2 then local a=b[1].get_wire_connector(defines.wire_connector_id.circuit_red,true); local c=b[2].get_wire_connector(defines.wire_connector_id.circuit_red,true); game.print("connect="..tostring(a.connect_to(c,false))) end
Output in the failing save:
belts=250
connect=true
So connect_to succeeds on the exact belts that refuse a mouse click. The resulting wire is created correctly, renders normally, and persists — the two belts form a working circuit network and behave normally thereafter. The connection is therefore fully valid in every respect; only the UI click path fails to create it.
4. The belts are otherwise completely normal. They show the standard white selection box on hover with an empty cursor, and can be mined, rotated, fast-replaced and blueprinted without issue.
Reproduction — two saves, one session, identical configuration
This is the core of the report. Two saves were created 29 seconds apart within a single game session, with no restart, no mod change, and no settings change between them:
Save
Saved at
Belt wiring
Test working
11:50:51
Works normally, all tiers
Test failing
11:51:20
Fails on every belt
Because both were loaded in one session without restarting, they necessarily share a single loaded prototype set. The difference cannot be prototype data.
Their level-init.dat files are byte-for-byte identical — both 1,138,679 bytes, with zero differences at the string level. That file carries the mod list and all startup settings, so mod configuration and startup settings are provably identical between the two saves.
Both saves report Map version 2.1.12-2, native to the running version. Loading either applies zero migrations, and the attached log contains zero errors or warnings:
Loading map ...\Test failing.zip: 39619384 bytes.
Info Scenario.cpp:152: Map version 2.1.12-2
Loading map ...\Test working.zip: 37655351 bytes.
Info Scenario.cpp:152: Map version 2.1.12-2
The only file that differs between the two saves is level.dat itself.
History of the world, in case it is relevant: this playthrough began before 2.1, and the underlying map was migrated up from 2.0.77-0 when 2.1.12 was installed. Both test saves above were written after that migration, in 2.1.12. The bug was first noticed on the post-migration save.
Things ruled out
Mods. Reproduces with all six non-DLC mods disabled (only base, space-age, quality, recycler and elevated-rails active).
Belt tier. All four tiers fail, including turbo.
Pre-existing entity state. Belts placed fresh during the failing session also refuse connection.
Adjacent-entity interference (cf. [2.0.28] report). A fresh belt on empty ground with nothing nearby still fails.
Reach / distance checks (cf. [15.9] "Circuit wire does not connect close to max reach"). Standing directly on top of the belt does not help. character_build_distance_bonus, character_reach_distance_bonus, character_resource_reach_distance_bonus, build_distance and reach_distance are all identical between the working and failing saves.
Control mode. Fails identically under character control, remote view and map view.
Force mismatch. Belt force and player force match.
Connections being actively removed. A wire created via connect_to persists and functions normally, so nothing is tearing connections down after creation. The click is simply not producing a connection.
Version and system
Factorio 2.1.12 (build 87038, win64, steam, space-age)
Operating system: Windows 11 (build 26200)
CPU: 12th Gen Intel(R) Core(TM) i9-12900H, 20 cores
RAM: 16124 MB
GPU: NVIDIA GeForce RTX 3070 Ti Laptop GPU, driver 32.0.16.1047
Save map version: 2.1.12-2 (world originally created pre-2.1, migrated up from 2.0.77-0)
Mods present when first observed (bug reproduces with all of these disabled):
base 2.1.12, space-age 2.1.12, quality 2.1.12, recycler 2.1.12, elevated-rails 2.1.12
colorblind_ultimate 2.7.0
Kruise_Kontrol_Updated 0.4.0
light-overhaul 0.3.0
mining-patch-planner 1.7.21
Pi-C_lib 2.1.0
squeak-through-2 0.2.0
Attachments
Test failing.zip — belts refuse circuit wires - https://drive.google.com/file/d/1XV2-oL ... sp=sharing
Test working.zip — same session, same config, belts wire normally - https://drive.google.com/file/d/1L96cfQ ... sp=sharing
bugreport-BOTH-SAVES-NO-MODS-2.1.12.log — single unmodded session loading both saves back to back
The attached log is one session with no third-party mods loaded at any stage, in which Test failing was loaded (bug present) and then Test working was loaded without quitting (bug absent). Both maps therefore ran against one identical prototype set. Its full mod load list is:
core 0.0.0 (data.lua)
base 2.1.12 (data.lua)
elevated-rails 2.1.12 (data.lua)
recycler 2.1.12 (data.lua)
quality 2.1.12 (data.lua)
space-age 2.1.12 (data.lua)
base 2.1.12 (data-updates.lua)
recycler 2.1.12 (data-updates.lua)
space-age 2.1.12 (data-updates.lua)
That run loaded Test failing.zip and the bug reproduced.
