[0.16.51] [Solved] Desync with random generator

[ZlovreD]

Note, although the global table has not been setup if a mod does populate the table with some data it will be overwritten by any loaded data.

So...that bit should behave pretty much the same as setting default values via "global.key = global.key or value" in on_init. And as such it might not actually be invalid. If it was written like that intentionally (ok, not very likely :p) i might actually consider it clever api usage..... hm... think think thing.... but... it'll break when a new version introduces new values. *scratches head*. But then why are the values even persisted...?!

Interesting, that means it won't even get reset by loading the file (which is what I thought would happen), so that should be completely fine. The more you know

The problem with doing it outside of an event is this

edit:
global.a = 1

save and edit:
global.a = 2

load:
global.a == 1

This is because during init "global" is saved to the map and during load the data from "global" that is stored in the savefile overwrites whatever you have for global.
on_init and and on_configuration_changed are the best places to populate and edit your "global"

But every time when on_load fired - you get actual data.
In MP when someone is connecting to the game, game is halting to save/share/load actual data with all current changes in global, isn't it?
In SP, you continue your progress from last save.
In all cases you getting actual globals.

[eradicator]

Hmm I'm not sure but what does this code really do?

Yep, it is convertion of reference address into a number.
And is works perfectly in SP. :roll:

Memory addresses are not deterministic. Don't use them for anything. You're not even allowed to print them. Just pretend they don't exist.
Ofc it "works in SP" because SP can't desync, same as MP with only one player can't desync. :p

[Rseding91]

One simple solution: delete your entire random generator class and just call math.random(...) from your functions and it will work perfectly.

[ZlovreD]

One simple solution: delete your entire random generator class and just call math.random(...) from your functions and it will work perfectly.

I had thinked about it in some moment. But i fixed mine because i need more than 10 different random numbers in one tick and default math.random can't guarantee that.
Just moved "unsecure" part into on_init handler.

As alternative - i thought about creating hash string from one random number and then split/convert it on to different numbers.

[orzelek]

One simple solution: delete your entire random generator class and just call math.random(...) from your functions and it will work perfectly.

I had thinked about it in some moment. But i fixed mine because i need more than 10 different random numbers in one tick and default math.random can't guarantee that.
Just moved "unsecure" part into on_init handler.

As alternative - i thought about creating hash string from one random number and then split/convert it on to different numbers.

What do you mean by math.random not being able to provide many different random numbers in same tick?
Every number coming from math.random is... random in the same way. Separately seeded generator will have same quality of random numbers since I think underlying implementation is the same.

Only reason to use separately seeded generator is if you need to have same random sequence depending on some predefined factor - for example using rng in specific location in game and you know you will need to repeat the sequence later on for some reason.

[Rseding91]

One simple solution: delete your entire random generator class and just call math.random(...) from your functions and it will work perfectly.

I had thinked about it in some moment. But i fixed mine because i need more than 10 different random numbers in one tick and default math.random can't guarantee that.

Yes it can. That works perfectly.