Factorio Forums

I'm writing a JSON-schema compliant description of the Blueprint string format. To be thorough, I'm testing the numeric limits of each attribute to determine their underlying datatype (or, at least their acceptable range of values). Both `entity_number` and `version` (when set outside their allowed range) describe their limits as a unsigned 64-bit integer (0 -> 2^64-1), but you can actually set values for both that exceed the upper bound:
Despite the above values being outside of the allowed range, the following blueprint will import into Factorio just fine:

Copy blueprint

It seems like these numbers are getting converted to a floating point number at some step, making them suffer from floating point precision error. If I set the value to 2^65, the value does error, but the returned value in the error varies from the input value by about a thousand:


The output string also seems to display the interpreted result with decimal values, further corroborating this interpretation. I suspect this coercion might be caused by the blueprint string entering the Lua side of things and getting coerced to a `number`, which is likely a C double.

If this is a bug, it's impact is non-existent; no player is ever going to have a blueprint with 2^53 entities in it, and the Factorio major version would have to be absurdly high for version to suffer from precision loss. However, this very well seems like it could be a simple oversight where an input value is being coerced to the wrong datatype accidentally, making the tooltip which describes it's valid range strictly incorrect at the very least.

Thanks for the report. The way we load the blueprint string fields they first get stored into an internal data structure we call a PropertyTree. That data structure in 1.1. only has 1 format for storing numbers - double. So as you see it will always run into those issues if values are outside the representable range for a double.

Since as you mentioned nobody is ever going to reach the actual limits in the field types that would fail to store in the double field we haven't spent any time working on it.

In 2.0 we added support for 64 bit integer types (signed and unsigned) so the logic that converts the string version to the PropertyTree could theoretically convert to the integer types with some extra logic. Right now I don't believe it does. I'll stick this on the backlog and if someone feels like poking at it they can but it's not a priority since as you said "it's impact is non-existent"

Rseding91 wrote: Sat Sep 23, 2023 2:29 pm In 2.0 we added support for 64 bit integer types (signed and unsigned) so the logic that converts the string version to the PropertyTree could theoretically convert to the integer types with some extra logic.

Does this mean a Lua runtime upgrade to 5.3 or later in 2.0 to be able to interact with the full range of those integers?

mwls wrote: Sat Sep 23, 2023 7:38 pm

Rseding91 wrote: Sat Sep 23, 2023 2:29 pm In 2.0 we added support for 64 bit integer types (signed and unsigned) so the logic that converts the string version to the PropertyTree could theoretically convert to the integer types with some extra logic.

Does this mean a Lua runtime upgrade to 5.3 or later in 2.0 to be able to interact with the full range of those integers?

Theoretically, but there are no plans to ever update the version of lua we use.