Could you please clarify what you mean by physics-based throttling?
Isn’t task.wait() more performant though? It can directly communicate with the task scheduler while wait() can’t (to my knowledge).
What do you mean by update rate?
As far as I know, wait() yields for 2 frames while task.wait() yields for 1 frame (with the difference of being way more observable in loops).
I would really appreciate if you clarified all of my questions, thanks!
Can you explain why wait() should no longer be used? Thanks.
task.wait() is more precise compared to wait()
But precision is not the issue here. He could have done wait(1) and it would still serves him fine.
I never said precision was the issue, im just saying that’s the reason why wait() should no longer be used. its always an option tho
You didnt do anything wrong, this is how computers work. Computers can’t be random, at least not digital ones (Quantum ones might). So a computer to be “random” it takes exterior factors, for example the weather, the runtime, the inputs, the day, the date etc… To generate the random number.
I’d recommend just decreasing the chances until it seems random enough
math.random(1,2) should work.
Prove it to yourself by putting it in a while loop and print out the value each time!
I’m not sure, I’m just going off of what developer relations & other developers have said.
Here are some threads that may answer your question:
And @WallsAreForClimbing has said that wait() is to be deprecated soon, however I cannot find the original reply where he said that, so you’re just gonna have to take my word for it.
Could you please clarify what you mean by physics-based throttling?
As physics calculations noticeably drop, the update rate would also drop. This is useful for when you want to consider physical simulations, especially those rendered on the server - and not use exact real-life time. For example, you’d like to give the player 5 seconds to run to a safe platform from a sinking one. If physics updates were to suddenly slow down, the player would be given more time to react and move. Otherwise, it would be near impossible for the player to get to the safe platform.
Isn’t
task.wait()more performant though? It can directly communicate with the task scheduler whilewait()can’t (to my knowledge).
I’m talking about the update rate. I haven’t heard of this task scheduler thing, but in the end, even if wait() were to be a bit less performant in that sense, it updates twice as slow. That’s got to make up for the indirect/less efficient checks, and more.
As for your third question, I believe the above covers it too.
math.random(1,2) should work, but if you don’t like it you can do it this way…
x = math.random(1,100)
randTeam = x % 2
Taking the remainder of random number x divided by 2 would give you a random number 0 or 1. 0 = Map1, 1 = Map2
So whenever you want to cover for server lag, use wait(n), otherwise if you want accuracy and no throttling, use task.wait(n)?
I told you it does work, its just not random
When u say not random, are you looking for equal number of hits between map1 and 2? You can literally get 100 hits on map1 before getting a hit on map2 and it’s still totally random.
The function math.random does not return a truly “random” number. No computer can do that, yet. Instead, it generates a pseudorandom number. There are ways to make the random number generator more random, but it isn’t possible to generate a true random number.
Actually, you can also do this also, which makes your code cleaner:
while task.wait() do
end
That is not true at all, math.random(A, B) can both return A or B, it’s not A only.
This is considered non-idiomatic (and overall bad) practice. You can read as to why that is so here:
All of these replies are an awkward way of doing this. The reason it isn’t random is because every time the game is started, the seed is the same.
To fix this, try this instead:
math.randomseed(time() * tick())
local randomNumber = math.random(1, 2)
Thank you very much fir understanding the situation
Here’s the post you’re looking for: