Walking and Running for player

[jim]

So how do I check if player is running or walking in qc?

[Sajt]

Well, running/walking is a clientside distinction (see 'cl_movespeedkey' cvar). That said, walking is usually 200 and running is usually 320 or 400 as far as I know.

You could check the player's velocity:

Code: Select all

if (self.flags & FL_ONGROUND)
{
  float xyspeed = vlen(self.velocity - '0 0 1' * self.velocity_z);
  if (xyspeed > 230)   // (give a little room so it doesn't twitch between running and walking when turning)
    running;
  else
    walking or stopped;
}

Depending on what you're using it for, there can be a problem. The player accelerates/decelerates, so when he starts running from a standstill, it will detect him as walking for a short period before switching to running.

If you're discerning run/walk to play different animations, this can make it look odd. Ditto if you're using it to play footstep sounds at different rates. However, if you're just using this for something simple like fatigue when running, it should be fine.

Or, if you're using DarkPlaces, you can check the player's '.movement' vector. This is set to the input sent by the client. For example if they are holding down the forward key and +speed, it will be set to '400 0 0' (this is the desired velocity, relative to your angles, e.g. X=forward). It doesn't include any acceleration/deceleration.

[jim]

I plan to use it for playing different animations, playing footstep sounds and getting fatigued when running a lot... I also use DarkPlaces, so that movement vector sounds the best idea.

I've already tried that velocity checking, but it seemed to work terrible. I didn't mind it looking slightly odd, but it crashed when I used the checking in all standing, walking and running actions.

[Urre]

Considering you're using Darkplaces, you should look into the SV_PlayerPhysics function (part of dpmod, as well as available as a separate file on the darkplaces site, called sv_user.qc iirc), which utilizes the movement vector Sajt mentioned, and is generally much better to use for poking at clients movement reaction, than having to hack stuff in like in the old days, what Sajt was giving an example of.

[jim]

I've looked into that sv_user.qc and I'm a bit unsure what it does. Does it override some other functions in other qc files? I'm seeing some stuff in some functions that are probably doing something same like the SV_PlayerPhysics. Yesterday I made some improved falling damage, but I didn't do it into that SV_PlayerPhysics function... but it works, but I think the falling damage will not just happen for players and I think it won't be just falling damage. I think people would get hurt if they were thrown hard into the ceiling or walls too.

Well... I'm quite used to hacking stuff in. With my old mod for Doomsday I managed to hack support for (nearly) unlimited amounts of weapons, while it actually supported only 10 weapons.. adding 11th weapon would make the game program suddenly quit after some initializing. Then later I noticed my weapon support hack was rather useless, since I had only modelled 13 weapons and never modelled more for it...

Anyway that SV_PlayerPhysics function looks complicated to me. Can I use it to change player move speed? I think I want player walk and run much slower.. current walk speed looks allright for running animation. And when I get some crouching done, it should be slower than walking and speed key shouldn't speed up crouch moving at all... I'll wonder about crouching later when I have crouching animations...

Right now I just have these:
Cloaked Noid animations

[Sajt]

The velocity checking crashing is probably a bug in some of your other code.


As for .movement, remember that .movement is set using the client's movement speed cvars. So if the client has cl_forwardspeed set to 200, and they move forward, .movement will be set to '200 0 0'. But if they have cl_forwardspeed set to 100, it will be set to '100 0 0'.

You can put your own values for the cl_*speed cvars in a config file, or stuffcmd them from QuakeC. Then set sv_maxspeed so that player's can't cheat by setting their speed to high. For example:

stuffcmd:
cl_forwardspeed 150
cl_sidespeed 150
cl_backspeed 150
cl_upspeed 150
cl_movespeedkey to 2 (this is how much their speed is multiplied when holding down +speed)

Then set the server sv_maxspeed to 300.

Now if a client tries to cheat by setting cl_forwardspeed to 999, they still will only be able to go 300, and they will have lost the ability to walk so they'll be noisy and fatigued all the time.

Note that the client may send smaller values if they have an analog controller. Analog controllers are tough because there is no hard line between running and walking, but fortunately nobody plays Quake with a joystick.

As for detecting whether they are running or walking, check the .movement vector and compare it with the expected values of the cl_*speed cvars (I say 'expected' because the server can't know what the client has actually set them to).