Why isn’t math.random not random?

Help and Feedback Scripting Support
#17

You could just make it a function that returns a number instead?

local function randTeam(): number
    return math.random(1, 2)
end

if randTeam() == 1 then
else
end
#18 
if math.random(1, 2) == 1 then
else
end

The full call to math.random isn’t that long, I don’t see why making a whole function is necessary, especially when it takes more lines that just doing the code yourself.

Try putting a print("Done loop!") after the loop to make sure it’s actually moving on from it, because it shouldn’t be. I personally think you should look a little into while-loops.

while wait() do
    randTeam = math.random(1, 2)
end

print("Done loop!") --look for "Done loop!" in the output
1 Like
#19

Wait() has its own benefits. Physics-based throttling, x2 update rate. More performant overall.

#20

That’s simple logic. The random number plucked out by math.random (either 1 or 2) is stored in a variable. That variable will act as a constant. It will not change until manually changed again. If the initial assignment were to be 1, it wouldn’t change to anything else unless specifically reassigned.

Using a dynamic approach, simply writting math.random(1, 2) when you need to use it would guarantee a pseudo-random number between 1 and 2 each time the method is called

#21

In your case, Random.new():NextInteger(1, #Maps) would be the best option, since it doesn’t return floats.

#22

However it should never be used anymore

&

#23

It still should. It has its advantages, as I’ve stated.

In the future there would still be uses for it over task.wait(), unless parameters are added to enable/disable physics throttling, and change the rate at which checks are made.

1 Like
#24

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!

2 Likes
#25

Can you explain why wait() should no longer be used? Thanks.

#26

task.wait() is more precise compared to wait()

#27

But precision is not the issue here. He could have done wait(1) and it would still serves him fine.

#28

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

#29

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

#30

math.random(1,2) should work.
Prove it to yourself by putting it in a while loop and print out the value each time!

2 Likes
#31

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.

1 Like
#32

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 while wait() 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.

2 Likes
Is it possible to use wait() within a coroutine?
#34

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

1 Like
#35

So whenever you want to cover for server lag, use wait(n), otherwise if you want accuracy and no throttling, use task.wait(n)?

1 Like
#36

I told you it does work, its just not random

1 Like
#37

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.