Closed Thread Subscribe

**Divran** · 21st May 2012

Wanted to do a batman cape or something similar.
So I tried to implement some cloth physics.
It works surprisingly well and lags a lot less than I expected.

*video*

You can set some parameters for it such as elasticity, air friction and gravity but they are kind of sensitive.
One decimal too much and it will spazz all over the place.

Now make a cape addon that lets you put your steam avatar on it.

**ralle105** · 21st May 2012

Sakarias88 posted:

Wanted to do a batman cape or something similar.
So I tried to implement some cloth physics.
It works surprisingly well and lags a lot less than I expected.

-video-

You can set some parameters for it such as elasticity, air friction and gravity but they are kind of sensitive.
One decimal too much and it will spazz all over the place.

Dat song

Th13teen · 21st May 2012

3D audio streaming with no modules.
It can play pretty much any on-line file or stream on any OS.

Grocel · 21st May 2012

Th13teen posted:

3D audio streaming with no modules.

You mean with GMod's stuck lua only?

Th13teen · 21st May 2012

Grocel posted:

You mean with GMod's stuck lua only?

Its lua, html and javascript.

**maurits150** · 21st May 2012

Th13teen posted:

3D audio streaming with no modules.
It can play pretty much any on-line file or stream on any OS.

Awesome. Now just add some way to get the sound spectrum. :)

**Splambob** · 21st May 2012

Sakarias88 posted:

Wanted to do a batman cape or something similar.
So I tried to implement some cloth physics.
It works surprisingly well and lags a lot less than I expected.

You can set some parameters for it such as elasticity, air friction and gravity but they are kind of sensitive.
One decimal too much and it will spazz all over the place.

That looks damn nice. Are you planning to let the code loose? I can think of a few applications for it.

**Wizard of Ass** · 21st May 2012

maurits150 posted:

Awesome. Now just add some way to get the sound spectrum. :)

I doubt this will be possible, the lua<->js interface is not exactly fast.

**Sakarias88** · 21st May 2012

Splambob posted:

That looks damn nice. Are you planning to let the code loose? I can think of a few applications for it.

Well, yeah but not in it's current state.
There are parts to be improved and flaws that needs to be fixed.
The cloth is only visible from one side for example.

**CapsAdmin** · 21st May 2012

Sakarias88 posted:

Wanted to do a batman cape or something similar.
So I tried to implement some cloth physics.
It works surprisingly well and lags a lot less than I expected.

You can set some parameters for it such as elasticity, air friction and gravity but they are kind of sensitive.
One decimal too much and it will spazz all over the place.

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.

Edited:

maurits150 posted:

Awesome. Now just add some way to get the sound spectrum. :)

flash! (used something a friend of mine made before and it works better than bass really)

**Sakarias88** · 21st May 2012

CapsAdmin posted:

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!

**Spencer Sharkey** · 22nd May 2012

A semi-proper battle tonight! Image-heavy.

Fun!

Hentie · 22nd May 2012

Are you using opensteer for the mob movement handling? :o

**ArmageddonScr** · 22nd May 2012

Hentie posted:

Are you using opensteer

What's that? Sounds interesting

**Spencer Sharkey** · 22nd May 2012

Hentie posted:

Are you using opensteer for the mob movement handling? :o

No.

Hentie · 22nd May 2012

It's an open-source flocking library written in C++.
It's the sort of flocking/queuing that Starcraft 2 uses to simulate large crowds.

**LemONPLaNE** · 22nd May 2012

Hentie posted:

It's an open-source flocking library written in C++.
It's the sort of flocking/queuing that Starcraft 2 uses to simulate large crowds.

That looks extremely unnatural.

**Mr. Quiggles** · 22nd May 2012

What has my imagination done!?

Pregnancy addon. I don't even know how my brain can concoct such a... mortifying and disturbing idea.

No, I barely even began to code it. I just thrown a screenshot together to at least have this for show.

Ugh... The screaming...

Hentie · 22nd May 2012

LemONPLaNE posted:

That looks extremely unnatural.

It isn't meant to be natural, it's meant to be efficient at moving large quantities of units.

Check out other opensteer examples where flocking and steering is used to simulate natural wandering crowds.

**LemONPLaNE** · 22nd May 2012

Hentie posted:

It isn't meant to be natural, it's meant to be efficient at moving large quantities of units.

Check out other opensteer examples where flocking and steering is used to simulate natural wandering crowds.

I'm not sure wandering crowds are supposed to intersect like that.

Hentie · 22nd May 2012

LemONPLaNE posted:

I'm not sure wandering crowds are supposed to intersect like that.

The individual entities are all no-collided to each other but they're designed to avoid each other, causing a crowd and not just a single blob.

I don't think you should be too anal about how they intersect each other, I think of it as interacting like soft-bodies.

**LemONPLaNE** · 22nd May 2012

Hentie posted:

The individual entities are all no-collided to each other but they're designed to avoid each other, causing a crowd and not just a single blob.

I don't think you should be too anal about how they intersect each other, I think of it as interacting like soft-bodies.

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

**Spencer Sharkey** · 22nd May 2012

It's not geared to make it look as if it's a natural crowd, however it makes it slightly more appealing.

It's biggest task is o make sure the entities don't collide and force physics upon each other, and it looks aesthetically better.

Flora KEidran · 22nd May 2012

Why are we arguing about "Crowd Control" inside of a video game?

Everybody has there person tastes, Some people like it looking realistic, while others might enjoy it looking cartoony and odd.

Hentie · 22nd May 2012

LemONPLaNE posted:

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.

**LemONPLaNE** · 23rd May 2012

Hentie posted:

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.

Anyway, I think that's enough derailing.

**Mr. Quiggles** · 23rd May 2012

The Sperm Bank, and Invitro Fertilization Clinic

I'm Preggers!

First Trimester, and going to attend Lamaze sessions early.

In Lamaze. Look at that emotionless face.

Finished my sessions! And reached my second trimester!

Abortion? No way!

My water broke!

In labor... (Why did my model change from Alyx to Mossman?...)

Awwwwww. Baby Danielle!

-----

Getting closer to the intended results: to be very disturbing with fecal matter and placental fluids profusely spewing everywhere, while the baby emits blood curdling frequencies from it's throat.

Edited:

Informative? I know too much someone my age is suppose to know about pregnancy...

**Kittai** · 23rd May 2012

What the...

Hentie · 23rd May 2012

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.

**CapsAdmin** · 23rd May 2012

Hentie posted:

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.

Why is it incredibly laggy? Did you do a literal translation? (can you show code?)

**Divran** · 23rd May 2012

Hentie posted:

*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

Hentie · 23rd May 2012

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

*It's a loose translation with some edits.

**Remscar** · 24th May 2012

Hentie posted:

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

*It's a loose translation with some edits.

And this is useful how?

Hentie · 24th May 2012

Well I was planning on using omnibot to create a navmesh since we don't have access to source's navmesh, but I needed way more control over NPC's than we currently have.

This was just a start.

I also want client predicted animation because I don't want to send each frame of animation over every second, which is what source is doing right now.

This is also a chance to have an open source player controller, which would allow for a ton more possibilities, like predictable custom player controls.

I don't know if that's being too optimistic, but that's just my vision.

**JeffDOA** · 24th May 2012

DarkShadow6 posted:

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

Edited:

In-game examples:
http://steamcommunity.com/id/DarkSha...15662730305742
http://steamcommunity.com/id/DarkSha...15662730308037
http://steamcommunity.com/id/DarkSha...15662730310762
http://steamcommunity.com/id/DarkSha...15662730321551
http://steamcommunity.com/id/DarkSha...15662730315032
http://steamcommunity.com/id/DarkSha...15662730323729
http://steamcommunity.com/id/DarkSha...15662730319082

Wat program is dat? ._.

Ice Tea · 24th May 2012

JeffDOA posted:

Wat program is dat? ._.

Gimp but with a sexy Steam windows theme.

**Spencer Sharkey** · 24th May 2012

Ice Tea posted:

Gimp but with a sexy Steam windows theme.

I find it to be nasty :(

**ralle105** · 24th May 2012

Mr. Quiggles posted:

The Sperm Bank, and Invitro Fertilization Clinic

I'm Preggers!

First Trimester, and going to attend Lamaze sessions early.

In Lamaze. Look at that emotionless face.

Finished my sessions! And reached my second trimester!

Abortion? No way!

My water broke!

In labor... (Why did my model change from Alyx to Mossman?...)

Awwwwww. Baby Danielle!

-----

Getting closer to the intended results: to be very disturbing with fecal matter and placental fluids profusely spewing everywhere, while the baby emits blood curdling frequencies from it's throat.

Edited:

Informative? I know too much someone my age is suppose to know about pregnancy...

When can we expect a video?

KoTTsNoRk · 24th May 2012

ralle105 posted:

When can we expect a video?

Oh god please no!

TheTrueAndy · 24th May 2012

Hentie posted:

Fixing up overv's 3D panels.

That's a scaled panel.

my changes:

local function getCursorPos()
	local p = planeLineIntersect( LocalPlayer():EyePos(), LocalPlayer():GetAimVector(), origin, normal )
	
	local vec, ang = WorldToLocal( p, Angle(0,0,0), origin, normal:Angle() );
	
	return math.ceil( vec.y / scale ), math.ceil( -vec.z / scale );
end

local function planeLineIntersect( ray_pos, ray_dir, plane_pos, plane_n )
	local t = -((ray_pos-plane_pos):Dot( plane_n ) / ray_dir:Dot( plane_n ));
	local p = ray_pos + t * ray_dir;
	
	return p;
end

The mouse will now be correct in any kind of angle except for roll, since it takes the screen's normal.

Looking good.

-SNIP-