if (self.deadflag >=DEAD_DEAD)
   {
      PlayerDeathThink ();
      return;
   }

In this guide, you will be changing your movetype. That is, a player's movetype is normally MOVETYPE_WALK. You will be changing that to MOVETYPE_FLY when the player selects flying mode. It will switch back to MOVETYPE_WALK when the player turns off flying mode. However, when a player dies, his movetype is changed to MOVETYPE_TOSS. But the modifications you will be making will cause the movetype to return to MOVETYPE_WALK since upon death, the player is no longer in flying mode. This will cause Quake to crash when the player attempts to respawn. To correct this problem, you will need to modify the above IF block. The modifications to the IF block below are highlighted in BLUE.

   if (self.deadflag >=DEAD_DEAD)
   {
      self.movetype = MOVETYPE_TOSS;
      PlayerDeathThink ();
      return;
   }

Step 2

After you make the above modifications, you will add a new IF block just below that IF block. Below that IF block, add the following:

   if (self.flags & FL_FLY)
   {
      self.movetype = MOVETYPE_FLY;

      if ( !(self.flags & FL_ONGROUND) )
      {
         self.flags = self.flags + FL_ONGROUND;
      }
   }
   else
   {
      self.movetype = MOVETYPE_WALK;
   }

As you can see, if the player is in flying mode, his/her movetype is changed to MOVETYPE_FLY. If the player is not, it is switched to MOVETYPE_WALK. The interesting point here is the second IF block that is nested inside this IF block. The FL_ONGROUNG flag is added to self.flags if it is not present. When you play a game using E1M8 level (the low gravity map), you will notice that when you are in the air, you have much difficulty in controlling your movement. This is because the FL_ONGROUND flag is removed when you are in the air. Adding the FL_ONGROUNG flag will return the control back to you.

Step 3

After adding the above IF block, below that add this new IF block:

   // must define variables before using them
   local float vel1, yaw_diff, up_z;
   local vector dir, dir2;

   makevectors (self.v_angle);

   if ( (self.flags & FL_FLY) && (self.velocity_x || self.velocity_y) )
   {
      vel1 = vlen (self.velocity); // its current speed
      dir = self.velocity;
      dir2 = vectoangles (dir);

      // This corrects an ID mistake.  They had the pitch angle in
      // reverse.
      dir2_x = dir2_x * -1;

      yaw_diff = dir2_y - self.v_angle_y;

      if (yaw_diff > 180)
         yaw_diff = yaw_diff - 360;

      if (fabs (self.v_angle_x) > 24)
      {
         up_z = TRUE;  // movement in z direction (up/down)

         if (fabs (fabs (yaw_diff) - 180) < 2)
         {
            dir = v_forward * -1;
         }
         else if (fabs (yaw_diff) < 2)
         {
            dir = v_forward;
         }
         else
         {
            up_z = FALSE;
         }
      }


      self.velocity = normalize (dir) * vel1;

      if (up_z)
      {
         if (vlen (self.velocity) > 10)
         {
            vel1 = cvar ("sv_maxspeed");
            self.velocity = normalize (dir) * vel1;
         }
      }
   }

All functions and variables must be defined first before using it. Here, we will be defining five new variables to use within PlayerPreThink. The keyword local tells the compiler that these variables are "local" variables and are only accessible within the PlayerPreThink function. This means that if another function uses the variable vel1, then that variable is actually DIFFERENT from the variable vel1 used in this function. Both variables have the same label, the same name but these two variables are actually two different variables.

Two of the variables are defined as VECTORS. A "vector" in Quake is actually a variable that holds three values. An example of a vector is the location of an entity. We call this location an origin and it is in what some would call "rectangular" coordinates of x, y ,z. So the location of an entity might be '338 -329 1048'. So somewhere in the map is the starting point. From this starting point, the entity is 338 units in the x direction, 329 units in the negative y direction and 1048 units in the positive z direction. If you have the origin of another entity, you can subtract the two origins to find a direction. The result of this subtraction is another vector. This vector holds the direction from one entity to the next. The length of this vector is often called the distance or speed.

