Really Wierd Bug - Schedule and getRandom inaccuracy

[chrisbot6]

Hi.

This might belong in standard help, but seeing as it's to do with code i'm putting it here.

Recently I got a reply to the add-on topic for the Renderman mod that the renderman appears less often if the server has been up for a long time. Now obviously this is the word of one person and I haven't tried to reproduce it yet, but i'm still concerned for the following reasons:
- I've seen things in the past about schedules becoming broken after the simtime reaches a certain value
- I once had a server up with Support_Prepper and noticed it would break towards the end
- The old firemod I made would break after it had been hosted for a certain amount of time

All of these mods use schedules, as well as countless others.

Obviously, I don't know what i'm talking about, (And quoting that line alone would probably be enough to bring the thread to a close) but if this stuff is happening then it might be safe to assume that this is a real bug in the game. Also, I was wondering if you guys knew anything about this.

Of course, it might just be the Renderman mod. (If anyone wants to see the code for it just DL the addon and look yourself) but I still want to see if anyone has seen anything about this simtime schedule theory people seem to have. I'm not nitpicking - i'm just trying to find out if this is real. Post your opinions below.

[Ad Bot]

[otto-san]

I've never heard anything about this. It wouldn't surprise me if it happened, though.

what's this have to do with getrandom?

[.Trinick]

You know you code in a stuffty language when someone reports a possible major issue with how the language works and you say, "eh, probably."

[otto-san]

You know you code in a stuffty language when someone reports a possible major issue with how the language works and you say, "eh, probably."

i really wish i had room in my signature

[Electrk]

How can getRandom be inaccurate?

[Rykuta]

From what I know about most Random classes / functions, they require a "seed" since they are technically not random.
If one wishes to make a number truly random, they use the current time for the seed, since time is constantly incrementing.
So, it is possible for that to malfunction when time reaches an invisible bounds or a value that the random number generator cannot interpret properly. Why this bound would exist at all, is beyond me.

Schedules probably also rely on the current time to estimate when they should execute, in advanced.

It is also possible that the data type used to store simTime reaches its max value (Since each type can only store a certian amount of values before being unable to hold anymore.) Most of the time when it reaches this value, it simply loops back around, (AKA becomes negitive)

[Port]

A random function cannot be "accurate". The entire point of such a method is to return completely inaccurate data. Also, I was running a server for around 19 days without taking it down a while back whilst running a schedule heavy add-on and noticed no failures at all.

Finally, if you generally aim to have your code support long server uptimes, avoid using getSimTime() at all costs. Instead, use $Sim::Time.

[Destiny/Zack0Wack0]

From what I know about most Random classes / functions, they require a "seed" since they are technically not random.
If one wishes to make a number truly random, they use the current time for the seed, since time is constantly incrementing.
So, it is possible for that to malfunction when time reaches an invisible bounds or a value that the random number generator cannot interpret properly. Why this bound would exist at all, is beyond me.

Schedules probably also rely on the current time to estimate when they should execute, in advanced.

It is also possible that the data type used to store simTime reaches its max value (Since each type can only store a certian amount of values before being unable to hold anymore.) Most of the time when it reaches this value, it simply loops back around, (AKA becomes negitive)

The seed is used only once, that's why it's called a "seed". So the current time when the RNG context is created is the seed that is used and then it never changes (generally).

[Treynolds416]

Finally, if you generally aim to have your code support long server uptimes, avoid using getSimTime() at all costs. Instead, use $Sim::Time.

Care to explain?

[Trinick!]

Care to explain?

getSimTime() returns a number in MS, which means eventually it will become very very large and Torque will truncate it. $Sim::Time returns a number in seconds with  a decimal value for getting milliseconds.

[Greek2me]

After about how long will getSimTime() stop working properly? That could explain some of my problems.

[Treynolds416]

getSimTime() returns a number in MS, which means eventually it will become very very large and Torque will truncate it. $Sim::Time returns a number in seconds with  a decimal value for getting milliseconds.

I guess that would make it another 10^3 longer, not sure how unlikely that would be however

[Port]

getSimTime() returns a number in MS, which means eventually it will become very very large and Torque will truncate it. $Sim::Time returns a number in seconds with  a decimal value for getting milliseconds.

Furthermore, when Blockland has been running for more than 999999 MS, you can't do math with the value from getSimTime.

[Xalos]

Furthermore, when Blockland has been running for more than 999999 MS, you can't do math with the value from getSimTime.

You can still use it for checking since the last time you got it, though.

if(vectorDist(getSimTime(), %somePrevSimTime) >= 3000)
    //Has been 3 seconds since %somePrevSimTime

[elm]

You can still use it for checking since the last time you got it, though.

if(vectorDist(getSimTime(), %somePrevSimTime) >= 3000)
    //Has been 3 seconds since %somePrevSimTime

Lol at using the vector distance function.