Random Factor

[Ranakastrasz]

I am planning to add a random factor to one of my mods. presumably based on the math.rand method.
I am uncertain how to manage the seed, whether a seed carries over between game saves, or in multiplayer. I also am trying to access the map's seed to use for generation, and it isn't working

for key,value in pairs(game.map_settings) do globalPrint(value) end

This results in an error, as does several other permutations.

[daniel34]

See here: Multiplayer and random number generation [Modding interface requests]

Basically, they overrode math.random to use the map.random they wrote, so that any call to math.random gives the same results for each client.

[Ranakastrasz]

Alright. What about the seed? Do I have to initilize it to get different results per game? Do I have to do it on game-load? If i do it on game load, will it sync over all players?

[Oxyd]

Alright. What about the seed? Do I have to initilize it to get different results per game? Do I have to do it on game-load? If i do it on game load, will it sync over all players?

You can't seed the generator from Lua. There is one random number generator for each map – used both by the game itself and by Lua's math.random. This generator is seeded when the map is generated – there's an input box on the map generator screen when starting a new game that lets you specify the random seed.

[Ranakastrasz]

Alright, so just call math.rand() and I get a random number, which doesn't desync, and is different for each game assuming you use a different seed?

[Oxyd]

Alright, so just call math.rand() and I get a random number, which doesn't desync, and is different for each game assuming you use a different seed?

Yes.

[SirRichie]

Can someone please verify that math.random() *really* works in MP?

My own experience is different. I know that the devs aimed at making it MP-safe, but when I coded my mod, I had to ship it with a variant of a lua implementation of Mersenne-Twister, which I initialize with the map_generation seed.

[Klonan]

Can someone please verify that math.random() *really* works in MP?

My own experience is different. I know that the devs aimed at making it MP-safe, but when I coded my mod, I had to ship it with a variant of a lua implementation of Mersenne-Twister, which I initialize with the map_generation seed.

My mod Wind turbine relies heavily on making random calls, which affects large amounts of the turbines, and never had a desync issue. If a math.random call is made, on the same tick, in the same map seed, the value should be the same

[SirRichie]

Can someone please verify that math.random() *really* works in MP?

My own experience is different. I know that the devs aimed at making it MP-safe, but when I coded my mod, I had to ship it with a variant of a lua implementation of Mersenne-Twister, which I initialize with the map_generation seed.

My mod Wind turbine relies heavily on making random calls, which affects large amounts of the turbines, and never had a desync issue. If a math.random call is made, on the same tick, in the same map seed, the value should be the same

Thank you a lot, I will definitely try that out, might simplify things.
Does anyone know if this also works across different platforms?

[daniel34]

...

Thank you a lot, I will definitely try that out, might simplify things.
Does anyone know if this also works across different platforms?

Yes it does, I'd consider any error/desync you get as a result of running the same code on different platforms as a bug.

Unit tests are aimed at testing non-trivial internal functions. They work with mocked objects and the result is that they give us a certain assurance that the specific part of the code functions correctly on itself. They are really fast to run, this is because they don't load any graphics nor any prototypes (data from the base mod). Examples of unit tests are testing synchronization mechanisms in the multiplayer code, tests in the crafting queue logic or even testing that floating point operations give the same result on all our architectures.

RNGs usually don't use floating point operations but integer operations (IIRC), but the above statement should still be true.

EDIT: I was actually searching for this quote, which I found now:

This week a lot of our energy has been spent on the determinism. Kovarex started writing integration tests that check the determinism correctness. This has revealed an error in our map generation code which was a reason why in the past week we had to play on restricted map (infinite map was desyncing all the time). For the curious ones the error was in ambiguous sort comparator (c++ stl sort across different compilers obviously behaves differently for elements that are equal to each other). Originally we were quite afraid of Floating point operations discrepancies across different computers. But surprisingly, this hasn't been a big problem so far (knocking on the table). We got away with implementing our own trigonometric functions.