Factorio Forums

Title. The bizarre thing is that this only started happening now and it only happens to the newly built 20 powerplants - i have 180 powerplants that were built way before and when their inserters get locked out of placing an item mid-swing they just stay like this:



I want to reiterate that these two behaviors are happening simultaneously. The only difference between power plants that are doing it and don't is that the older ones were built on an older factorio version more than 250h ago (in playthrough time). The bug was previously reported to pY devs but they told me to redirect it here.

Save with pins for both power plants groups: https://drive.google.com/file/d/17nKt46 ... sp=sharing

Ref.: 125212

You've enabled the control behavior on the assembling machines and when they have a control behavior the insertion of items will fall back to the "dump" inventory if it doesn't fit into the energy source, and is not used by the current recipe.

Because the energy inventory can only ever hold 1 item type and the inserters are grabbing mixed fuel the "doesn't fit" fuel gets put into the dump inventory.

The *reason* it goes to the dump inventory is: the recipe for the assembler may change between the inserter picking up the item and it getting to the machine. If the item the inserter is trying to insert isn't used by the current recipe - it goes to the dump to be removed. If it didn't do this - change-recipe assemblers would constantly get stuck inserters holding items for previous recipes.

I could add 1 more rule that "if it's fuel and accepted by the energy source, then don't go to the dump inventory" but that also risks inserters getting stuck if any of the recipes used fuel-having items (such as several gleba recipes).

In your case you can simply filter the inserters to only put 1 fuel type in. Or, use 1 inserter which will never try to put fuel in that it doesn't already have. Or, don't use control behaviors on the assemblers (don't hook them up to wires).

Rseding91 wrote: Thu Dec 11, 2025 9:12 pm Or, don't use control behaviors on the assemblers (don't hook them up to wires).

You mean globally, on any machines? I never wired any of those coal powerplants, old or new.

also, i definitely attached wires to assemblers way way before this started to happen. my first attached wire was at around 300h (with new powerplants working without this bug) and this started to happen after 1200th hour

Here, i checked it on a new clean save without attaching wires to anything, this still happens regardless of wiring stuff

Press F4 and check the "show-entity-control-behaviors" option. You'll see that one of the mods you're using is creating the behavior on the assembler. Specifically at least "perel" https://mods.factorio.com/mod/perel is forcing it to exist in every single entity built that supports control behaviors.

Note this is *absolutely terrible* for performance since it means every single belt in your save that you built after adding it is having its transport lines force split making the entire transport belt system slower.

Based off the save file, it shows you added that mod fairly recently. If you remove it, any newly build factories and belts won't be force-creating their control behaviors.

Noted. Also: viewtopic.php?t=132045

After thinking about this more, I’m going to make some tweaks for 2.1:

* The put into dump inventory will only happen if the behavior is active (has wires), and is doing set-recipe.
* The logic in that scenario will only expand the inventory to 1 slot (from zero), or fill existing stacks. So it will still trash “incorrect” items but it will block after the first stack instead of just expanding forever.

Rseding91 wrote: Thu Dec 11, 2025 11:04 pm Press F4 and check the "show-entity-control-behaviors" option. You'll see that one of the mods you're using is creating the behavior on the assembler. Specifically at least "perel" https://mods.factorio.com/mod/perel is forcing it to exist in every single entity built that supports control behaviors.

Note this is *absolutely terrible* for performance since it means every single belt in your save that you built after adding it is having its transport lines force split making the entire transport belt system slower.

Based off the save file, it shows you added that mod fairly recently. If you remove it, any newly build factories and belts won't be force-creating their control behaviors.

Wow, thank you very much for digging into it. The time of adding that mod fits perfectly to when the issue started to appear. If the performance impact is huge you basically saved my already struggling-for-UPS pY run.

Is there a way to somehow manually reset the "|"-control behavior params to none on those already built entities that had the mod "mark" them?

A tedious solution but not using console commands is to copy paste settings from a belt that has no behavior, basically shift+right click one of belts without "I" and then shift+left click over a belt with "I". Drag paste may help with this.

boskid wrote: Thu Dec 11, 2025 11:43 pm A tedious solution but not using console commands is to copy paste settings from a belt that has no behavior, basically shift+right click one of belts without "I" and then shift+left click over a belt with "I". Drag paste may help with this.

That seem to only create a "|" for the "empty" belt...

That is not part of game logic, it must be some mod listening for copy settings event and interfering. Did you remove the mod that Rseding pointed at?

boskid wrote: Thu Dec 11, 2025 11:53 pm That is not part of game logic, it must be some mod listening for copy settings event and interfering. Did you remove the mod that Rseding pointed at?

yes, all newly built entities don't have the "|" anymore (i've rebuilt those)



upd nevermind, i've found a second mod that does it, it works now, ty very much

It looks like copy settings is messed up by https://mods.factorio.com/mod/AdditionalPasteSettings creating a behavior on the source entity when copying settings. With this mod removed the copy-settings approach seems to be working as expected.