Factorio Forums

when adding the same Signal to a constant combinator twice, it does not longer over or underflow as of the .44 patch.
The signals of 2 different combinators still add towards and overflow.

Expected behavaior: The 2 signals in the same combinator add up using overflow

This actually did break my game circuitry logic. It's not a theoretical case. I use the overflow to set filters a lot.


Top Left: single combinator with 2 groups.
Bottom right: 2 combinators with each 1 group.

Thanks for the report however this is not a bug.

Rseding91 wrote: Fri Apr 11, 2025 10:49 pm Thanks for the report however this is not a bug.

Can you explain this? This was working differently until this very patch. And that result is not expected. Why was it changed to behave unexpected? It does not seem consistant at all that values from different combinators behave not the same, as the signals from a single combinator.

If this is intended behavior and not a bug... I think it should be at least announced in the changelog.
Cuz this just broke a whole bunch of stuff

We have at no point defined how logistic sections when combined work, and overflow/wrap around is not in any way intuitive compared to clamping at the extremes.

As part of a fix for adding together logistic section values also including multipliers, the logic was unified and changed to clamp explicitly when converting the numbers from the separate values into the final summed value.

This is a classic case of https://www.laws-of-software.com/laws/hyrum/ and I have no plans to change the behavior to wrapping. Talking with some of the other developers they agreed.

Rseding91 wrote: Sat Apr 12, 2025 1:33 am We have at no point defined how logistic sections when combined work, and overflow/wrap around is not in any way intuitive compared to clamping at the extremes.

Sure you haven't defined how it works, but considering how they are combined in a rather similar manner to multiple combinators on the same circuit network, it would be expected for them to operate the same way. Especially since overflow is how it works on the circuit network, and is intuitive to anybody getting to the point of overflowing the signals. All you've done now is create a disconnect in how the systems operate, making it even harder for new players to understand why it works one way in one case and another way in a second case.

Rseding91 wrote: Sat Apr 12, 2025 1:33 am As part of a fix for adding together logistic section values also including multipliers, the logic was unified and changed to clamp explicitly when converting the numbers from the separate values into the final summed value.

I'd argue that the 'fix' is rather counterintuitive, considering how circuit signals work everywhere else in the game. Talking with some people on discord, we agree that it's weird that implicit signal addition now behaves differently from a combinator doing addition. Why clamp it here and not elsewhere? This isn't me asking for it to be clamped elsewhere, I love the simple logic I can do with overflows. Please don't 'fix' that as well.

At the very least, this should have been mentioned in the changelog, like @GlassBricks said, in more simple terms than 'combining logistic filters'.

The root of this seems to be that constant combinator "signals" are actually several logistic filters in a trench coat pretending to be circuit network values. I've forwarded this to Kovarex to see if he'd like to veto this decision, and or propose an alternate method for how this all should work.

+1 for "reverting" to old behavior, at least for the circuit network case. I (and I imagine everyone else) are perfectly okay with the clamping for things like sums of logistics groups in requester chests or when reading from a miner set to "read patch", as in those cases it just makes more sense. However, I am quite attached to overflow behaviors as far as combinators go, and in that case clamping is actually less consistent with how other adjacent systems work (combinator addition, implicit wire summation). I think the best way forward would be to delineate between the two situations, and use the overflow/underflow logic specifically for combinators/wires and clamping for everything else, which (I think) would make everyone happy.

Redruin wrote: Sat Apr 12, 2025 6:37 pm +1 for "reverting" to old behavior, at least for the circuit network case. I (and I imagine everyone else) are perfectly okay with the clamping for things like sums of logistics groups in requester chests or when reading from a miner set to "read patch", as in those cases it just makes more sense. However, I am quite attached to overflow behaviors as far as combinators go, and in that case clamping is actually less consistent with how other adjacent systems work (combinator addition, implicit wire summation). I think the best way forward would be to delineate between the two situations, and use the overflow/underflow logic specifically for combinators/wires and clamping for everything else, which (I think) would make everyone happy.

+1

+1. The reason to saturate is when you have a very clear indication that the user specifically wants a positive (or negative) number, and the sign is more important to them than the value. In logistic requester chests, that is probably true, but in constant combinators it is ambiguous.

Odds are extremely good that if you get anywhere close to counting 2147483648 of something, you don't actually expect that many of the thing to show up and are playing intentional games with the math. Even typing "99999999" won't overflow it.

+1 to reverting. If the circuit system operates using a wraparound system when using separate combinators it is then an ugly wart that a single combinator with multiple groups does not behave the same. (-1 To making both cases clamp because this allows many combinator builds with low tick latency.)

I will raise this topic on one of the meetings so for now i will keep this in assigned and will let you know what were the decisions.

+1

I get that how it works internally is different from everything else, but everything else in the game revolving around implicit signal combination over/underflows. It doesn't make sense from a player's perspective, even if it makes sense from a developer's perspective.

boskid wrote: Sun Apr 13, 2025 3:36 pm I will raise this topic on one of the meetings so for now i will keep this in assigned and will let you know what were the decisions.

Appreaciated!

Ok, decision was made and constant combinators will wrap-around total values accumulated from multiple sections. Issue is now fixed for 2.0.45.