[1.1.61] Integer overflow constant combinator

[dasiro]

When entering a ridiculous high number like 999999999999 the constant combinator changes the value to -2147483648 so instead of ridiculously HIGH it becomes ridiculously LOW.

Can the input validation be extended to check for high/low values and put them automatically to the upper/lower value?

[Loewchen]

viewtopic.php?p=280128#p280128

[robot256]

As for the GUI problem, It can even be seen as a feature. When pasting large numbers most of the times it's useful to cut the extra bits instead of clamping to the largest number.

I get the underlying behavior, but this statement doesn't make sense to me at all. Why would you type a super big number in if you don't want a super big number? The user enters numbers in decimal and the game truncates in binary, so it's not easy for humans to predict what they get out. Aside from intentionally casting an unsigned int to a signed int, is there any case the user would use this feature instead of a separate calculator to get what they want?

[Tertius]

It's difficult to explain, but for someone with a background in computer programming, especially someone who did C and assembler, binary truncating a big number to signed 32-bit (it's simply <value> mod 2^32 interpreted as two's complement) makes absolutely sense. Especially if the system that actually performs the operation is based on 32-bit integer. It's the same technical and computer-orientated spirit the whole game is breathing and living.

Rounding down would be wrong from a technical point of view. Truncating the number in the GUI is the same "weird" result as if you add 2 huge 32-bit integer numbers within the combinators if the result will overflow 32-bit, so it's consistent.

[robot256]

It's difficult to explain, but for someone with a background in computer programming, especially someone who did C and assembler, binary truncating a big number to signed 32-bit (it's simply <value> mod 2^32 interpreted as two's complement) makes absolutely sense. Especially if the system that actually performs the operation is based on 32-bit integer. It's the same technical and computer-orientated spirit the whole game is breathing and living.

Rounding down would be wrong from a technical point of view. Truncating the number in the GUI is the same "weird" result as if you add 2 huge 32-bit integer numbers within the combinators if the result will overflow 32-bit, so it's consistent.

I'm quite familiar with how to make it behave the way it does mathematically. It would make perfect sense if we were talking about a programmer's calculator set to 32-bit mode. But we are not--this is a text input field for normal gamers trying to input a number. There is no visual indicator of when or why the game might store a number other than exactly what you typed. This is the reason for multiple bug reports on the topic.

If anything, the "technically correct" behavior should be to give the user an error message stating the valid range of inputs. The mod settings GUI already does this for arbitrary specified number ranges. Rounding the number to the largest available is an implicit way of giving the user this information.

Please let me know if you have a different use case, but the only times I actually manipulate numbers that big is as part of a more complex formula. Since equations are not allowed in the Factorio constant dialog box, I must use an external calculator to compute them. At that point, I might as well perform the truncation in my calculator. I have no need for Factorio to do it for me.

On the other hand, there are reasons to want BIGINT in a circuit that don't involve a more complex equation. Right now, I only have powers of 2 memorized up to 17, so to get "2^31-1" I have to use an external calculator. Having the dialog round 999999999999 to 2,147,483,647 would save me from needing a calculator in this case, and not change the prior case, and give users an indication when a value is too big. Seems like a win-win-win.