What is the meaning of math.randomseed(os.mtime()) in startup.lua

[Lopaskurwa]

What this function do? Whats the point of having it?

 

[Night Wolf]

All random functions rely on a pseudo-random generator that uses a seed to generate the "randomness".
What this function does is transforming the seed to the time in miliseconds (current time).

However, there are debates if this is indeed a good seed since the number changes in the same proportion everyday and therefore are "less random".

A good seed people usually use is os.clock() that relies on the amount of clocks of your CPU and are usually varying a lot between each function call. Some even even use both combined in a function.

 

[Lopaskurwa]

All random functions rely on a pseudo-random generator that uses a seed to generate the "randomness".
What this function does is transforming the seed to the time in miliseconds (current time).

However, there are debates if this is indeed a good seed since the number changes in the same proportion everyday and therefore are "less random".

A good seed people usually use is os.clock() that relies on the amount of clocks of your CPU and are usually varying a lot between each function call. Some even even use both combined in a function.

Could it be the reason why sometimes random functions doesnt really feel random?

 

[Night Wolf]

Could it be the reason why sometimes random functions doesnt really feel random?

they won't ever feel truly random because they aren't. Computers can't produce randomness.
Of course setting up a good seed from the start is the best workaround to make your pseudo-random functions behave as "random" as computers can possibly do.

There's an entire business around selling "randomness", they use it using nature data from radioactive elements, quantum spins and geo/weather information.

 

[Lopaskurwa]

So what would you suggest changing it to?

 

[Night Wolf]

math.randomseed(os.clock()) or retain the math.randomseed(os.mtime())
both should be ok

 

[Lopaskurwa]

math.randomseed(os.clock()) or retain the math.randomseed(os.mtime())
both should be ok

Thank you

 

[Iryont]

What this function do? Whats the point of having it?

You can read about it here:

Monster:onDropLoot / getLootRandom() not working correctly · Issue #2632 · otland/forgottenserver

