Player Acceleration/Deceleration

[DusterdooSmock]

Alright, I'm back with a new question...
- I'm coding vehicles, and so far it's going good acceleration was coded and tested(working) in about 5 minutes, but as for deceleration, I'm at a standstill. When you let off the button, it should gradually slow down, and the problem I am having is that once you let off the throttle, you instantly slow down.

Code: Select all

//In PlayerPreThink
if(self.button1)
{
   stuffcmd(self, "+forward\n");
   
   if(vlen(self.velocity) < 400)
   {
      self.velocity = (self.velocity * 1.1);
   }
}

//In PlayerPostThink
if(!self.button1)
{
   local float x;
   
   x = vlen(self.velocity);
   
   stuffcmd(self, "-forward\n");
   
   if(x > 0)
   {
      x = (x - 1);
   }
}

And I've tried this:

Code: Select all

if(!self.button1)
{
   local float x;
   
   x = vlen(self.velocity);
   
   if(x > 0)
   {
      x = (x - 1);
   }

      if(x == 0)
      {
               stuffcmd(self, "-forward\n");
      }
}

But, when I let off of the throttle, I didn't slow down at all.

Any ideas?

[Baker]

I'm no QuakeC genious but the methodology in the above is just very bad and defies accepted standards.

You shouldn't be stuffing +forward or -forward to a client. Commands with + or - are client states (if I press a key or button with +this, when I release it then that triggers -this ... you are breaking the model by not allowing the client to decide what key, button, control does an alias for starters and you can easily supply an autoexec.cfg or quake.rc that wires up buttons and controls with the mod in the way that you want them to achieve default controls that you want). The server and hence the progs.dat gets to make all the acceleration decisions.

Someone with more QuakeC knowledge should step in but even with my lesser QuakeC experience I can see that the way you have this written is "not good". You don't need to stuffcmd to a client to control that players speed, just look at the explosion code for instance that makes things like rocket jumping possible.

I know that I am not offering any solutions here so in some ways I'm not helpfully advancing what you are trying to do here, but I am hoping the above information gives some background to how QuakeC should be used.

[DusterdooSmock]

I never said it was a good way to do it, in fact i knew it wasn't anywhere near the right way, but it was the first thing that i thought of, so i tried it, and it worked.

[Baker]

I never said it was a good way to do it, in fact i knew it wasn't anywhere near the right way, but it was the first thing that i thought of, so i tried it, and it worked.

I think that is how everyone learns and everyone has done it.

[DusterdooSmock]

I never said it was a good way to do it, in fact i knew it wasn't anywhere near the right way, but it was the first thing that i thought of, so i tried it, and it worked.

I think that is how everyone learns and everyone has done it.

That's usually how i am when i write new code. I get an idea, try it, and if it works, i work out all of the kinks and purify it, and if it doesn't, then i brainstorm more ideas on how it could be done.

EDIT: I re-wrote the code using self.velocity, the v_forward vector, and a float that i created to store the player's speed, and i works beautifully now, it even decelerates like it should.

[Cobalt]

I think there is a cvar that controls how fast a player accelerates or slows down...I know DP has it. Found this:

*SV_STOPSPEED
Syntax: sv_stopspeed
Default: 100
The SV_STOPSPEED variable controls the rate of deceleration of players.
Do not confuse this with SV_FRICTION.