I'm noticing GC lag spikes in your video. To avoid it you should make it so your code reuses variables instead of creating new ones.

example:

"vec1 + vec2"
will create a new Vector which adds up to get garbage collected in a bunch and creates a lag spike

while:
"vec1x + vec2.x
vec1.y + vec2.y
vec1.z + vec2.z"

Does not create a new vector. It modifies vec1 instead. You might as well not use vectors at all really.

You can also try to calculate the physics less as well (every third or second frame) if you haven't done so yet.

Garbage collector? Never thought it could be the issue but it's possible since the lag spike always appear between regular intervals.
I will give your tip a try tomorrow and if it would solve the problem that would be great.
Thanks for the advice!

I see what they're trying to achieve, I just think they're achieving it in the wrong way, making it less realistic.

Dude what are you talking about? What is "realistic" to you? Do you want more tech demos showing flocking/steering with better graphics?

^second one demonstrates opensteer at 4:41, but it's demonstrating steering in general.

The steering is meant to be efficient. Doing multiple traces to calculate where all the people in a crowd should move to make way for a single person to go through would be very expensive and would look very unnatural and robotic.

I don't think you see what they are trying to achieve at all. If you don't think it's realistic, then you're calling most Pixar and Dreamworks movies unrealistic in crowd movement simulation, since most of them use flocking and boids. They just have different algorithms for setting the goal of each individual person in the crowds. In the opensteer demos, they're usually going around in a circle, or they're given a random goal.

Dude what are you talking about? What is "realistic" to you? Do you want more tech demos showing flocking/steering with better graphics?

^second one demonstrates opensteer at 4:41, but it's demonstrating steering in general.

The steering is meant to be efficient. Doing multiple traces to calculate where all the people in a crowd should move to make way for a single person to go through would be very expensive and would look very unnatural and robotic.

I don't think you see what they are trying to achieve at all. If you don't think it's realistic, then you're calling most Pixar and Dreamworks movies unrealistic in crowd movement simulation, since most of them use flocking and boids. They just have different algorithms for setting the goal of each individual person in the crowds. In the opensteer demos, they're usually going around in a circle, or they're given a random goal.

I get that they're going for efficiency, and I'm all for that, but it seems that the people using the algorithm (e.g. the Starcraft 2 example) are just using it straight off, without any changes or compromises to adapt it to what they're using. In an example where each unit in the crowd is a dimensionless coordinate, the standard algorithm works quite well, but as soon as you add volume to each object, you need to take precautions so that nothing awkward happens, and it seems they've overlooked that in a few of the examples above.

*video*
Translated the engine code for player movement into lua, except for the gravity code since I couldn't find it.

I was just interested in how source calculated player velocity when they move against the wall, and I saw some pretty mathy stuff.

It's incredibly laggy since its in lua. I was hoping to use it for an NPC base that did not rely on the engine NPCs, but seeing as it's unplayably laggy, I guess I have to find something else.

Edited:
doesn't seem to lag as much with just one player.

I might experiment with single player planetary gravity. and real gravity hulls, not just hacky ones.

I don't see how that would be laggy. Uclip used to do the same thing (until garry broke it - it might be fixed again now though) to prevent users from noclipping through other people's contraptions. It didn't lag at all. You must be doing something wrong :/
EDIT: This was the latest one I could find: http://forums.ulyssesmod.net/index.p...ic,1080.0.html

Just checked out uclip's code and it does less calculations.
This is the big chunk of code that causes the lag:

