Looking at the save file it seems to be the same type of corruption as in https://forums.factorio.com/127574 - one of the entities was saved without data of its energy source, making this save file unloadable because game was confused about meaning of various bytes on read (misinterpreting lack of ...

Without a save file this bug report is incomplete.

Heavy mode is the ultimate tool for finding desyncs with game bugs or scripting bugs, you may notice it is uplayably slow because it saves the game, loads a game, and then does update of the original game instance and second game instance doing more saves in between to rule out all possible places ...

I wont be discussing this if you cannot state your problem more accurately than saying "it does not work".

OP's first post shows usage of "Everything" signal which never supported having a second special signal.

Tested right now in 2.0.72 the exact setup from the provided picture, it works ...

LocalisedString's recursion limit being 20 levels is documented since 1.1.22. Please consider not splicing localised strings and instead using log() for whatever debugging purpose you need it.

This is most likely related to 131153. Since that issue was fixed in 2.0.70 while you are trying to run 2.0.69, i would suggest trying to install a latest version (2.0.72 at the moment of writing).

Only problematic thing here may be that latest demo is 2.0.69.

Straight off of the wiki, I need something to do exactly this operation, but this doesnt exist anymore for whatever reason. I did manage to find a weird workaround though.


Icons were updated since creation of that image.

"each" signal now looks like this (2.0.72):
12-16-2025, 09-38-25.png

It is solvable if you stop reading ingredients from all assemblers.

This is a feature request since you want R/G checkboxes from decider. I am not seeing any bugs in this given current feature set.

-- edit:

To be even more precise, your proposed solution would not help with the setup you have in the save file since all 6 assemblers are reading ingredients and all ...

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.

I am curious, why exactly do you need to remove a control behavior? There should be no reason to create a control behavior in the first place if you are not trying to add a wire or to set a setting. There is a significant difference between "get_control_behavior" and "get_or_create_control_behavior ...

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?

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.

I would prefer to not have this because it would have huge sideeffects: removing all circuit wires (if there are any), clearing all settings to defaults and in some cases it may even remove items (assembler's dump inventory is part of assembler behavior). That being said, there are at least 2 cases ...

This does not feel realistic. There are basically 2 approaches, lets call them "automatic" and "manual" and both of them are a no-no.

In the "automatic" approach, you would select a recipe and a machine would accept any ingredients that match the specified list of ingredients. This approach would ...

Is there a save file i could take a look at?

This looks like an issue with trigger effect descriptions logic because it sees big biter being an entity spawned that deals 30 physical damage and wants to show this damage in the tooltip, however this is not a damage applied when spawning a biter.

I will mark this bug report as fixed for 2.1 due to unrelated changes that make this issue not show.

I can reproduce this issue in 2.0.72 however it looks like it is already fixed for 2.1 due to changes made for 131555. Since this report is different i will just mark this as fixed for 2.1.

OK, i added something for 2.1.