Efficency on checking players distance in seconds. Question

Hiwi! Thank you for reading.
I guess the answer to this is obvious but I just want to make sure.
Whats more efficient?

I have a explosion system. I want to make the players near the explosion get the “push”. I already built 2 different methods.

  1. (This happens a few seconds after the bomb is placed and a few seconds before the bomb explodes) Using Players:GetPlayers(). And checking distance. And storing them into a table. Using that table to trigger CL and SV functions to make some stuff just milliseconds before the bomb explodes. (Cause I need to activate their ragdoll mode, and physics on their bodies before the explosion)

     	for _, p in pairs(Players:GetPlayers()) do
     		if p:DistanceFromCharacter(blwFX.Position) < 10 then
     			table.insert(blwnList, p)
  2. Create an invisible big sphere, just a few seconds before the bomb is placed, connect a function onTouch for everyone inside the ball, checking if the part is HumanoidRootPart, triggering the same CL and SV functions to activate the ragdoll and physics for those players. The ball is created a few seconds before the bomb is placed, triggering the functions onTouch milliseconds before the explosion.

Both works fine, no errors and in time. But, onTouch method, is iterating on all parts of the players, comparing if its a HumanoidRootPart. And the GetPlayers() it would only iterate on all players in server. So. This means that its better to iterate on 50 players, make a table, instead of iterate on the players that are touching the invisible ball?

Thank you for reading :3


If your concern is efficiency I don’t recommend those checks. Just use ProximityPrompts with its Style set to Custom. They are entirely written in native code, so they are objectively going to be more performant. You could create prompts named "DistancePrompt" or similar, then use ProximityPromptService.PromptShown, check the name, if the name is equal to whatever name you use for your distance prompts, then you would do your code.


I see… ProximityPrompt. I never used it before. Im gonna give it a check. Btw that link doesnt work xD
But no problem I will search for it, thank you so much! :3

1 Like

Hmm, seems like you already got the setup working, you can test it out yourself using os.clock() within a given scenario.

Here is an example though of me iterating through a model to find multiple Motor6D Instances in order to create a dictionary of them instead of manually indexing the right leg part then the motor.

Example bench marking
-- spare code used to benchmark obtaining a dictionary of named Motor6D values
--Yeah using predefined instance values with less to loop through is much faster

for i =1,1000 do
    local test = Instance.new("ObjectValue")
    test.Parent = mech
method 2 = get descendants
method 1 = object values
    Method 2 : 0.137 seconds
    method 1: 0.06 seconds
    makes sense loop through less
    with 1000+ more instances it becomes
    Method 2: 1.8 seconds
    Method 1: 0.07 seconds -- stays the same
    Might be better to use getDescendants initially then store them in an object value method

local startTime = os.clock()

for i=1,10000 do
    local Motor6DValues = mech.Motor6DValues:GetChildren()
    local ModelMotor6Ds = {}
    for i,v in pairs (Motor6DValues) do
        ModelMotor6Ds[v.Name] = v.Value

local deltaTime = os.clock() - startTime
print("Elapsed time method 1: " .. deltaTime)

local startTime = os.clock()

for i=1,10000 do
    local descendants = mech:GetDescendants()
    local ModelMotor6Ds = {}
    for i,v in pairs (descendants) do
        if v:IsA("Motor6D") then
            ModelMotor6Ds[v.Name] = v

local deltaTime = os.clock() - startTime
print("Elapsed time method 2: " .. deltaTime)

return nothing

Otherwise yeah the new proximity prompt mentioned by @sjr04 being used this way seems like a really cool alternative being event-based, the best part is it won’t show up in the script activity bar :tongue: shouldn’t have to worry about it at all.

1 Like

mmmhh! I never tried to check the time that is taking the methods by doing that!
I will use this to check everything more detailed! Thank you so much!
Yeah, by doing this I can be sure whats happening behind curtains related with time with any method I try. Very useful!

I had luck, cause I stored the Motor6D’s using the method 1 in ur script, in order to create the ragdolls, I thought doing it like that could improve the performance, but that was just luck. Checking it with os.clock() will give me more data to work in the right direction, thank you so much! :3

1 Like

Im not exactly sure if using the Prompt is more efficient. I need to test the os.clock() first to be sure whats happening. But I sense a very little more delay using the Prompt than the GetPlayers()

Due to the fact that, the Prompt is relying on Client, using a remote to send the player to server with a sanity check before calling a Module to execute all functions (maybe my procedure is not good actually) But, due to all that time that takes all the signals to reach the end point. I feel more delay when using the prompt than the getplayers()

I insist, maybe my approach is not good, but it seems that maybe checking the player’s distance on server, works faster than waiting for the client to send their player instance to trigger all other functions. Im not sure, but I see it. I need more tests and use the os.clock to check it. And probably make the system better, which could be the issue.

Checking distance on the client could be slow depending on the client’s device performance. So let the server handle the job instead.

1 Like

Thats what I think.
And using the ProximityPrompt relies on Client, I got better results by checking it on server. Thats what I think