function ENT:TryPlayerMove( pFirstDest, pFirstTrace )
local bumpcount, numbumps;
local dir;
local d;
local numplanes;
local planes = {};
local primal_velocity, original_velocity;
local new_velocity;
local i, j;
local pm;
local endpos = Vector(0,0,0);
local time_left, allFraction;
local blocked;
numbumps = 4; // Bump up to four times
blocked = 0; // Assume not blocked
numplanes = 0; // and not sliding along any planes
original_velocity = VectorCopy( self.move_Velocity ); // Store original velocity
primal_velocity = VectorCopy( self.move_Velocity );
allFraction = 0;
time_left = FrameTime(); // Total time for this movement operation.
for bumpcount = 1, numbumps do
if ( self.move_Velocity:Length() == 0 ) then
break;
end
// Assume we can move all the way from the current origin to the
// end point.
endpos = VectorMA( self:GetPos(), time_left, self.move_Velocity );
// See if we can make it from origin to end point.
if ( true /*g_bMovementOptimizations*/ ) then
// If their velocity Z is 0, then we can avoid an extra trace here during WalkMove.
if ( pFirstDest == endpos ) then
pm = pFirstTrace;
else
local foo = self:Trace( self:GetPos(), self:GetPos() );
if ( foo.StartSolid and foo.Fraction != 1.0 ) then
MsgN( "bah" )
end
pm = self:Trace( self:GetPos(), endpos );
end
if ( pFirstDest ) then
pFirstDest.x = endpos.x;
pFirstDest.y = endpos.y;
pFirstDest.z = endpos.z;
end
else
pm = self:Trace( self:GetPos(), endpos );
end
allFraction = allFraction + pm.Fraction;
// If we started in a solid object, or we were in solid space
// the whole way, zero out our velocity and return that we
// are blocked by floor and wall.
if ( pm.StartSolid && pm.FractionLeftSolid == 0 && pm.Fraction == 0 ) then
// entity is trapped in another solid
self.move_Velocity = VectorCopy( vector_origin );
return 4;
end
// If we moved some portion of the total distance, then
// copy the end position into the pmove.origin and
// zero the plane counter.
if ( pm.Fraction > 0 ) then
if ( numbumps > 0 and pm.Fraction == 1 ) then
// There's a precision issue with terrain tracing that can cause a swept box to successfully trace
// when the end position is stuck in the triangle. Re-run the test with an uswept box to catch that
// case until the bug is fixed.
// If we detect getting stuck, don't allow the movement
local stuck = self:Trace(pm.HitPos, pm.HitPos);
if ( stuck.StartSolid or stuck.Fraction != 1 ) then
self.move_Velocity = VectorCopy( vector_origin );
break;
end
end
// actually covered some distance
self:SetPos( pm.HitPos );
original_velocity = VectorCopy( self.move_Velocity );
numplanes = 0;
end
// If we covered the entire distance, we are done
// and can return.
if ( pm.Fraction == 1 ) then
break; // move the entire distance
end
// Save entity that blocked us (since fraction was < 1.0)
// for contact
// Add it if it's not already in the list!!!
//MoveHelper( )->AddToTouched( pm, mv->m_vecVelocity );
// If the plane we hit has a high z component in the normal, then
// it's probably a floor
if ( pm.Normal.z > 0.7 ) then
blocked = blocked + 2 ^ 1; // floor
end
// If the plane has a zero z component in the normal, then it's a
// step or wall
if ( pm.Normal.z == 0 ) then
blocked = blocked + 2 ^ 2; // step / wall
end
// Reduce amount of m_flFrameTime left by total time left * fraction
// that we covered.
time_left = time_left - time_left * pm.Fraction;
// Did we run out of planes to clip against?
if ( numplanes >= MAX_CLIP_PLANES ) then
// this shouldn't really happen
// Stop our movement if so.
self.move_Velocity = VectorCopy( vector_origin );
break;
end
// Set up next clipping plane
planes[numplanes] = pm.Normal;
numplanes = numplanes + 1;
// modify original_velocity so it parallels all of the clip planes
//
// reflect player velocity
// Only give this a try for first impact plane because you can get yourself stuck in an acute corner by jumping in place
// and pressing forward and nobody was really using this bounce/reflection feature anyway...
if ( numplanes == 1 and not self.on_ground ) then
for i = 0, numplanes - 1 do
if ( planes[i].z > 0.7 ) then
// floor or slope
self:ClipVelocity( original_velocity, planes[i], new_velocity, 1 );
original_velocity = VectorCopy( new_velocity );
else
self:ClipVelocity( original_velocity, planes[i], new_velocity, 1 + 0.1 /* + sv_bounce.GetFloat() * (1 - player->m_surfaceFriction)*/ );
end
end
self.move_Velocity = VectorCopy( new_velocity );
original_velocity = VectorCopy( new_velocity );
else
local i = 0;
for i = 0, numplanes - 1 do
self:ClipVelocity(
original_velocity,
planes[i],
self.move_Velocity,
1 );
local j = 0;
for j = 0, numplanes - 1 do
if ( j != i ) then
// Are we now moving against this plane?
if ( self.move_Velocity:Dot( planes[j] ) < 0 ) then
break; // not ok
end
end
end
if ( j == numplanes ) then // Didn't have to clip, so we're ok
break;
end
end
// Did we go all the way through plane set
if ( i != numplanes ) then
// go along this plane
// pmove.velocity is set in clipping call, no need to set again.
else
// go along the crease
if ( numplanes != 2 ) then
self.move_Velocity = VectorCopy( vector_origin );
break;
end
dir = planes[0]:Cross( planes[1] );
dir:Normalize();
d = dir:Dot( self.move_Velocity );
self.move_Velocity = dir * d;
end
//
// if original velocity is against the original velocity, stop dead
// to avoid tiny occilations in sloping corners
//
d = self.move_Velocity:Dot( primal_velocity );
if ( d <= 0 ) then
self.move_Velocity = VectorCopy( vector_origin );
break;
end
end
end
if ( allFraction == 0 ) then
self.move_Velocity = VectorCopy( vector_origin );
end
// Check if they slammed into a wall
local fSlamVol = 0.0;
local fLateralStoppingAmount = primal_velocity:Length2D() - self.move_Velocity:Length2D();
if ( fLateralStoppingAmount > PLAYER_MAX_SAFE_FALL_SPEED * 2 ) then
fSlamVol = 1;
elseif ( fLateralStoppingAmount > PLAYER_MAX_SAFE_FALL_SPEED ) then
fSlamVol = 0.85;
end
//PlayerRoughLandingEffects( fSlamVol );
return blocked;
end