Before creating an issue, please ensure: [✔] This is a bug in the software that resides in this repository, and not a support matter (use https://otland.net/forums/support.16/ for support) [✔ ] Thi...

github.com

I was the one to suggest the fix based on that report regarding loot distribution:

Monster:onDropLoot / getLootRandom() not working correctly · Issue #2632 · otland/forgottenserver

Before creating an issue, please ensure: [✔] This is a bug in the software that resides in this repository, and not a support matter (use https://otland.net/forums/support.16/ for support) [✔ ] Thi...

github.com

Anyway, such number generator does not have to be random at all. In fact, it's all predictable if you know the algorithm and the seed, however, what matters in this case is the distribution of the generated numbers. As long as the are distributed in a way that random numbers would be then it's good and nothing more is needed. There isn't any place a true randomness would ever be needed, period.

That being said, considering you have math.randomseed(os.mtime()) in startup.lua I can only imagine you are still using the code before my proposed fix which was merged here:

Fix getLootRandom, fix use of randomseed by thatmichaelguy · Pull Request #2637 · otland/forgottenserver

resolves #2632 Solution provided by iryont Removed randomseed from startup.lua Removed randomseed from getLootRandom function of global.lua Added randomseed to line 1 of global.lua

github.com

That's probably the reason you don't "feel randomness".

 

[Lopaskurwa]

You can read about it here:

Monster:onDropLoot / getLootRandom() not working correctly · Issue #2632 · otland/forgottenserver

Before creating an issue, please ensure: [✔] This is a bug in the software that resides in this repository, and not a support matter (use https://otland.net/forums/support.16/ for support) [✔ ] Thi...

github.com

I was the one to suggest the fix based on that report regarding loot distribution:

Monster:onDropLoot / getLootRandom() not working correctly · Issue #2632 · otland/forgottenserver

Before creating an issue, please ensure: [✔] This is a bug in the software that resides in this repository, and not a support matter (use https://otland.net/forums/support.16/ for support) [✔ ] Thi...

github.com

Anyway, such number generator does not have to be random at all. In fact, it's all predictable if you know the algorithm and the seed, however, what matters in this case is the distribution of the generated numbers. As long as the are distributed in a way that random numbers would be then it's good and nothing more is needed. There isn't any place a true randomness would ever be needed, period.

That being said, considering you have math.randomseed(os.mtime()) in startup.lua I can only imagine you are still using the code before my proposed fix which was merged here:

Fix getLootRandom, fix use of randomseed by thatmichaelguy · Pull Request #2637 · otland/forgottenserver

resolves #2632 Solution provided by iryont Removed randomseed from startup.lua Removed randomseed from getLootRandom function of global.lua Added randomseed to line 1 of global.lua

github.com

That's probably the reason you don't "feel randomness".

So what you suggest removing math.randomseed(os.mtime()) from startup and adding it on global.lua in line 1?

 

[Kaspar]

So what you suggest removing math.randomseed(os.mtime()) from startup and adding it on global.lua in line 1?

https://github.com/otland/forgottenserver/pull/2637/commits/5480fdf89e9c2bc2282a4444462fb9ec7911397a

 

[kay]

However, there are debates if this is indeed a good seed since the number changes in the same proportion everyday and therefore are "less random".

It doesn't matter. Even if one were to guess the exact time of seeding (which is already unlikely), they have no way to know how many times the server calls for the next number in the sequence and for what purpose, therefore realistically no player will ever be able to predict anything. And as long as the sequence looks random, it is all good. You may need a safer pseudorandomness in cryptography and such, but not in a freaking game. Tibia used standard rand() seeded with time() upon the start, there is zero reason for an OTS to do anything more than that.

they won't ever feel truly random because they aren't. Computers can't produce randomness.

Again, it doesn't matter. They don't need to be truly random at all to feel like random. It's all about adequate distribution only.

 

[Kaspar]

True randomness is a really interesting topic and deserves its own Discussion thread. Although, as mentioned in above posts, true randomness is not truly applicable outside the scope of quantum mechanics.

To not go too much off-topic (OP's question has already been answered):
While predicting loot from monsters doesn't really matter since monsters are killed everywhere in the world, and you will get the same average loot while hunting regardless... I still want to live in the illusion that I have a random chance to loot something nice from a monster. I don't care if the randomness is truly random or not, because my brain cannot comprehend such a fact in runtime (hunt time) either way. If there is no illusion of randomness (i.e pseudo-randomness) and I know beforehand that I will only loot the rare drop I'm after, on the 550th Demon I kill, and not on the previous 549 ones... I won't be excited until the 550th Demon.

Reading about the previous loot distribution issue in TFS brings my thoughts on how raids work in Tibia.
Predicting when a "random" rare boss spawn, does actually matter; unlike the prediction of loot. It gives the player an advantage over others. So whereas the loot system in Tibia is an example of a good implementation of randomness, the raid (& rare boss) system is an example of a bad implementation of randomness. It's not really always about the algorithm per say, or being as close to true randomness as possible. As long as you can simulate randomness, then it's often enough. With exceptions of course...

 

[kay]

While predicting loot from monsters doesn't really matter since monsters are killed everywhere in the world, and you will get the same average loot while hunting regardless... I still want to live in the illusion that I have a random chance to loot something nice from a monster. I don't care if the randomness is truly random or not, because my brain cannot comprehend such a fact in runtime (hunt time) either way. If there is no illusion of randomness (i.e pseudo-randomness) and I know beforehand that I will only loot the rare drop I'm after, on the 550th Demon I kill, and not on the previous 549 ones... I won't be excited until the 550th Demon.

It doesn't matter, but only because you will never be able to predict the loot of any nth demon, regardless of it being "only" pseudorandom, lol.

Reading about the previous loot distribution issue in TFS brings my thoughts on how raids work in Tibia.
Predicting when a "random" rare boss spawn, does actually matter; unlike the prediction of loot. It gives the player an advantage over others. So whereas the loot system in Tibia is an example of a good implementation of randomness, the raid (& rare boss) system is an example of a bad implementation of randomness. It's not really always about the algorithm per say, or being as close to true randomness as possible. As long as you can simulate randomness, then it's often enough. With exceptions of course...

Not an issue either. Tibia's randomness is all safe to an acceptable degree for a game. Again, this topic is significant in cryptography and possibly other areas, but irrelevant for OTS. The issue that you had in the TFS loot generation had literally nothing to do with the weakness of pseudorandomness. It was solely within the fact, that some smart TFS developer apparently thought that it would be a great idea to re-seed before each use of random(), and then another smart TFS developer pulled it into the main repo. It for sure wasn't like that originally. Anyway, when the loot of a monster is generated, it calls random() for each item in the list and then compares against its chance. Since they kept seeding it with time in miliseconds, whenever all the loot of one monster was drawn within the span of 1 milisecond, the drawn number was the same for each item. Hence, whenever that number was low enough, all the rare items were spawned together. With the correct use of seeding, no such issues would occur. Seeding should be done once because it is only needed to ensure that the whole sequence is going to be different each time you start the program, as Iryont has already explained to you. Those functions are deterministic, but it does NOT make the overall result predictable for a player at any point, and therefore you don't need anything other than the standard rand() function seeded with time upon the server's start, period.