Distance checks are actually one of the cheapest operations you can do, they run in O(1) and probably the most efficient way to check against a part. Only downside is distance checks create a sphere check and you cant check against a box for example
Finding the magnitude is a bit expensive because it uses square roots, itâs probably fine if youâre storing the magnitude in a variable instead of calculating it more than once.
1 Like
I wouldnât consider an O(1) operation expensive at all, you could easily run the operation 50k times in a frame and no lag at all. And if weâre ranking most efficient ways to check distance, magnitude is by far the fastest
1 Like
I agree, magnitude checking is probably the least expensive method on checking distance. Sometimes âmicro-optimizationsâ ruins your perspective on coding haha
This isnât really advice from me, more of speculation, with nothing to test with.
Must be a lot of calculating updates of the area while in the other function
O(1) is a lot of time to grab objects in an arena, true.
what
What do you mean what âŚI was agreeing with you.
The enter/exit function is basically for changing the local playerâs lighting. Also, good to know on region-creating every time.
If youâre curious. I plan on adding debounces for these so these functions donât run more than once.
function enter(v)
print(v)
local env = v:FindFirstChild("Environment")
print(env)
if env ~= false then
for i,v in ipairs(game.Lighting:GetChildren()) do
if not v:IsA("Folder") then
v:Destroy()
end
end
for i,v in ipairs(env:GetChildren()) do
if v:IsA("Sky") then
v:Clone().Parent = game.Lighting
elseif v:IsA("Atmosphere") then
v:Clone().Parent = game.Lighting
elseif v.Name == "ClockTime" then
game.Lighting.ClockTime = v.Value
elseif v.Name == "GeographicLatitude" then
game.Lighting.GeographicLatitude = v.Value
elseif v.Name == "OutdoorAmbient" then
game.Lighting.OutdoorAmbient = v.Value
elseif v.Name == "ColorShift_Top" then
game.Lighting.ColorShift_Top = v.Value
elseif v.Name == "ColorShift_Bottom" then
game.Lighting.ColorShift_Bottom = v.Value
elseif v.Name == "Ambient" then
game.Lighting.Ambient = v.Value
elseif v.Name == "Star" then
if v.Value ~= nil then
v.Value.Transparency = 1
end
elseif v.Name == "Gravity" then
game.Workspace.Gravity = v.Value
end
end
else
warn("Error with Environment")
end
end```This isnât exactly the case. while true do repeats the same code over and over again without first respecting other processes / resources.
Heartbeat waits until all Physics calculations have completed in a frame, then executes the code listed after all the important stuff is finished. This sort of argument was how wait() is insufficient against task.wait().
Straight from the RunService API Documentation.
Yeah I know that, but I meant it is tied directly to the task scheduler. I referenced wait() as an example. I guess in this sense if you used while true do with a wait it would be basically the same, except you could have just used task.wait() for better performance regardless. The argument is the same.
I did a benchmark to prove the speeds on another post of mine, but am a bit lazy to retrieve, so I recommend doing research on that in your own time.