Just checked out uclip's code and it does less calculations.
This is the big chunk of code that causes the lag:

function ENT:TryPlayerMove( pFirstDest, pFirstTrace )
local bumpcount, numbumps;
local dir;
local d;
local numplanes;
local planes = {};
local primal_velocity, original_velocity;
local new_velocity;
local i, j;
local pm;
local endpos = Vector(0,0,0);
local time_left, allFraction;
local blocked;
numbumps = 4; // Bump up to four times
blocked = 0; // Assume not blocked
numplanes = 0; // and not sliding along any planes
original_velocity = VectorCopy( self.move_Velocity ); // Store original velocity
primal_velocity = VectorCopy( self.move_Velocity );
allFraction = 0;
time_left = FrameTime(); // Total time for this movement operation.
for bumpcount = 1, numbumps do
if ( self.move_Velocity:Length() == 0 ) then
break;
end
// Assume we can move all the way from the current origin to the
// end point.
endpos = VectorMA( self:GetPos(), time_left, self.move_Velocity );
// See if we can make it from origin to end point.
if ( true /*g_bMovementOptimizations*/ ) then
// If their velocity Z is 0, then we can avoid an extra trace here during WalkMove.
if ( pFirstDest == endpos ) then
pm = pFirstTrace;
else
local foo = self:Trace( self:GetPos(), self:GetPos() );
if ( foo.StartSolid and foo.Fraction != 1.0 ) then
MsgN( "bah" )
end
pm = self:Trace( self:GetPos(), endpos );
end
if ( pFirstDest ) then
pFirstDest.x = endpos.x;
pFirstDest.y = endpos.y;
pFirstDest.z = endpos.z;
end
else
pm = self:Trace( self:GetPos(), endpos );
end
allFraction = allFraction + pm.Fraction;
// If we started in a solid object, or we were in solid space
// the whole way, zero out our velocity and return that we
// are blocked by floor and wall.
if ( pm.StartSolid && pm.FractionLeftSolid == 0 && pm.Fraction == 0 ) then
// entity is trapped in another solid
self.move_Velocity = VectorCopy( vector_origin );
return 4;
end
// If we moved some portion of the total distance, then
// copy the end position into the pmove.origin and
// zero the plane counter.
if ( pm.Fraction > 0 ) then
if ( numbumps > 0 and pm.Fraction == 1 ) then
// There's a precision issue with terrain tracing that can cause a swept box to successfully trace
// when the end position is stuck in the triangle. Re-run the test with an uswept box to catch that
// case until the bug is fixed.
// If we detect getting stuck, don't allow the movement
local stuck = self:Trace(pm.HitPos, pm.HitPos);
if ( stuck.StartSolid or stuck.Fraction != 1 ) then
self.move_Velocity = VectorCopy( vector_origin );
break;
end
end
// actually covered some distance
self:SetPos( pm.HitPos );
original_velocity = VectorCopy( self.move_Velocity );
numplanes = 0;
end
// If we covered the entire distance, we are done
// and can return.
if ( pm.Fraction == 1 ) then
break; // move the entire distance
end
// Save entity that blocked us (since fraction was < 1.0)
// for contact
// Add it if it's not already in the list!!!
//MoveHelper( )->AddToTouched( pm, mv->m_vecVelocity );
// If the plane we hit has a high z component in the normal, then
// it's probably a floor
if ( pm.Normal.z > 0.7 ) then
blocked = blocked + 2 ^ 1; // floor
end
// If the plane has a zero z component in the normal, then it's a
// step or wall
if ( pm.Normal.z == 0 ) then
blocked = blocked + 2 ^ 2; // step / wall
end
// Reduce amount of m_flFrameTime left by total time left * fraction
// that we covered.
time_left = time_left - time_left * pm.Fraction;
// Did we run out of planes to clip against?
if ( numplanes >= MAX_CLIP_PLANES ) then
// this shouldn't really happen
// Stop our movement if so.
self.move_Velocity = VectorCopy( vector_origin );
break;
end
// Set up next clipping plane
planes[numplanes] = pm.Normal;
numplanes = numplanes + 1;
// modify original_velocity so it parallels all of the clip planes
//
// reflect player velocity
// Only give this a try for first impact plane because you can get yourself stuck in an acute corner by jumping in place
// and pressing forward and nobody was really using this bounce/reflection feature anyway...
if ( numplanes == 1 and not self.on_ground ) then
for i = 0, numplanes - 1 do
if ( planes[i].z > 0.7 ) then
// floor or slope
self:ClipVelocity( original_velocity, planes[i], new_velocity, 1 );
original_velocity = VectorCopy( new_velocity );
else
self:ClipVelocity( original_velocity, planes[i], new_velocity, 1 + 0.1 /* + sv_bounce.GetFloat() * (1 - player->m_surfaceFriction)*/ );
end
end
self.move_Velocity = VectorCopy( new_velocity );
original_velocity = VectorCopy( new_velocity );
else
local i = 0;
for i = 0, numplanes - 1 do
self:ClipVelocity(
original_velocity,
planes[i],
self.move_Velocity,
1 );
local j = 0;
for j = 0, numplanes - 1 do
if ( j != i ) then
// Are we now moving against this plane?
if ( self.move_Velocity:Dot( planes[j] ) < 0 ) then
break; // not ok
end
end
end
if ( j == numplanes ) then // Didn't have to clip, so we're ok
break;
end
end
// Did we go all the way through plane set
if ( i != numplanes ) then
// go along this plane
// pmove.velocity is set in clipping call, no need to set again.
else
// go along the crease
if ( numplanes != 2 ) then
self.move_Velocity = VectorCopy( vector_origin );
break;
end
dir = planes[0]:Cross( planes[1] );
dir:Normalize();
d = dir:Dot( self.move_Velocity );
self.move_Velocity = dir * d;
end
//
// if original velocity is against the original velocity, stop dead
// to avoid tiny occilations in sloping corners
//
d = self.move_Velocity:Dot( primal_velocity );
if ( d <= 0 ) then
self.move_Velocity = VectorCopy( vector_origin );
break;
end
end
end
if ( allFraction == 0 ) then
self.move_Velocity = VectorCopy( vector_origin );
end
// Check if they slammed into a wall
local fSlamVol = 0.0;
local fLateralStoppingAmount = primal_velocity:Length2D() - self.move_Velocity:Length2D();
if ( fLateralStoppingAmount > PLAYER_MAX_SAFE_FALL_SPEED * 2 ) then
fSlamVol = 1;
elseif ( fLateralStoppingAmount > PLAYER_MAX_SAFE_FALL_SPEED ) then
fSlamVol = 0.85;
end
//PlayerRoughLandingEffects( fSlamVol );
return blocked;
end

He has a name like Foohy, of course he's cool.
I think I saw a pen by a company called "Foohy"... Eh.
Anywho, I was wondering why there weren't kill icons for the world and fire. Anyone know why?
Since there isn't, I decided to make my own:
At least I'm trying. It'll be a while before I get to the level of epic you guys seep from your very pores :u