Vectors, however, can be used in a different way. Rather than be used as a true vector, we can use these vectors to hold any three values. In this case, we want to store the pitch, the bearing (sometimes called 'yaw'), and the roll of an entity in one variable. For players, these three values are stored in the vector self.v_angle and self.angles. Self.angles stores the values for the player's model while self.v_angle stores the values for player's view (i.e. the pitch, bearing, and roll of the player's crosshairs). In most cases, the value of the roll is usually zero and, thus, it is often ignored.

The vector dir2 contains the yaw that is associated with the player's current velocity. If the player is moving in the same direction he/she is pointing his/her cross hairs, the difference between the yaw of the player's current velocity and the yaw of the player's view should be zero. In the IF block above, I checked for a value less than 2. This is because there can be round-off errors which can accumulate. Sometimes we call such error accumulation error propagation. You have to take into account this error propagation. Otherwise, it will greatly affect the results in a bad way.

The function vectoangles calculates the pitch, the bearing, and roll of a given vector. To give you an idea what these three things are, the pitch is how much you move your head up or down. That is, you move your chin up or down. The bearing is how much you turn your neck left or right. And the roll is how much you turn your head side ways. That is, you turn your neck so that one of your ears is now "pointing" towards the ground while the other ear now points up. Since this function calculates three components, these components are conveniently stored as a vector.

If the player is moving backwards but he/she is pointing his/her crosshairs in the forward direction, then the difference in yaw should be 180 degrees. Of course, you still have to take into account error propagation. Using the difference in yaw values, you can determine if the player wants to go backwards or move forwards. Although not needed in this modification, you can also use the difference in yaw to determine if the player is strafing left or right. A difference of +90 degrees means the player is strafing left while a difference of -90 degrees means the player is strafing right.

When the player's movetype is set to MOVETYPE_FLY, gravity is "removed" for that player. That is, if the player jumps up, he/she will move upwards continuously until he/she hits something. There is no gravity to slow the player down. However, the controls (eg. up arror, down arror, etc.) does not allow you to move up or down. It just moves you forward, backwards, strafe left, or strafe right. At some point, you would want to not only move forward (or backward) but also move up or down simultaneously. That is, you want the direction you are facing affect your movement. If you are looking up, you might want to move up by using the up arror key or move down while looking up by using the down arror key. This is where the player's pitch comes into play.

The function makevectors calculates three vectors using a given pitch, yaw, and roll. Remember, the pitch, yaw, and roll are stored in a single vector. So the parameter that makevector uses is a vector. Now this function takes this one vector and calculates three new vectors. These vectors are called V_FORWARD, V_UP, and V_RIGHT. These vectors are true vectors. That is, these vectors have a direction and magnitude. The magnitude of each vector is one. We often call such vectors unit vectors.

If the player is looking up or down by more than 24 degrees, the player's movement will be controlled by the vector v_forward which is the direction the player is looking at. This will allow the player to simultaneously move up/down while moving forward/backward. At the same time, if the player is strafing left and right while looking up or down, he/she does not have to worry about strafing downwards into lava (since he/she is looking at his/her target and not paying attention to the surroundings) or upwards into the ceiling to get smacked by splash damage caused by rocket explosions.

Another major reason that I use the pitch of the player is that I want the ability to fly straight ahead or backwards or left or right without worrying about drifting slightly upward or downward just because my cross hairs are not pointing straight ahead. I might, for instance, be engaged in battle and I want to strafe to a Quad or a better weapon. If I am firing at a target slightly below me, obviously, my crosshairs will not be pointing towards the direction I want. As a result, I might miss picking up a vital weapon or power-up. With this method, I do not have to worry about that.

One of the side-effects of changing the movetype to MOVETYPE_FLY is that at certain times, the player is no longer able to increase his/her speed when trying to move up or down. The controls begin to behave as if the FL_ONGROUND flag has been removed. The FL_ONGROUND flag has not been removed but the controls behave like it has been. To correct his problem, the variable up_z is used to determine whether or not the player needs a little boost. The magnitude of this boost is determined by the server.

Unfortunately, this correction has its own side-effect. Normally, if you are flying straight ahead and not moving up or down, you can slow down as if you were really walking on the ground. But if you are moving up or down, you will not slow down at all. So if you want to stop, you will need to point your crosshairs straight ahead so your pitch will no longer be greater than 24 degrees up (or down).

Step 4

Search for the function called PlayerPostThink. Look for the following IF block:

   if (self.deadflag)
      return;

Recall that a player's movetype should be MOVETYPE_TOSS when he/she has died. The modifications to the IF block below are highlighted in BLUE.

   if (self.deadflag)
   {
      self.movetype = MOVETYPE_TOSS;
      return;
   }

Step 5

After you make the above modifications, you will add a new IF block just below that IF block. Below that IF block, add the following:

   // must define variables before using them
   local float g;
   g = cvar ("sv_gravity") * frametime;

   if (self.flags & FL_FLY)
   {
      if (self.velocity_z > 0)
      {
         self.velocity_z = self.velocity_z - g;
      }

      if (self.velocity_z < 0)
      {
         self.velocity_z = self.velocity_z + g;
      }

      if (fabs (self.velocity_z) < g)
      {
         self.velocity_z = 0;
      }
   }

Recall that in fly mode, the player's movetype is set to MOVETYPE_FLY. Gravity is "removed" for that player when his/her movetype is set to MOVETYPE_FLY. The above code "adds" gravity back in. So if the player jumps up, he/she will slow down.

Step 6

Using your favorite editor, open the file called weapons.qc. Search for the function called ImpulseCommands. Somewhere in that function but BEFORE the last line, add the following IF block: