Do action after player reaches specfic velocity.

Celty · **Author**

Is there a way to check if a player is going at or more then a specific velocity, and play a sound when they reach it.

Sorry there is not much context but that's the simplest way i could put it to avoid confusion.

Willing to pay for this to be made.

ThatOneGuy · *Last edited by ThatOneGuy; 08-01-2015 at 02:57.*

You would have to constantly monitor them. Not to hard to do, but uses a little CPU to monitor all players like that.

You could do something like the following...

Code:

new bool:ga_bSoundPlayed[MAXPLAYERS + 1] = {false, ...};
new g_iTickCount = 1;

public OnGameFrame()
{
	new Float:fVelocity = 0.0;

	if(g_iTickCount > MaxClients)
	{
		g_iTickCount = 1;
	}
	else
	{
		if(g_iTickCount % 1 == 0)
		{
			new client = g_iTickCount / 1;
			if(IsClientInGame(client) && IsPlayerAlive(client))
			{	
				GetEntPropVector(client, Prop_Data, "m_vecVelocity", fVelocity);
				if(fVelocity > 350)
				{
					if(!ga_bSoundPlayed[client])
					{
						EmitSoundToClientAny(client, sSoundPath);
					}
				}
				else
				{
					if(ga_bSoundPlayed[client])
					{
						ga_bSoundPlayed[client] = false;
					}
				}
				
				
			}
		}
		g_iTickCount++;
	}
}

The idea to use the tickcount for filtering out some of the processing is from Inami's macrodox plugin. I'm not sure the point in the dividing and multiplying by one, but I left that there in case there is some significance to it, since I havent tested it without. I really cant think of why that would be there though. Anyways, use a global boolean to check if they have already had the sound played. Make sure you precache the sounds as well and add them to the download table.

Celty · 08-02-2015 , 04:25 Re: Do action after player reaches specfic velocity.

Im looking for anyone who can make this for me, would be willing to pay.

Arkarr · *Last edited by Arkarr; 08-03-2015 at 15:17.*

Quote:

Originally Posted by Celty

Im looking for anyone who can make this for me, would be willing to pay.

Dude, don't pay anything to anyone except to ThatOneGuy who did that code above, this is pretty much everything.

Try this.

Bacardi · *Last edited by Bacardi; 08-04-2015 at 01:17.*

Less CPU burden

*
ThatOneGuy suggest

Arkarr · *Last edited by Arkarr; 08-03-2015 at 15:18.*

Quote:

Originally Posted by Bacardi

Your code [...]

Shouldn't you add the flag TIMER_FLAG_NOMAPCHANGE as well ? I think it could be better, so, if the map change, the sound will be still playing.
Or 'OnClientPutInServer' fire when the player join after a map change as well ?

Bacardi · *Last edited by Bacardi; 08-03-2015 at 15:32. Reason: more!*

Quote:

Originally Posted by Arkarr

Shouldn't you add the flag TIMER_FLAG_NOMAPCHANGE as well ? I think it could be better, so, if the map change, the sound will be still playing.
Or 'OnClientPutInServer' fire when the player join after a map change as well ?

Aa aa aa, that's beginner's mistake. Do your home work

3 Passing Data

3.1 Simple Values

[css] Native "KillTimer" error

ThatOneGuy · *Last edited by ThatOneGuy; 08-03-2015 at 21:16.*

Alternately, Bacardi, pass the client's userID and when converting back, check if still valid. If not, return Plugin_Stop. This avoids creating a global array of handles that could potentially be leaked if the coder doesnt handle them properly. I usually try to avoid global array handles (excluding ADT arrays and some others), since the code can often be accomplished without them...Just my preference though, since to me it is "cleaner". I used to do it the other way around though (killing timers).

Quote:

Originally Posted by Arkarr

Dude, don't pay anything to anyone except to ThatOneGuy who did that code above, this is pretty much everything.

Meh, no worries. Whoever makes it still needs to make the cvars and add the code to precache the sound and add to DL tbl. So, they're doing part of the work as well. The OP also had some additional requests (trail of flames when they break the speed threshold), that I'm not sure can be done with simplicity. Igniting or even parenting a fire entity would make it right on the client, not trail him, correct? Is there a way to make it more of a "trail" outside of creating a bunch of entities on a repeat timer, TP'ing them to the client, then killing them after X seconds? Hmmmm...one other idea would be to parent say 6 fire entities, each offset slightly more from the player. Then you wouldnt have to kill them, etc. until they lose speed. That might be an even better option, although I imagine it being slightly more "rigid" of a trail than the TP'ing ents.