Version 1.1.95

[FactorioBot]

Changes

• Technology researched message does not play chat notification sound.

Bugfixes

• Fixed that the prototype explorer and CustomInputEvent::selected_prototype did not work on crafting machine fluid slots.
• Fixed LuaEntity::disconnect_neighbour called on electric pole would disconnect left side of power switch when requested to disconnect right side. (109309)
• Fixed that cloning rails in the map editor could lead to corrupt saves in some instances. (109436)
• Fixed offset of circuit connector sprites for inserters

Scripting

• Added PrintSettings::sound_path, volume_modifier and game_state.
• Replaced PrintSettings::skip_if_redundant with PrintSettings::skip. Added defines.print_skip.

Use the automatic updater if you can (check experimental updates in other settings) or download full installation at http://www.factorio.com/download/experimental.

[Rseding91]

This experimental version also contains cross-platform checks for x86 vs arm floating point conversions. x86 and arm do floating point conversions differently and if we don't handle it correctly on the C++ side it results in different values which results in multiplayer desyncs.

[Sanqui]

If you ran into this issue when updating to 1.1.95 please try again, I have released update packages which work around this problem.

[Kane]

Thank you

[Stringweasel]

This experimental version also contains cross-platform checks for x86 vs arm floating point conversions. x86 and arm do floating point conversions differently and if we don't handle it correctly on the C++ side it results in different values which results in multiplayer desyncs.

As a programmer myself I'm curious what exactly you mean here. I understand the part that different platforms do floating point operations differently, and they might have different results. And because Factorio is deterministic it's very important that all calculations always result in exactly the same answer.

But isn't this something that should be checked during development? Or in CI/CD pipelines? My first guess is that there's simply too many things to check?

And what type of checks was added? For example, the Factorio instance on my PC will do a floating point calculation, but to what would the result be compared (checked) to verify it's consistent?

An explanation would be really nice to hear, but of course not expected. Just a curiosity

[AugustoResende]

If you play in a Linux machine (x86) and your friend is playing in a M1 Mac Os, without this fix in some cases could occur a multiplayer desync because of different fload calculations

[Stringweasel]

If you play in a Linux machine (x86) and your friend is playing in a M1 Mac Os, without this fix in some cases could occur a multiplayer desync because of different fload calculations

I do understand the reason why they are added. I'm curious what they added.

[Genhis]

As a programmer myself I'm curious what exactly you mean here. I understand the part that different platforms do floating point operations differently, and they might have different results. And because Factorio is deterministic it's very important that all calculations always result in exactly the same answer.

But isn't this something that should be checked during development? Or in CI/CD pipelines? My first guess is that there's simply too many things to check?

And what type of checks was added? For example, the Factorio instance on my PC will do a floating point calculation, but to what would the result be compared (checked) to verify it's consistent?

Floating-point operations still have to do the same thing, otherwise cross-architecture multiplayer wouldn't work at all. This release added checks for conversion from floating-point numbers to integers. One of the issues we encountered was converting `double(-1)` into `uint32_t` - x86 lets it overflow and arm clamps it to 0 (105953). So it's mostly about checking if a floating-point value is in range of the target type and clamping it if it doesn't fit.

We do compare CRC values of our tests between x86 and arm, but sometimes we make incorrect assumptions or don't think about stuff modders would do. (Who would define a technology cost larger than ~18 quintillion, right? ) Also, not every line of code can be reliably tested. Runtime checks help us to fill in these gaps.

[Stringweasel]

As a programmer myself I'm curious what exactly you mean here. I understand the part that different platforms do floating point operations differently, and they might have different results. And because Factorio is deterministic it's very important that all calculations always result in exactly the same answer.

But isn't this something that should be checked during development? Or in CI/CD pipelines? My first guess is that there's simply too many things to check?

And what type of checks was added? For example, the Factorio instance on my PC will do a floating point calculation, but to what would the result be compared (checked) to verify it's consistent?

Floating-point operations still have to do the same thing, otherwise cross-architecture multiplayer wouldn't work at all. This release added checks for conversion from floating-point numbers to integers. One of the issues we encountered was converting `double(-1)` into `uint32_t` - x86 lets it overflow and arm clamps it to 0 (105953). So it's mostly about checking if a floating-point value is in range of the target type and clamping it if it doesn't fit.

We do compare CRC values of our tests between x86 and arm, but sometimes we make incorrect assumptions or don't think about stuff modders would do. (Who would define a technology cost larger than ~18 quintillion, right? ) Also, not every line of code can be reliably tested. Runtime checks help us to fill in these gaps.

Ah that makes sense, and answers my question. Thanks Genhis! And making the game so moddable, but still deterministic, is a big endeavor. I can imagine it will be really hard to find all possible issues during only development/testing