Really Wierd Bug - Schedule and getRandom inaccuracy

[Rykuta]

Except as I explained above, that's not how you should be using it at all. You're not meant to create a new one each time it's used in scope, which is what your code implies unless it is global scope and seeing as this is C# I doubt it very much.
Are you asking me to place it inside the class as an instance field? Because I was always taught the more local something is, the better. The code in question is being used during the update function of a game. AKA, constantly being used, but only in a single method; so I determined putting it in the class would be ineffecient. Although I concede that what you're suggesting would be otherwise useful, if I intended to use random number generators elsewhere in the process.
You obviously don't know this stuff correctly because you came in here assuming that PRNGs were seeded each cycle and posted an incorrect snippet of code that will give beginners the wrong idea.
I assumed torquescript modified the seed to keep them fully random, instead of pseudo random. If that's wrong, just say so, and I will remove the snippit.
This is how humans learn.
I am not human, nor will I ever be.

No need to get snippy, as we seem to be getting offtopic in a heated debate about the proper use of random number generation. Let's head back to schedules and the original point of the topic.
I made the assumption that, (as torque seemed to be a bizzare hybrid of programming), torque would have a less pseudo random number generator as other actual languages. As such, I assumed that was why time was causing problems.  The statement: "Torque does not do this." would have sufficed as an answer, and yet you have provided no input on why this would happen yourself, which leads me to believe you are here for the purpose of telling people how random numbers work, and how seeds work, instead of why schedules would be inaccurate when using random numbers. But I digress.

How about instead of arguing, you get on topic? That's a better idea.

This ^ ^

[Ad Bot]

[Ipquarx]

How about instead of arguing, you get on topic? That's a better idea.

[Destiny/Zack0Wack0]

The OP has already been answered in earlier posts and a discussion about RNGs is completely related to the topic. Look bud, I said "Torque does not do this" and then you posted an incorrect snippet to which I explained thoroughly and politely why it was incorrect. I don't understand how you can call Torque a hybrid language, it sticks to its data orientated OO roots pretty thoroughly. I am absolutely here to tell people how RNGs work, because a) I explained why Torque's builtin RNG would not regress and hence the OP's assumption that the RNG was to blame was wrong b) you posted a statement to which I kindly directed an explanation of why it was incorrect and again why the RNG was irrelevant to the OP's bug.

1) The "more local something the better" is a bad attitude in _most_ non-concurrent use cases, as that takes up more memory and cycles. Like I mentioned before, using it in the update function of the game is bad because it will (depending on the language) need to reallocate the random number generator each time the function is called, reseed it (which can be expensive depending on the PRNG type) and it won't be random because the same numbers will be generated each time.
2) TorqueScript does not "modify the seed to keep fully random, instead of psuedo random". Every random number generator is psuedo-random, calculating actual entropy is impossible and seeds are only used once. You keep complaining about me explaining how PRNGs work when you apparently already know -- even though you say ridiculous things like the above and are only now listening to why instantiating a RNG in a game update function is bad even though I've detailed this 2 times before.
3) hhehea u so funy

[Rykuta]

1) The "more local something the better" is a bad attitude in _most_ non-concurrent use cases, as that takes up more memory and cycles. Like I mentioned before, using it in the update function of the game is bad because it will (depending on the language) need to reallocate the random number generator each time the function is called, reseed it (which can be expensive depending on the PRNG type) and it won't be random because the same numbers will be generated each time.
Your word against my professors. Although I agree with yours, they do (allegedly) have experience in the matters. I'll have to take up the subject with them.
2) TorqueScript does not "modify the seed to keep fully random, instead of psuedo random". Every random number generator is psuedo-random, calculating actual entropy is impossible and seeds are only used once. You keep complaining about me explaining how PRNGs work when you apparently already know -- even though you say ridiculous things like the above and are only now listening to why instantiating a RNG in a game update function is bad even though I've detailed this 2 times before.
Detail it with a single line reply so I can clearly read it in plain english next time, I obviously missed it as it was nuzzled inbetween the "You don't know how to random number" comments.
3) hhehea u so funy
I try, if you laughed, my work here is done. ^.=.^

Thanks for the input, Sorry my output was condescending. For future preference, please refrain from depthy explanations of things (Or at least when talking to me, as I tend to miss important details amoungst the filler), lists are your friends; hugs all around.