#GitHub - noaccessl/gmod-PhysicsCrashGuar...
1 messages · Page 1 of 1 (latest)
i dont like it too
to make it better: push entity to queue & process it in next tick with GM:Think
Real
From what I understood, GM:Think's description states that it can be called less when the server is lagging or may not be called at all if the server freezes.
So, using a 0-timer to make it work at maximum frequency.
Or am I wrong?
Called every server tick. Serverside, this is similar to GM:Think.
This hook WILL NOT run if the server is empty, unless you set the ConVar sv_hibernate_think to 1
Serverside, this is similar to GM:Think.
Called every frame. This will be the same as GM:Tick on the server when there is no lag, but will only be called once every processed server frame during lag.
See GM:Tick for a hook that runs every tick on both the client and server.
👍
oh you meant this..
is there any difference?
I meant timer.Simple(0, like https://github.com/noaccessl/gmod-PhysicsCrashGuard/blob/master/physcrashguard/constraints.lua#L12
also "but will only be called once every processed server frame during lag" sounds nosence
This isn’t called every frame but shouldn’t https://wiki.facepunch.com/gmod/Vector:DistToSqr be used
Returns the squared distance of 2 vectors, this is quicker to call than Vector:Distance as DistToSqr does not need to calculate the square root, which is an expensive process.
Squared distances should not be summed. If you need to sum distances, use Vector:Distance.
When performing a distance check, ensure the distance being checked against is s...
No. It won't make a difference.
Factually incorrect statement
prove it
Don’t waste performance just for the purpose of wasting it
ive personally been unable to see any performance difference between them when i tested
I’ll test when I get home
prove it
this is axiom
x
local numEntries = 1000000
local range = 100
local executionGap = 5 -- -1 to do it all in the same tick
local useDifferentData = true
local swapOrder = false
local entries = {}
local function generateEntries()
for i = 1, numEntries do
entries[i] = Vector( math.Rand( -range, range ), math.Rand( -range, range ), math.Rand( -range, range ) )
end
end
local function doStuff1()
local var
local prevEntry = entries[1]
for i = 2, numEntries do
local entry = entries[i]
var = prevEntry:Distance( entry )
prevEntry = entry
end
end
local function doStuff2()
local var
local prevEntry = entries[1]
for i = 2, numEntries do
local entry = entries[i]
var = prevEntry:DistToSqr( entry )
prevEntry = entry
end
end
local function checkTime( stuff, name )
local startTime = SysTime()
stuff()
local endTime = SysTime()
local diff = endTime - startTime
print( name .. " took " .. diff .. " seconds" )
return diff
end
local function compareStuff()
local methodName1 = "Method 1"
local methodName2 = "Method 2"
if swapOrder then
doStuff1, doStuff2 = doStuff2, doStuff1
methodName1 = "Method 2 (executed first)"
methodName2 = "Method 1 (executed last)"
end
local time1 = checkTime( doStuff1, methodName1 )
local function testTheRest()
local time2 = checkTime( doStuff2, methodName2 )
local timeDiff = math.abs( time2 - time1 )
if time1 < time2 then
print( methodName1 .. " was faster by " .. timeDiff .. " seconds!" )
print( "This is an improvement of " .. math.Round( 100 * timeDiff / time2, 2 ) .. "%" )
elseif time2 < time1 then
print( methodName2 .. " was faster by " .. timeDiff .. " seconds!" )
print( "This is an improvement of " .. math.Round( 100 * timeDiff / time1, 2 ) .. "%" )
else
print( "Both methods took the same time." )
end
end
if useDifferentData then
generateEntries()
end
if executionGap < 0 then
testTheRest()
else
timer.Simple( executionGap, testTheRest )
end
end
generateEntries()
timer.Simple( 5, compareStuff )
Running multiple tests each with and without executionGap, useDifferentData, and swapOrder ends up with inconsistent results that's easily skewed by execution order and delay.
With one million entries each, execution times ranged from around 0.9 to 0.12 and had improvement percentages of 0%-24%. This happened on both sides fairly evenly, determined by execution order more than anything else.
As far as I can tell, there's no significant performance difference between the two in gmod, despite sqrt algorithms being fundamentally slower in principle. Maybe the internal implementation doesn't actually skip the square root, or they're both so fast that it's negligible compared to the impact of cpu scheduling and the like?
This was tested on a 64bit dedicated server, and had similar results with/without jit.
Running it again with the distance lines commented out gives total method times around 0.0004 seconds, so reading the entry table had an insignificant impact.
Running again with var = entry.Distance and var = entr.DistToSqr instead gives times around 0.08, so roughly 10% of the total time is from accessing the distance functions without running them. It's less than the method's execution time, but still comparable in scale to the amount of variance observed.
Doing yet another test with math.Distance( x1, y1, x2, y2 ) and math.DistanceSqr( x1, y1, x2, y2 ) shows similar results; the two have very similar performance to one another, both sitting around 0.005 seconds for one million entries.
So, to reiterate, experimental tests appear to show that there is no significant performance difference between Vector:Distance() and Vector:DistToSqr()
@vast meteor threw this on my sever a couple days ago. It seems to prevent crashes but does some weird stuff like NPCs become transparent (resolve) and map moving objects like garage doors and even vehicles. Thought I would give you this feedback
Thank you for the feedback. I'll look into it.