[1.1.91] Floating point precision loss with some Blueprint string fields

[Redruin]

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:

Code: Select all

test_dict = {
    "blueprint": {
        "item": "blueprint",
        "entities": [
            {
                "name": "wooden-chest",
                "position": {"x": 0.5, "y": 0.5},
                "entity_number": 2**64 + 1000
            }
        ],
        "version": 2**64 + 1000
    }
}

Despite the above values being outside of the allowed range, the following blueprint will import into Factorio just fine:

0eNptjF0KwjAQBq9S9lklrflRryIi1i4YMJuSpNUScnfXloIPviwfs8NkaJ8D9sFSglOVwSZ0PH7opgKkZJPFyI9zBro5/Cov7zuk7f2BcbZ6H9nyNHfefMVOMZ6WVdbOdKXBtRgY1wcptZFSmL0RR6UaXetyYXHEEJfSX6V8AHdANaM=

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:

Code: Select all

36893488147419103232        (2**65)
36893488147419104982.000000 (returned)

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.

[Rseding91]

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"

[mwls]

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?

[Rseding91]

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.