FPS RigidBody Fix (#1500)

* Changed the wording in the first three parts of the FPS tutorial to
not use "we" when refering to the player.

Changed the name of variables outside of a function to "class variables"
(instead of "global variables", which was less accurate and can be confusing)

Changed the code in RigidBody_hit_test.gd to take bullet rotation into account.

* Changed part 4 and part 5 of the FPS tutorial to not use "we" as often, and not to use "we" for referring to scripts
and other objects.

Changed some of the code to reflect changes in RigidBody_hit_test.gd.

Fixed typos and other small changes.

* Changed part 6 of the FPS tutorial to not use "we" when referring to scripts and other objects.
Fixed a couple minor things in part 2.
Updated all of the zip files to reflect the changed code in RigidBody_hit_test.gd.

tutorials/3d/fps_tutorial/part_five.rst

@@ -6,7 +6,7 @@ Part 5
 Part Overview
 -------------
 
-In this part we're going to add grenades to our player, give our player the ability to grab and throw objects, and add turrets!
+In this part we're going to add grenades to the player, give the player the ability to grab and throw objects, and add turrets!
 
 .. image:: img/PartFiveFinished.png
 
@@ -19,20 +19,20 @@ Let's get started!
 Adding grenades
 ---------------
 
-First, let's give our player some grenades to play with. Open up ``Grenade.tscn``.
+First, let's give the player some grenades to play with. Open up ``Grenade.tscn``.
 
-There's a few things to note here, the first and foremost being that our grenades are going to use :ref:`RigidBody <class_RigidBody>` nodes.
-We're going to use :ref:`RigidBody <class_RigidBody>` nodes for our grenades so they bounce around the world in a somewhat realistic manner.
+There's a few things to note here, the first and foremost being that the grenades are going to use :ref:`RigidBody <class_RigidBody>` nodes.
+We're going to use :ref:`RigidBody <class_RigidBody>` nodes for our grenades so they bounce around the world in a (somewhat) realistic manner.
 
-The second thing to note is ``Blast_Area``. This is a :ref:`Area <class_Area>` node that will represent the blast radius of our grenade.
+The second thing to note is ``Blast_Area``. This is a :ref:`Area <class_Area>` node that will represent the blast radius of the grenade.
 
 Finally, the last thing to note is ``Explosion``. This is the :ref:`Particles <class_Particles>` node that will emit an explosion effect when
-the grenades explodes. One thing to note here is that we have ``One shot`` enabled. This is so we emit all of our particles at once. We're also emitting in world
+the grenade explodes. One thing to note here is that we have ``One shot`` enabled. This is so we emit all of the particles at once. The particles are also emitting using world
 coordinates instead of local coordinates, so we have ``Local Coords`` unchecked as well.
 
-.. note:: If you want you can see how the particles are set up by looking through it's ``Process Material`` and ``Draw Passes``.
+.. note:: If you want, you can see how the particles are set up by looking through the particle's ``Process Material`` and ``Draw Passes``.
 
-Let's write the code needed for our grenade. Select ``Grenade`` and make a new script called ``Grenade.gd``. Add the following:
+Let's write the code needed for the grenade. Select ``Grenade`` and make a new script called ``Grenade.gd``. Add the following:
 
 ::
     
@@ -77,7 +77,7 @@ Let's write the code needed for our grenade. Select ``Grenade`` and make a new s
                 var bodies = blast_area.get_overlapping_bodies()
                 for body in bodies:
                     if body.has_method("bullet_hit"):
-                        body.bullet_hit(GRENADE_DAMAGE, global_transform.origin)
+                        body.bullet_hit(GRENADE_DAMAGE, body.global_transform.looking_at(global_transform.origin, Vector3(0,1,0)) )
                 
                 # This would be the perfect place to play a sound!
                 
@@ -88,7 +88,7 @@ Let's write the code needed for our grenade. Select ``Grenade`` and make a new s
                 if explosion_wait_timer >= EXPLOSION_WAIT_TIME:
                     queue_free()
 
-Let's go over what's happening, starting with the global variables:
+Let's go over what's happening, starting with the class variables:
 
 * ``GRENADE_DAMAGE``: The amount of damage the grenade causes when it explodes.
 * ``GRENADE_TIME``: The amount of time the grenade takes (in seconds) to explode once it's created/thrown.
@@ -100,56 +100,57 @@ Let's go over what's happening, starting with the global variables:
 * ``blast_area``: The blast :ref:`Area <class_Area>` used to damage things when the grenade explodes.
 * ``explosion_particles``: The :ref:`Particles <class_Particles>` that play when the grenade explodes.
 
-Notice how ``EXPLOSION_WAIT_TIME`` is a rather strange number (``0.48``). This is because we want ``EXPLOSION_WAIT_TIME`` to be the length of time
-the particles are emitting, so when the particles are done we destroy/free the grenade. We calculate ``EXPLOSION_WAIT_TIME`` by taking the particle's life time
+Notice how ``EXPLOSION_WAIT_TIME`` is a rather strange number (``0.48``). This is because we want ``EXPLOSION_WAIT_TIME`` to be equal to the length of time
+the explosion particles are emitting, so when the particles are done we destroy/free the grenade. We calculate ``EXPLOSION_WAIT_TIME`` by taking the particle's life time
 and dividing it by the particle's speed scale. This gets us the exact time the explosion particles will last.
 
 ______
 
 Now let's turn our attention to ``_ready``.
 
-First we get all of the nodes we'll need and assign them to the proper global variables.
+First we get all of the nodes we'll need and assign them to the proper class variables.
 
 We need to get the :ref:`CollisionShape <class_CollisionShape>` and :ref:`MeshInstance <class_MeshInstance>` because similarly to the target in :ref:`doc_fps_tutorial_part_four`,
 we will be hiding the grenade's mesh and disabling the collision shape when the grenade explodes.
 
-The reason we need to get the blast :ref:`Area <class_Area>` is so we can damage everything inside it when it explodes. We'll be using code similar to the knife
-weapon in our player. We need the :ref:`Particles <class_Particles>` so we can emit them when we explode.
+The reason we need to get the blast :ref:`Area <class_Area>` is so we can damage everything inside it when the grenade explodes. We'll be using code similar to the knife
+code in the player. We need the :ref:`Particles <class_Particles>` so we can emit particles when the grenade explodes.
 
-After we get all of the nodes and assign them to their global variables, we then make sure the explosion particles are not emitting, and that they are set to
-emit in one shot.
+After we get all of the nodes and assign them to their class variables, we then make sure the explosion particles are not emitting, and that they are set to
+emit in one shot. This is to be extra sure the particles will behave the way we expect them to.
 
 ______
 
 Now let's look at ``_process``.
 
-First we check to see if the ``grenade_timer`` is less than ``GRENADE_TIMER``. If it is, we add ``delta`` and return. This is so we have to wait ``GRENADE_TIME`` seconds,
-allowing our :ref:`RigidBody <class_RigidBody>` to move around.
+First we check to see if the ``grenade_timer`` is less than ``GRENADE_TIMER``. If it is, we add ``delta`` and return. This is so the grenade has to wait ``GRENADE_TIME`` seconds,
+before exploding, allowing the :ref:`RigidBody <class_RigidBody>` to move around.
 
-If ``grenade_timer`` is at ``GRENADE_TIMER`` or higher, we then need to check if we waited long enough and need to explode. We do this by checking to see
+If ``grenade_timer`` is at ``GRENADE_TIMER`` or higher, we then need to check if the grenade has waited long enough and needs to explode. We do this by checking to see
 if ``explosion_wait_timer`` is equal to ``0`` or less. Since we will be adding ``delta`` to ``explosion_wait_timer`` right after, whatever code under the check
-will only be called once, right when we've waited long enough and need to explode.
+will only be called once, right when the grenade has waited long enough and needs to explode.
 
-If we've waited long enough to explode, we first tell the ``explosion_particles`` to emit. Then we make ``grenade_mesh`` invisible, and disable ``rigid_shape``, effectively
-hiding our grenade.
+If the grenade has waited long enough to explode, we first tell the ``explosion_particles`` to emit. Then we make ``grenade_mesh`` invisible, and disable ``rigid_shape``, effectively
+hiding the grenade.
 
 We then set the :ref:`RigidBody <class_RigidBody>`'s mode to ``MODE_STATIC`` so the grenade does not move.
 
 Then we get all of the bodies in ``blast_area``, check to see if they have the ``bullet_hit`` method/function, and if they do we call it and pass in ``GRENADE_DAMAGE`` and
-the grenade's position.
+the transform from the body looking at the grenade. This makes it where the bodies exploded by the grenade will explode outwards from the grenade's position.
 
 We then check to see if ``explosion_wait_timer`` is less than ``EXPLOSION_WAIT_TIME``. If it is, we add ``delta`` to ``explosion_wait_time``.
 
 Next we check to see if ``explosion_wait_timer`` is more than or equal to ``EXPLOSTION_WAIT_TIME``. Because we added ``delta``, this will only be called once.
-If ``explosion_wait_timer`` is more or equal to ``EXPLOSION_WAIT_TIME``, we've waited long enough to let the :ref:`Particles <class_Particles>` play and can free/destroy ourselves.
+If ``explosion_wait_timer`` is more or equal to ``EXPLOSION_WAIT_TIME``, the grenade has waited long enough to let the :ref:`Particles <class_Particles>` play
+and we can free/destroy the grenade as we no longer need it.
 
 ______
 
 Let's quickly get the sticky grenade set up too. Open up ``Sticky_Grenade.tscn``.
 
 ``Sticky_Grenade.tscn`` is almost identical to ``Grenade.tscn``, with one small addition. We now have a second
-:ref:`Area <class_Area>`, called ``Sticky_Area``. We'll be using ``Stick_Area`` to detect when we've collided with
-the environment and need to stick to something.
+:ref:`Area <class_Area>`, called ``Sticky_Area``. We will be using ``Stick_Area`` to detect when the sticky grenade has collided with
+the environment and needs to stick to something.
 
 Select ``Sticky_Grenade`` and make a new script called ``Sticky_Grenade.gd``. Add the following:
 
@@ -228,7 +229,7 @@ Select ``Sticky_Grenade`` and make a new script called ``Sticky_Grenade.gd``. Ad
                 var bodies = blast_area.get_overlapping_bodies()
                 for body in bodies:
                     if body.has_method("bullet_hit"):
-                        body.bullet_hit(GRENADE_DAMAGE, global_transform.origin)
+                        body.bullet_hit(GRENADE_DAMAGE, body.global_transform.looking_at(global_transform.origin, Vector3(0,1,0)) )
                 
                 # This would be the perfect place to play a sound!
             
@@ -241,16 +242,16 @@ Select ``Sticky_Grenade`` and make a new script called ``Sticky_Grenade.gd``. Ad
                         attach_point.queue_free()
                     queue_free()
                 
-The code above is almost identical to the code for ``Grenade.gd``, so let's go over what's changed.
+The code above is almost identical to the code for ``Grenade.gd``, so let's just go over what's changed.
 
-First, we have a few more global variables:
+First, we have a few more class variables:
 
-* ``attached``: A variable for tracking whether or not we've attached to a :ref:`PhysicsBody <class_PhysicsBody>`.
-* ``attach_point``: A variable to hold a :ref:`Spatial <class_Spatial>` that will be at the position we collided at.
+* ``attached``: A variable for tracking whether or not the sticky grenade has attached to a :ref:`PhysicsBody <class_PhysicsBody>`.
+* ``attach_point``: A variable to hold a :ref:`Spatial <class_Spatial>` that will be at the position the sticky grenade collided at.
 * ``player_body``: The player's :ref:`KinematicBody <class_KinematicBody>`.
 
-These additions are so we can stick to any :ref:`PhysicsBody <class_PhysicsBody>` we happen to hit. We also now
-need the player's :ref:`KinematicBody <class_KinematicBody>` so we don't stick to the player that threw this grenade.
+These additions are so the sticky grenade can stick to any :ref:`PhysicsBody <class_PhysicsBody>` it happens to hit. We also now
+need the player's :ref:`KinematicBody <class_KinematicBody>` so the sticky grenade does not stick to the player when the player throws it.
 
 ______
 
@@ -261,41 +262,44 @@ ______
 
 Next let's take a look at ``collided_with_body``.
 
-First we make sure we're not colliding with ourself. Because our :ref:`Area <class_Area>` does not know it's attached to the grenade's :ref:`RigidBody <class_RigidBody>`,
-we need to make sure we're not going to stick to ourself. If we have collided with ourself, we ignore it by returning.
+First we make sure the sticky grenade is not colliding with itself.
+Because the sticky :ref:`Area <class_Area>` does not know it's attached to the grenade's :ref:`RigidBody <class_RigidBody>`,
+we need to make sure it's not going to stick to itself by checking to make sure the body it has collided with is not itself.
+If we have collided with ourself, we ignore it by returning.
 
-We then check to see if we have something assigned to ``player_body``, and if the body we collided with is the player that threw this grenade.
-If the body we've collided with is indeed ``player_body``, we ignore it by returning.
+We then check to see if we have something assigned to ``player_body``, and if the body the sticky grenade has collided with is the player that threw it.
+If the body the sticky grenade has collided with is indeed ``player_body``, we ignore it by returning.
 
-Next we check if we are attached already or not.
+Next we check if the sticky grenade has attached to something already or not.
 
-If we are not attached, we then set ``attached`` to true so we know we've attached to something.
+If the sticky grenade is not attached, we then set ``attached`` to true so we know the sticky grenade has attached to something.
 
-We then make a new :ref:`Spatial <class_Spatial>` node, and make it a child of the body we collided with. We then set the :ref:`Spatial <class_Spatial>`'s position
-to our current position.
+We then make a new :ref:`Spatial <class_Spatial>` node, and make it a child of the body the sticky grenade collided with. We then set the :ref:`Spatial <class_Spatial>`'s position
+to the sticky grenade's current global position.
 
-.. note:: Because we've added the :ref:`Spatial <class_Spatial>` as a child of the body we've collided with, it will follow along with said body. We can then use this
-          :ref:`Spatial <class_Spatial>` to set our position, so we're always at the same position relative to the body we collided with.
+.. note:: Because we've added the :ref:`Spatial <class_Spatial>` as a child of the body the sticky grenade has collided with, it will follow along with said body.
+          We can then use this :ref:`Spatial <class_Spatial>` to set the sticky grenade's position, so it is always at the same position relative to the body it collided with.
 
-We then disable ``rigid_shape`` so we're not constantly moving whatever body we've collided with. Finally, we set our mode to ``MODE_STATIC`` so the grenade does not move.
+We then disable ``rigid_shape`` so the sticky grenade is not constantly moving whatever body it has collided with.
+Finally, we set our mode to ``MODE_STATIC`` so the grenade does not move.
 
 ______
 
 Finally, lets go over the few changes in ``_process``.
 
-Now we're checking to see if we are attached right at the top of ``_process``.
+Now we're checking to see if the sticky grenade is attached right at the top of ``_process``.
 
-If we are attached, we then make sure the attached point is not equal to ``null``.
-If the attached point is not equal to ``null``, we set our global position (using our global :ref:`Transform <class_Transform>`'s origin) to the global position of
+If the sticky grenade is attached, we then make sure the attached point is not equal to ``null``.
+If the attached point is not equal to ``null``, we set the sticky grenade's global position (using its global :ref:`Transform <class_Transform>`'s origin) to the global position of
 the :ref:`Spatial <class_Spatial>` assigned to ``attach_point`` (using its global :ref:`Transform <class_Transform>`'s origin).
 
-The only other change is now before we free/destroy the grenade, we check to see if we have an attached point. If we do, we also call ``queue_free`` on it, so it's
-also freed/destroyed.
+The only other change is now before we free/destroy the sticky grenade is to check to see if the sticky grenade has a attached point.
+If it does, we also call ``queue_free`` on the attach point, so it's also freed/destroyed.
 
 Adding grenades to the player
 -----------------------------
 
-Now we need to add some code to ``Player.gd`` so we can use our grenades.
+Now we need to add some code to ``Player.gd`` so we can use the grenades.
 
 First, open up ``Player.tscn`` and expand the node tree until you get to ``Rotation_Helper``. Notice how in
 ``Rotation_Helper`` we have a node called ``Grenade_Toss_Pos``. This is where we will be spawning the grenades.
@@ -303,7 +307,7 @@ First, open up ``Player.tscn`` and expand the node tree until you get to ``Rotat
 Also notice how it's slightly rotated on the ``X`` axis, so it's not pointing straight, but rather slightly up. By changing
 the rotation of ``Grenade_Toss_Pos``, you can change the angle the grenades are tossed at.
 
-Okay, now lets start making the grenades work with our player. Add the following global variables to ``Player.gd``:
+Okay, now let's start making the grenades work with the player. Add the following class variables to ``Player.gd``:
 
 ::
     
@@ -313,11 +317,11 @@ Okay, now lets start making the grenades work with our player. Add the following
     var sticky_grenade_scene = preload("res://Sticky_Grenade.tscn")
     const GRENADE_THROW_FORCE = 50
 
-* ``grenade_amounts``: The amount of grenades we are currently carrying for each type of grenade.
-* ``current_grenade``: The name of the grenade type we're currently using.
+* ``grenade_amounts``: The amount of grenades the player is currently carrying (for each type of grenade).
+* ``current_grenade``: The name of the grenade the player is currently using.
 * ``grenade_scene``: The grenade scene we worked on earlier.
 * ``sticky_grenade_scene``: The sticky grenade scene we worked on earlier.
-* ``GRENADE_THROW_FORCE``: The force at which we throw the grenade at.
+* ``GRENADE_THROW_FORCE``: The force at which the player will throw the grenades at.
          
 Most of these variables are similar to how we have out weapons set up.
 
@@ -358,26 +362,26 @@ Now we need to add some code in ``_process_input`` Add the following to ``_proce
          
 Let's go over what's happening here.
 
-First, we check to see if the ``change_grenade`` action has just been pressed. If it has, we then check to see which grenade we
-are currently using. Based on the name of the grenade we're currently using, we change ``current_grenade`` to the opposite grenade name.
+First, we check to see if the ``change_grenade`` action has just been pressed. If it has, we then check to see which grenade the player is
+currently using. Based on the name of the grenade the player is currently using, we change ``current_grenade`` to the opposite grenade name.
 
-Next we check to see if the ``fire_grenade`` action has just been pressed. If it has, we then check to see if we have more than ``0`` grenades for the
-current grenade we have selected.
+Next we check to see if the ``fire_grenade`` action has just been pressed. If it has, we then check to see if the player has more than ``0`` grenades for the
+current grenade type selected.
 
-If we have more than ``0`` grenades, we then remove one from the grenade amounts for the current grenade.
-Then, based on the grenade we're currently using we instance the proper grenade scene and assign it to ``grenade_clone``.
+If the player has more than ``0`` grenades, we then remove one from the grenade amounts for the current grenade.
+Then, based on the grenade the player is currently using, we instance the proper grenade scene and assign it to ``grenade_clone``.
 
-Next we add ``grenade_clone`` as a child of the node at the root, and set its global :ref:`Transform <class_Transform>` to
+Next we add ``grenade_clone`` as a child of the node at the root and set its global :ref:`Transform <class_Transform>` to
 ``Grenade_Toss_Pos``'s global :ref:`Transform <class_Transform>`. Finally, we apply an impulse to the grenade so that it is launched forward, relative
 to the ``Z`` directional vector of ``grenade_clone``'s.
 
 ______
 
-Now we can use both types of grenades, but there's a few things we should probably add before we move on to adding the other things.
+Now the player can use both types of grenades, but there is still a few things we should probably add before we move on to adding the other things.
 
-We still need a way to see how many grenades we have left, and we should probably have a way to get more grenades when we pick up ammo.
+We still need a way to show the player how many grenades are left, and we should probably add a way to get more grenades when the player picks up ammo.
 
-First, let's change some of the code in ``Player.gd`` so we can see how many grenades we have left. Change ``process_UI`` to the following:
+First, let's change some of the code in ``Player.gd`` to show how many grenades are left. Change ``process_UI`` to the following:
 
 ::
     
@@ -393,9 +397,9 @@ First, let's change some of the code in ``Player.gd`` so we can see how many gre
             "\nAMMO:" + str(current_weapon.ammo_in_weapon) + "/" + str(current_weapon.spare_ammo) + \
             "\n" + current_grenade + ":" + str(grenade_amounts[current_grenade])
 
-Now we'll show how many grenades we have left in our UI.
+Now we'll show how many grenades the player has left in the UI.
 
-While we're still in ``Player.gd``, let's add a function to add grenades. Add the following function to ``Player.gd``:
+While we're still in ``Player.gd``, let's add a function to add grenades to the player. Add the following function to ``Player.gd``:
 
 ::
     
@@ -408,7 +412,7 @@ Now we can add a grenade using ``add_grenade``, and it will automatically be cla
 .. tip:: You can change the ``4`` to a constant if you want. You'd need to make a new global constant, something like ``MAX_GRENADES``, and
          then change the clamp from ``clamp(grenade_amounts[current_grenade], 0, 4)`` to ``clamp(grenade_amounts[current_grenade], 0, MAX_GRENADES)``
          
-         If you do not want to limit how many grenades you can carry, remove the line that clamps the grenades altogether!
+         If you do not want to limit how many grenades the player can carry, remove the line that clamps the grenades altogether!
 
 Now we have a function to add grenades, let's open up ``AmmoPickup.gd`` and use it!
 
@@ -427,18 +431,18 @@ Open up ``AmmoPickup.gd`` and go to the ``trigger_body_entered`` function. Chang
             respawn_timer = RESPAWN_TIME
             kit_size_change_values(kit_size, false)
 
-Now we're also checking to see if the body has the ``add_grenade`` function. If it does, we call it like we call ``add_ammo``.
+Now we are also checking to see if the body has the ``add_grenade`` function. If it does, we call it like we call ``add_ammo``.
 
-You may have noticed we're using a new constant we haven't defined yet, ``GRENADE_AMOUNTS``. Let's add it! Add the following global variable
-to ``AmmoPickup.gd`` with the other global variables:
+You may have noticed we are using a new constant we have not defined yet, ``GRENADE_AMOUNTS``. Let's add it! Add the following class variable
+to ``AmmoPickup.gd`` with the other class variables:
 
 ::
     
     const GRENADE_AMOUNTS = [2, 0]
     
-* ``GRENADE_AMOUNTS``: The amount of grenades each pick up in each size contains.
+* ``GRENADE_AMOUNTS``: The amount of grenades each pick up contains.
 
-Notice how the second element in ``GRENADE_AMOUNTS`` is ``0``. This is so the small ammo pick up does not give our player
+Notice how the second element in ``GRENADE_AMOUNTS`` is ``0``. This is so the small ammo pick up does not give the player
 any additional grenades.
 
 ______
@@ -449,9 +453,9 @@ Now you should be able to throw grenades now! Go give it a try!
 Adding the ability to grab and throw RigidBody nodes to the player
 ------------------------------------------------------------------
 
-Next let's give our player the ability to pick up and throw :ref:`RigidBody <class_RigidBody>` nodes.
+Next let's give the player the ability to pick up and throw :ref:`RigidBody <class_RigidBody>` nodes.
 
-Open up ``Player.gd`` and add the following global variables:
+Open up ``Player.gd`` and add the following class variables:
 
 ::
     
@@ -461,9 +465,9 @@ Open up ``Player.gd`` and add the following global variables:
     const OBJECT_GRAB_RAY_DISTANCE = 10
 
 * ``grabbed_object``: A variable to hold the grabbed :ref:`RigidBody <class_RigidBody>` node.
-* ``OBJECT_THROW_FORCE``: The force we throw the grabbed object at.
-* ``OBJECT_GRAB_DISTANCE``: The distance away from the camera we hold the grabbed object at.
-* ``OBJECT_GRAB_RAY_DISTANCE``: The distance the :ref:`Raycast <class_Raycast>` goes. This is our grab distance.
+* ``OBJECT_THROW_FORCE``: The force the player throws the grabbed object at.
+* ``OBJECT_GRAB_DISTANCE``: The distance away from the camera the player holds the grabbed object at.
+* ``OBJECT_GRAB_RAY_DISTANCE``: The distance the :ref:`Raycast <class_Raycast>` goes. This is the player's grab distance.
 
 With that done, all we need to do is add some code to ``process_input``:
 
@@ -505,8 +509,8 @@ With that done, all we need to do is add some code to ``process_input``:
 
 Let's go over what's happening.
 
-First we check to see if the action pressed is the ``fire`` action, and that we are using the ``UNARMED`` weapon.
-This is because we only want to be able to pick up and throw objects when we're not using any weapons. This is a design choice,
+First we check to see if the action pressed is the ``fire`` action, and that the player is using the ``UNARMED`` 'weapon'.
+This is because we only want the player to be able to pick up and throw objects when the player is not using any weapons. This is a design choice,
 but I feel it gives ``UNARMED`` a use.
 
 Next we check to see whether or not ``grabbed_object`` is ``null``.
@@ -523,19 +527,20 @@ use a :ref:`Raycast <class_Raycast>` node.
 Then we get the center of the screen by dividing the current :ref:`Viewport <class_Viewport>` size in half. We then get the ray's origin point and end point using
 ``project_ray_origin`` and ``project_ray_normal`` from the camera. If you want to know more about how these functions work, see :ref:`Ray-casting <doc_ray-casting>`.
 
-Next we send our ray into the space state and see if we get a result. We add ourselves and the knife's :ref:`Area <class_Area>` as two exceptions so we cannot carry
-ourselves or the knife's collision area.
+Next we send the ray into the space state and see if it gets a result. We add the player and the knife's :ref:`Area <class_Area>` as two exceptions so the player cannot carry
+themselves or the knife's collision :ref:`Area <class_Area>`.
 
-Then we check to see if we got a result back. If we have, we then see if the collider the ray collided with is a :ref:`RigidBody <class_RigidBody>`.
+Then we check to see if we got a result back from the ray. If we have, we then see if the collider the ray collided with is a :ref:`RigidBody <class_RigidBody>`.
 
 If the ray collided with a :ref:`RigidBody <class_RigidBody>`, we set ``grabbed_object`` to the collider the ray collided with. We then set the mode on
-the :ref:`RigidBody <class_RigidBody>` we collided with to ``MODE_STATIC`` so it's not moved.
+the :ref:`RigidBody <class_RigidBody>` we collided with to ``MODE_STATIC`` so it does not move.
 
-Finally, we set its collision layer and collision mask to ``0``. This will make it have no collision layer or mask, which will means it will not be able to collide with anything.
+Finally, we set the grabbed :ref:`RigidBody <class_RigidBody>`'s collision layer and collision mask to ``0``.
+This will make the grabbed :ref:`RigidBody <class_RigidBody>` have no collision layer or mask, which will means it will not be able to collide with anything.
 
 ______
 
-If ``grabbed_object`` is not ``null``, then we need to throw the :ref:`RigidBody <class_RigidBody>` we're holding.
+If ``grabbed_object`` is not ``null``, then we need to throw the :ref:`RigidBody <class_RigidBody>` the player is holding.
 
 We first set the :ref:`RigidBody <class_RigidBody>` we holding mode to ``MODE_RIGID``.
 
@@ -543,7 +548,7 @@ We first set the :ref:`RigidBody <class_RigidBody>` we holding mode to ``MODE_RI
           that may not be the case in other projects.
           
           If you have :ref:`RigidBody <class_RigidBody>`'s with different modes, you may need to store the mode of the :ref:`RigidBody <class_RigidBody>` you
-          have picked up into a global variable so you can change it back to the mode it was in before you picked it up.
+          have picked up into a class variable so you can change it back to the mode it was in before you picked it up.
   
 Then we apply an impulse to send it flying forward. We send it flying in the direction the camera is facing, at ``OBJECT_THROW_FORCE`` force.
 
@@ -552,21 +557,21 @@ We then set the grabbed :ref:`RigidBody <class_RigidBody>`'s collision layer and
 .. note:: This is, once again, making a rather large assumption that all rigid bodies will be only on collision layer ``1``, and all collision masks will be on layer ``1``.
           If you are using this script in other projects, you may need to store the collision layer/mask of the :ref:`RigidBody <class_RigidBody>` before you change them to ``0``.
 
-Finally, we set ``grabbed_object`` to ``null`` since we have successfully thrown the held object.
+Finally, we set ``grabbed_object`` to ``null`` since the player has successfully thrown the held object.
 
 ______
 
-The last thing we do is check to see whether or not ``grabbed_object`` is equal to ``null``, outside of the grabbing/throwing code.
+The last thing we do is check to see whether or not ``grabbed_object`` is equal to ``null``, outside all of the grabbing/throwing related code.
 
 .. note:: While technically not input related, it's easy enough to place the code moving the grabbed object here
 	      because it's only two lines, and then all of the grabbing/throwing code is in one place
 
-If we are holding an object, we set its global position to the camera's position plus ``OBJECT_GRAB_DISTANCE`` in the direction the camera is facing.
+If the player is holding a object, we set its global position to the camera's position plus ``OBJECT_GRAB_DISTANCE`` in the direction the camera is facing.
 
 ______
 
-Before we test this, we need to change something in ``_physics_process``. While we're holding an object, we don't
-want to be able to change weapons or reload, so change ``_physics_process`` to the following:
+Before we test this, we need to change something in ``_physics_process``. While the player is holding an object, we do not
+want the player to be able to change weapons or reload, so change ``_physics_process`` to the following:
 
 ::
     
@@ -582,23 +587,23 @@ want to be able to change weapons or reload, so change ``_physics_process`` to t
 	# Process the UI
 	process_UI(delta)
 
-Now we cannot change weapons or reload while holding an object.
+Now the player cannot change weapons or reload while holding an object.
     
 Now you can grab and throw RigidBody nodes while in a ``UNARMED`` state! Go give it a try!
 
 Adding a turret
 ---------------
 
-Next, let's make a turret to shoot our player!
+Next, let's make a turret to shoot the player!
 
 Open up ``Turret.tscn``. Expand ``Turret`` if it's not already expanded.
 
-Notice how our turret is broken up into several parts. We have a ``Base``, ``Head``, ``Vision_Area``, and a ``Smoke`` :ref:`Particles <class_Particles>`.
+Notice how the turret is broken up into several parts. We have a ``Base``, ``Head``, ``Vision_Area``, and a ``Smoke`` :ref:`Particles <class_Particles>`.
 
 Open up ``Base`` and you'll find it's a :ref:`StaticBody <class_StaticBody>` and a mesh. Open up ``Head`` and you'll find there's several meshes,
 a :ref:`StaticBody <class_StaticBody>` and a :ref:`Raycast <class_Raycast>` node.
 
-One thing to note with the ``Head`` is that the raycast will be where our bullets will fire from if we are using raycasting. We also have two meshes called
+One thing to note with the ``Head`` is that the raycast will be where the turret's bullets will fire from if we are using raycasting. We also have two meshes called
 ``Flash`` and ``Flash_2``. These will be the muzzle flash that briefly shows when the turret fires.
 
 ``Vision_Area`` is a :ref:`Area <class_Area>` we'll use as the turret's ability to see. When something enters ``Vision_Area``, we'll assume the turret can see it.
@@ -607,7 +612,7 @@ One thing to note with the ``Head`` is that the raycast will be where our bullet
 
 ______
 
-Now that we've looked at how the scene is set up, lets start writting the code for the turret. Select ``Turret`` and create a new script called ``Turret.gd``.
+Now that we've looked at how the scene is set up, lets start writing the code for the turret. Select ``Turret`` and create a new script called ``Turret.gd``.
 Add the following to ``Turret.gd``:
 
 ::
@@ -726,14 +731,14 @@ Add the following to ``Turret.gd``:
             ammo_in_turret -= 1
         
         else:
-            node_raycast.look_at(current_target.global_transform.origin + PLAYER_HEIGHT, Vector3(0,1,0))
+            node_raycast.look_at(current_target.global_transform.origin + Vector3(0, PLAYER_HEIGHT, 0), Vector3(0,1,0))
             
             node_raycast.force_raycast_update()
             
             if node_raycast.is_colliding():
                 var body = node_raycast.get_collider()
                 if body.has_method("bullet_hit"):
-                    body.bullet_hit(TURRET_DAMAGE_RAYCAST, node_raycast.get_collision_point())
+                    body.bullet_hit(TURRET_DAMAGE_RAYCAST, node_raycast.global_transform)
             
             ammo_in_turret -= 1
         
@@ -773,7 +778,7 @@ Add the following to ``Turret.gd``:
             smoke_particles.emitting = true
             destroyed_timer = DESTROYED_TIME
 
-This is quite a bit of code, so let's break it down function by function. Let's first look at the global variables:
+This is quite a bit of code, so let's break it down function by function. Let's first look at the class variables:
 
 * ``use_raycast``: A exported boolean so we can change whether the turret uses objects or raycasting for bullets.
 * ``TURRET_DAMAGE_BULLET``: The amount of damage a single bullet scene does.
@@ -800,7 +805,7 @@ This is quite a bit of code, so let's break it down function by function. Let's
 * ``destroyed_timer``: A variable for tracking the amount of time a turret has been destroyed.
 * ``bullet_scene``: The bullet scene the turret fires (same scene as the player's pistol)
 
-Phew, that's quite a few global variables!
+Phew, that's quite a few class variables!
 
 ______
 
@@ -812,9 +817,9 @@ We then get all of the nodes and assign them to their respective variables.
 
 Next add some exceptions to the :ref:`Raycast <class_Raycast>` so the turret cannot hurt itself.
 
-Then we make both flash meshes invisible to start, since we're not going to be firing during ``_ready``.
+Then we make both flash meshes invisible to start, since we are not going to be firing during ``_ready``.
 
-We then get the smoke particles node and assign it to the ``smoke_particles`` node. We also set ``emitting`` to ``false`` to assure it's
+We then get the smoke particles node and assign it to the ``smoke_particles`` node. We also set ``emitting`` to ``false`` to assure the particles are
 not emitting until the turret is broken.
 
 Finally, we set the turret's health to ``MAX_TURRET_HEALTH`` so it starts at full health.
@@ -829,19 +834,19 @@ Next we check to see if ``flash_timer`` is more than zero, meaning the flash mes
 delta from ``flash_timer``. If ``flash_timer`` gets to zero or less after we've subtracted ``delta``, we want to hide
 both of the flash meshes.
 
-Next we check to see if we have a target or not. If we have a target, we make the turret head look at it, adding ``PLAYER_HEIGHT`` so we're not
+Next we check to see if the turret has a target or not. If the turret has a target, we make the turret head look at it, adding ``PLAYER_HEIGHT`` so it is not
 aiming at the player's feet.
 
 We then check to see if the turret's health is more than zero. If it is, we then check to see if there is ammo in the turret.
 
-If there is ammo in the turret, we then check to see if ``fire_timer`` is more than zero. If ``fire_timer`` is more than zero, we cannot fire and need to
-remove ``delta`` from ``fire_timer``. If ``fire_timer`` is equal to or less than zero, we want to fire a bullet, so we call the ``fire_bullet`` function.
+If there is ammo in the turret, we then check to see if ``fire_timer`` is more than zero. If ``fire_timer`` is more than zero, the turret cannot fire and we need to
+remove ``delta`` from ``fire_timer``. If ``fire_timer`` is equal to or less than zero, the turret can fire a bullet, so we call the ``fire_bullet`` function.
 
 If there is not any ammo in the turret, we check to see if ``ammo_reload_timer`` is more than zero. If ``ammo_reload_timer`` is more than zero,
 we subtract ``delta`` from ``ammo_reload_timer``. If ``ammo_reload_timer`` is equal to or less than zero, we set ``ammo_in_turret`` to ``AMMO_IN_FULL_TURRET`` because
-we've waited long enough to refill the turret.
+the turret has waited long enough to refill its ammo.
 
-Next we check to see if the turret's health is less than or equal to ``0``, outside of whether we're active or not. If the turret's health is zero or less, we then
+Next we check to see if the turret's health is less than or equal to ``0``, outside of whether it is active or not. If the turret's health is zero or less, we then
 check to see if ``destroyed_timer`` is more than zero. If destroyed timer is more than zero, we subtract ``delta`` from ``destroyed_timer``.
 
 If ``destyored_timer`` is less than or equal to zero, we set ``turret_health`` to ``MAX_TURRET_HEALTH`` and stop emitting smoke particles by setting ``smoke_particles.emitting`` to
@@ -851,35 +856,35 @@ ______
 
 Next let's go through ``fire_bullet``.
 
-First we check to see whether we're using a raycast or not.
+First we check to see whether the turret is using a raycast or not.
 
 The code for the using a raycast is almost entirely the same as the code in the rifle from :ref:`doc_fps_tutorial_part_two`, so
 I'm only going to go over it briefly.
 
-We first make the raycast look at the target, assuring we'll hit the target. We then force the raycast to update so we get a frame
+We first make the raycast look at the target, assuring the raycast will hit the target if nothing is in the way. We then force the raycast to update so we get a frame
 perfect collision check. We then check if the raycast collided with anything. If the raycast has collided with something, we then check
-to see if the collided body has the ``bullet_hit`` function. If it does, we call it and pass in the damage a single raycast bullet does. We then remove
-``1`` from ``ammo_in_turret``.
+to see if the collided body has the ``bullet_hit`` function. If it does, we call it and pass in the damage a single raycast bullet does along with the raycast's transform.
+We then remove ``1`` from ``ammo_in_turret``.
 
-If we are not using a raycast, we spawn a bullet object instead. This code is almost entirely the same as the code in the pistol from :ref:`doc_fps_tutorial_part_two`, so
+If the turret is not using a raycast, we spawn a bullet object instead. This code is almost entirely the same as the code in the pistol from :ref:`doc_fps_tutorial_part_two`, so
 like with the raycast code, I'm only going to go over it briefly.
 
-We first make a bullet clone and assign it to ``clone``. We then add that as a child of the root node. We set it's global transform to
-the barrel end, scale it up since it's too small, and set it's damage and speed using the turret's constant global variables. We then remove ``1`` from
+We first make a bullet clone and assign it to ``clone``. We then add that as a child of the root node. We set the bullet's global transform to
+the barrel end, scale it up since it's too small, and set it's damage and speed using the turret's constant class variables. We then remove ``1`` from
 ``ammo_in_turret``.
 
 Then, regardless of which bullet method we used, we make both of the muzzle flash meshes visible. We set ``flash_timer`` and ``fire_timer`` to
-to ``FLASH_TIME`` and ``FIRE_TIME`` respectively. We then check to see if we used the last bullet in the turret. If we have used the last bullet,
-we set ``ammo_reload_timer`` to ``AMMO_RELOAD_TIME``.
+to ``FLASH_TIME`` and ``FIRE_TIME`` respectively. We then check to see if the turret used the last bullet in its ammo. If the turret has used the last bullet,
+we set ``ammo_reload_timer`` to ``AMMO_RELOAD_TIME`` so the turret reloads.
 
 ______
 
-Let's look at ``body_entered_vision`` next, and thankfully it's rather short.
+Let's look at ``body_entered_vision`` next, and thankfully it is rather short.
 
-We first check to see if we currently have a target by checking to see if ``current_target`` is equal to ``null``.
-If we do not have a target, we then check to see if the body that just entered the vision :ref:`Area <class_Area>` is a :ref:`KinematicBody <class_KinematicBody>`
+We first check to see if the turret currently has a target by checking to see if ``current_target`` is equal to ``null``.
+If the turret does not have a target, we then check to see if the body that just entered the vision :ref:`Area <class_Area>` is a :ref:`KinematicBody <class_KinematicBody>`
 
-..note:: We're assuming the turret only should fire at :ref:`KinematicBody <class_KinematicBody>` nodes, since that's what our player(s) are using.
+..note:: We're assuming the turret should only should fire at :ref:`KinematicBody <class_KinematicBody>` nodes, since that is what the player is using.
 
 If the body that just the vision :ref:`Area <class_Area>` is a :ref:`KinematicBody <class_KinematicBody>`, we set ``current_target`` to the body, and set ``is_active`` to
 ``true``.
@@ -888,25 +893,25 @@ ______
 
 Now let's look at ``body_exited_vision``.
 
-First we check to see if we have a target. If we have a target, we then check to see if the body that has just left our vision area
-is our target.
+First we check to see if the turret has a target. If the turret has a target, we then check to see if the body that has just left the turret's vision area
+is the turret's target.
 
-If the body that just left the area is the current target, we set ``current_target`` to ``null``, set ``is_active`` to ``false``, and reset
-all of the variables related to firing the turret, since we no longer have a target to fire at.
+If the body that just left the area is the turret's current target, we set ``current_target`` to ``null``, set ``is_active`` to ``false``, and reset
+all of the variables related to firing the turret, since the turret no longer has a target to fire at.
 
 ______
 
 Finally, let's look at ``bullet_hit``.
 
-We first remove however much damage we have received from the turret's health.
+We first remove however much damage the bullet causes from the turret's health.
 
-Then we check to see if we've been destroyed. If we have, we start the smoke particles emitting and set ``destroyed_timer`` to ``DESTROYED_TIME`` so we
-have to wait to repair the turret.
+Then we check to see if the turret has been destroyed (health being zero or less).
+If the turret is destroyed, we start the smoke particles emitting and set ``destroyed_timer`` to ``DESTROYED_TIME`` so the turret has to wait before being repaired.
 
 ______
 
-Phew, with all of that done and coded we only have one last thing to do before our turrets are ready for use. Open up ``Turret.tscn`` if it's not already open and
-select one of the :ref:`StaticBody <class_StaticBody>` nodes from either ``Body`` or ``Head``. Create a new script called ``TurretBodies.gd`` and attach it to whichever
+Phew, with all of that done and coded we only have one last thing to do before the turret is ready for use. Open up ``Turret.tscn`` if it's not already open and
+select one of the :ref:`StaticBody <class_StaticBody>` nodes from either ``Base`` or ``Head``. Create a new script called ``TurretBodies.gd`` and attach it to whichever
 :ref:`StaticBody <class_StaticBody>` you have selected.
 
 Add the following code to ``TurretBodies.gd``:
@@ -932,7 +937,7 @@ attached, assign the :ref:`NodePath <class_NodePath>` to the ``Turret`` node.
 
 ______
 
-The last thing we need to do is add a way for the player to be hurt. Since all of our bullets use the ``bullet_hit`` function, we need to add that to our player.
+The last thing we need to do is add a way for the player to be hurt. Since all of the bullets use the ``bullet_hit`` function, we need to add that function to the player.
 
 Open ``Player.gd`` and add the following:
 
@@ -948,7 +953,7 @@ Final notes
 
 .. image:: img/PartFiveFinished.png
 
-Now you the player can pick up :ref:`RigidBody <class_RigidBody>` nodes and throw grenades. We now also have turrets to fire at our player.
+Now you the player can pick up :ref:`RigidBody <class_RigidBody>` nodes and throw grenades. We now also have turrets to fire at the player.
 
 In :ref:`doc_fps_tutorial_part_six`, we're going to add a main menu and pause menu,
 add a respawn system for the player, and change/move the sound system so we can use it from any script.

tutorials/3d/fps_tutorial/part_four.rst

@@ -6,7 +6,7 @@ Part 4
 Part Overview
 -------------
 
-In this part we will be adding health pick ups, ammo pick ups, targets we can destroy, add support for joypads, and add the ability to change weapons with the scroll wheel.
+In this part we will be adding health pick ups, ammo pick ups, targets the player can destroy, support for joypads, and add the ability to change weapons with the scroll wheel.
 
 .. image:: img/PartFourFinished.png
 
@@ -20,7 +20,7 @@ Adding joypad input
 -------------------
 
 .. note:: In Godot any game controller is referred to as a joypad. This includes:
-          Console controllers, Joysticks (like for flight simulators), Wheels (like for driving simulators), VR Controllers, and more.
+          Console controllers, Joysticks (like for flight simulators), Wheels (like for driving simulators), VR Controllers, and more!
 
 First we need to change a few things in our project's input map. Open up the project settings and select the ``Input Map`` tab.
 
@@ -46,7 +46,7 @@ ______
 
 Now let's open up ``Player.gd`` and add joypad input.
 
-First, we need to define a few new global variables. Add the following global variables to ``Player.gd``:
+First, we need to define a few new class variables. Add the following class variables to ``Player.gd``:
 
 ::
     
@@ -56,11 +56,11 @@ First, we need to define a few new global variables. Add the following global va
 
 Let's go over what each of these do:
 
-* ``JOYPAD_SENSITIVITY``: This is how fast our joypad joysticks will move our camera.
+* ``JOYPAD_SENSITIVITY``: This is how fast the joypad's joysticks will move the camera.
 * ``JOYPAD_DEADZONE``: The dead zone for the joypad. You may need to adjust depending on your joypad.
 
 .. note::  Many joypads jitter around a certain point. To counter this, we ignore any movement in a
-           with a radius of JOYPAD_DEADZONE. If we did not ignore said movement, the camera will jitter.
+           with a radius of JOYPAD_DEADZONE. If we did not ignore said movement, the camera would jitter.
            
            Also, we are defining ``JOYPAD_SENSITIVITY`` as a variable instead of a constant because we'll later be changing it.
 
@@ -96,12 +96,12 @@ Let's go over what we're doing.
 First we check to see if there is a connected joypad.
 
 If there is a joypad connected, we then get its left stick axes for right/left and up/down.
-Because a wired Xbox 360 controller has different joystick axis mapping based on OS, we use different axes based on
+Because a wired Xbox 360 controller has different joystick axis mapping based on OS, we will use different axes based on
 the OS.
 
 .. warning:: This tutorial assumes you are using a XBox 360 wired controller.
              Also, I do not (currently) have access to a Mac computer, so the joystick axes may need changing.
-             If they do, please open a GitHub issue on the Godot documentation repository!
+             If they do, please open a GitHub issue on the Godot documentation repository! Thanks!
 
 Next we check to see if the joypad vector length is within the ``JOYPAD_DEADZONE`` radius.
 If it is, we set ``joypad_vec`` to an empty Vector2. If it is not, we use a scaled Radial Dead zone for precise dead zone calculating.
@@ -114,8 +114,8 @@ If it is, we set ``joypad_vec`` to an empty Vector2. If it is not, we use a scal
 
 Finally, we add ``joypad_vec`` to ``input_movement_vector``.
 
-.. tip:: Remember how we normalize ``input_movement_vector``? This is why! If we did not normalize ``input_movement_vector`` players could
-         move faster if they are pushing in the same direction with both their keyboard and their joypad!
+.. tip:: Remember how we normalize ``input_movement_vector``? This is why! If we did not normalize ``input_movement_vector``, the player could
+         move faster if the player pushes in the same direction with both the keyboard and the joypad!
          
 ______
 
@@ -167,37 +167,37 @@ Next we define a new :ref:`Vector2 <class_Vector2>` called ``joypad_vec``. This
 it is mapped to the proper axes for the right joystick.
 
 .. warning:: As stated above, I do not (currently) has access to a Mac computer, so the joystick axes may need changing. If they do,
-             please open a GitHub issue on the Godot documentation repository!
+             please open a GitHub issue on the Godot documentation repository! Thanks!
 
 We then account for the joypad's dead zone, exactly like in ``process_input``.
 
-Then we rotate ``rotation_helper`` and our KinematicBody using ``joypad_vec``.
+Then we rotate ``rotation_helper`` and the player's :ref:`KinematicBody <class_KinematicBody>` using ``joypad_vec``.
 
-Notice how the code that handles rotating ourselves and ``rotation_helper`` is exactly the same as the
+Notice how the code that handles rotating the player and ``rotation_helper`` is exactly the same as the
 code in ``_input``. All we've done is change the values to use ``joypad_vec`` and ``JOYPAD_SENSITIVITY``.
 
 .. note:: Due to few mouse related bugs on Windows, we cannot put mouse rotation in ``process_view`` as well.
-          Once these bugs are fixed, this will likely be updated to place the mouse rotation here as well.
+          Once these bugs are fixed, this will likely be updated to place the mouse rotation here in ``process_view_input`` as well.
 
-Finally, we clamp the camera's rotation so we cannot look upside down.
+Finally, we clamp the camera's rotation so the player cannot look upside down.
 
 ______
 
-The last thing you need to do is add ``process_view_input`` to ``_physics_process``.
+The last thing we need to do is add ``process_view_input`` to ``_physics_process``.
 
 Once ``process_view_input`` is added to ``_physics_process``, you should be able to play using a joypad!
 
-.. note:: I decided not to use the joypad triggers for firing because we'd then have to do some more axis managing, and because I prefer to use a shoulder button to fire.
+.. note:: I decided not to use the joypad triggers for firing because we'd then have to do some more axis managing, and because I prefer to use a shoulder buttons to fire.
           
-          If you want to use the triggers for firing, you will need to change how firing works in ``process_input``. You need to get the proper axis value for the trigger,
+          If you want to use the triggers for firing, you will need to change how firing works in ``process_input``. You need to get the axis values for the triggers,
           and check if it's over a certain value, say ``0.8`` for example. If it is, you add the same code as when the ``fire`` action was pressed.
          
 Adding mouse scroll wheel input
 -------------------------------
 
-Let's add one input related feature before we start working on the pick ups and target. Let's add the ability to change weapons using the scroll wheel on the mouse.
+Let's add one more input related feature before we start working on the pick ups and the target. Let's add the ability to change weapons using the scroll wheel on the mouse.
 
-Open up ``Player.gd`` and add the following global variables:
+Open up ``Player.gd`` and add the following class variables:
 
 ::
     
@@ -235,21 +235,21 @@ Now let's add the following to ``_input``:
                         
 Let's go over what's happening here:
 
-First we check if the event is a ``InputEventMouseButton`` event and that our mouse mode is ``MOUSE_MODE_CAPTURED``.
+First we check if the event is a ``InputEventMouseButton`` event and that the mouse mode is ``MOUSE_MODE_CAPTURED``.
 Then we check to see if the button index is either a ``BUTTON_WHEEL_UP`` or ``BUTTON_WHEEL_DOWN`` index.
 
 If the event's index is indeed a button wheel index, we then check to see if it is a ``BUTTON_WHEEL_UP`` or ``BUTTON_WHEEL_DOWN`` index.
-Based on whether it is up or down we add/remove ``MOUSE_SENSITIVITY_SCROLL_WHEEL`` to/from ``mouse_scroll_value``.
+Based on whether it is up or down we add or remove ``MOUSE_SENSITIVITY_SCROLL_WHEEL`` to/from ``mouse_scroll_value``.
 
-Next we clamp mouse scroll value to assure it is inside the range of our weapons.
+Next we clamp mouse scroll value to assure it is inside the range of selectable weapons.
 
-We then check to see if we are changing weapons or reloading. If we are doing neither, we round ``mouse_scroll_value`` and cast it to a ``int``.
+We then check to see if the player is changing weapons or reloading. If the player is doing neither, we round ``mouse_scroll_value`` and cast it to a ``int``.
 
 .. note:: We are casting ``mouse_scroll_value`` to a ``int`` so we can use it as a key in our dictionary. If we left it as a float,
           we would get an error when we try to run the project.
 
 Next we check to see if the weapon name at ``round_mouse_scroll_value`` is not equal to the current weapon name using ``weapon_number_to_name``.
-If the weapon is different than our current weapon, we assign ``changing_weapon_name``, set ``changing_weapon`` to true so we will change weapons in
+If the weapon is different than the player's current weapon, we assign ``changing_weapon_name``, set ``changing_weapon`` to ``true`` so the player will change weapons in
 ``process_changing_weapon``, and set ``mouse_scroll_value`` to ``round_mouse_scroll_value``.
 
 .. tip:: The reason we are setting ``mouse_scroll_value`` to the rounded scroll value is because we do not want the player to keep their
@@ -264,7 +264,7 @@ One more thing we need to change is in ``process_input``. In the code for changi
     
     mouse_scroll_value = weapon_change_number
     
-Now our scroll value we be changed with the keyboard input. If we did not change this, our scroll value will be out of sync. If the scroll wheel is out of
+Now the scroll value will be changed with the keyboard input. If we did not change this, the scroll value will be out of sync. If the scroll wheel is out of
 sync, scrolling forwards or backwards would not transition to the next/last weapon, but rather the next/last weapon the scroll wheel changed to.
 
 ______
@@ -274,7 +274,7 @@ Now you can change weapons using the scroll wheel! Go give it a whirl!
 Adding the health pick ups
 --------------------------
 
-Now that our player has health and ammo, we ideally need a way to replenish those resources.
+Now that the player has health and ammo, we ideally need a way to replenish those resources.
 
 Open up ``Health_Pickup.tscn``.
 
@@ -348,7 +348,7 @@ Select ``Health_Pickup`` and add a new script called ``Health_Pickup.gd``. Add t
             respawn_timer = RESPAWN_TIME
             kit_size_change_values(kit_size, false)
 
-Let's go over what this script is doing, starting with its global variables:
+Let's go over what this script is doing, starting with its class variables:
 
 * ``kit_size``: The size of the health pick up. Notice how we're using a ``setget`` function to tell if it's changed.
 * ``HEALTH_AMMOUNTS``: The amount of health each pick up in each size contains.
@@ -360,7 +360,7 @@ We're using ``is_ready`` because ``setget`` functions are called before ``_ready
 first kit_size_change call, because we cannot access child nodes until ``_ready`` is called. If we did not ignore the
 first ``setget`` call, we would get several errors in the debugger.
 
-Also, notice how we're using a exported variable. This is so we can change the size of the health pick up in the editor, for each pick up. This makes it where
+Also, notice how we are using a exported variable. This is so we can change the size of the health pick ups in the editor. This makes it where
 we do not have to make two scenes for the two sizes, since we can easily change sizes in the editor using the exported variable.
 
 .. tip:: See :ref:`doc_GDScript` and scroll down to the Exports section for a list of of export hints you can use.
@@ -369,10 +369,10 @@ ______
 
 Let's look at ``_ready``:
 
-First we connect the ``body_entered`` signal from our ``Health_Pickup_Trigger`` to the ``trigger_body_entered`` function. This makes is where any
+First we connect the ``body_entered`` signal from the ``Health_Pickup_Trigger`` to the ``trigger_body_entered`` function. This makes is where any
 body that enters the :ref:`Area <class_Area>` triggers the ``trigger_body_entered`` function.
 
-Next we set ``is_ready`` to ``true`` so we can use our ``setget`` function.
+Next we set ``is_ready`` to ``true`` so we can use the ``setget`` function.
 
 Then we hide all of the possible kits and their collision shapes using ``kit_size_change_values``. The first argument is the size of the kit, while the second argument
 is whether to enable or disable the collision shape and mesh at that size.
@@ -385,10 +385,10 @@ Next let's look at ``kit_size_changed``.
 
 The first thing we do is check to see if ``is_ready`` is ``true``.
 
-If ``is_ready`` is ``true``, we then make whatever kit is currently assigned to ``kit_size`` disabled using ``kit_size_change_values``, passing in ``kit_size`` and ``false``.
+If ``is_ready`` is ``true``, we then make whatever kit already assigned to ``kit_size`` disabled using ``kit_size_change_values``, passing in ``kit_size`` and ``false``.
 
 Then we assign ``kit_size`` to the new value passed in, ``value``. Then we call ``kit_size_change_values`` passing in ``kit_size`` again, but this time
-with the second argument as ``true`` so we enable it. Because we changed ``kit_size`` to the passed in value, this will make whatever kit size we passed in visible.
+with the second argument as ``true`` so we enable it. Because we changed ``kit_size`` to the passed in value, this will make whatever kit size was passed in visible.
 
 If ``is_ready`` is not ``true``, we simply assign ``kit_size`` to the passed in ``value``.
 
@@ -396,7 +396,7 @@ ______
 
 Now let's look at ``kit_size_change_values``.
 
-The first thing we do is check to see which size we're using. Based on which size we're wanting to enable/disable, we want to get different nodes.
+The first thing we do is check to see which size was passed in. Based on which size we're wanting to enable/disable, we want to get different nodes.
 
 We get the collision shape for the node corresponding to ``size`` and disable it based on the ``enabled`` passed in argument/variable.
 
@@ -416,14 +416,14 @@ Finally, let's look at ``trigger_body_entered``.
 The first thing we do is see whether or not the body that just entered has a method/function called ``add_health``. If it does, we then
 call ``add_health`` and pass in the health provided by the current kit size.
 
-Then we set ``respawn_timer`` to ``RESPAWN_TIME`` so we have to wait before we can get health again. Finally, call ``kit_size_change_values``,
-passing in ``kit_size`` and ``false`` so the kit at ``kit_size`` is invisible until we've waited long enough to respawn.
+Then we set ``respawn_timer`` to ``RESPAWN_TIME`` so the player has to wait before the player can get health again. Finally, call ``kit_size_change_values``,
+passing in ``kit_size`` and ``false`` so the kit at ``kit_size`` is invisible until it has waited long enough to respawn.
 
 _______
 
-The last thing we need to do before we can use this health pick up is add a few things to our player.
+The last thing we need to do before the player can use this health pick up is add a few things to ``Player.gd``.
 
-Open up ``Player.gd`` and add the following global variable:
+Open up ``Player.gd`` and add the following class variable:
 
 ::
     
@@ -431,7 +431,7 @@ Open up ``Player.gd`` and add the following global variable:
     
 * ``MAX_HEALTH``: The maximum amount of health a player can have.
 
-Now we need to add the ``add_health`` function to our player. Add the following to ``Player.gd``:
+Now we need to add the ``add_health`` function to the player. Add the following to ``Player.gd``:
 
 ::
     
@@ -441,18 +441,18 @@ Now we need to add the ``add_health`` function to our player. Add the following
 
 Let's quickly go over what this does.
 
-We first add ``additional_health`` to our current health. We then clamp the health so that it cannot exceed a value higher than ``MAX_HEALTH``, nor a value lower
+We first add ``additional_health`` to the player's current health. We then clamp the health so that it cannot exceed a value higher than ``MAX_HEALTH``, nor a value lower
 than ``0``.
 
 _______
 
-With that done, now we can collect health! Go place a few ``Health_Pickup`` scenes around and give it a try. You can change the size of the health pick up in the editor
+With that done, the player can now collect health! Go place a few ``Health_Pickup`` scenes around and give it a try. You can change the size of the health pick up in the editor
 when a ``Health_Pickup`` instanced scene is selected, from a convenient drop down.
 
 Adding the ammo pick ups
 ------------------------
 
-While adding health is good and all, we can't reap the rewards from it since nothing can (currently) damage us.
+While adding health is good and all, we can't reap the rewards from adding it since nothing can (currently) damage us.
 Let's add some ammo pick ups next!
 
 Open up ``Ammo_Pickup.tscn``. Notice how it's structured exactly the same as ``Health_Pickup.tscn``, but with the meshes and trigger collision shapes changed slightly to adjust
@@ -522,16 +522,16 @@ Select ``Ammo_Pickup`` and add a new script called ``Ammo_Pickup.gd``. Add the f
 You may have noticed this code looks almost exactly the same as the health pick up. That's because it largely is the same! Only a few things
 have been changed, and that's what we're going to go over.
 
-First, notice how we have ``AMMO_AMOUNTS`` instead of ``HEALTH_AMMOUNTS``. ``AMMO_AMOUNTS`` will be how many ammo clips/magazines we add to the current weapon.
+First, notice how there is ``AMMO_AMOUNTS`` instead of ``HEALTH_AMMOUNTS``. ``AMMO_AMOUNTS`` will be how many ammo clips/magazines the pick up add to the current weapon.
 (Unlike ``HEALTH_AMMOUNTS`` which was how many health points, we instead add an entire clip for the current weapon, instead of the raw ammo amount)
 
-The only other thing to notice is in ``trigger_body_entered`` we're checking and calling a function called ``add_ammo``, not ``add_health``.
+The only other thing to notice is in ``trigger_body_entered``. We're checking and calling a function called ``add_ammo`` instead of ``add_health``.
 
-Other than those two small changes, everything else is exactly the same as the health pickup!
+Other than those two small changes, everything else is exactly the same as the health pick up!
 
 _______
 
-All we need to do make the ammo pick ups work is add a new function to our player. Open ``Player.gd`` and add the following function:
+All we need to do make the ammo pick ups work is add a new function to the player. Open ``Player.gd`` and add the following function:
 
 ::
     
@@ -542,7 +542,7 @@ All we need to do make the ammo pick ups work is add a new function to our playe
 
 Let's go over what this function does.
 
-The first thing we check is to see whether we're using ``UNARMED`` or not. Because ``UNARMED`` does not have a node/script, we want to make sure we're not using
+The first thing we check is to see whether the player is using ``UNARMED`` or not. Because ``UNARMED`` does not have a node/script, we want to make sure the player is not using
 ``UNARMED`` before trying to get the node/script attached to ``current_weapon_name``.
 
 Next we check to see if the current weapon can be refilled. If the current weapon can, we add a full clip/magazine worth of ammo to the weapon by
@@ -576,9 +576,9 @@ and needs to be destroyed. Then we're going to hide the non-broken target, so it
 spawned/instanced.
 
 While you still have ``Broken_Target.tscn`` open, attach ``RigidBody_hit_test.gd`` to all of the :ref:`RigidBody <class_RigidBody>` nodes. This will make
-it where we can shoot at the broken pieces and they will react to the bullets.
+it where the player can shoot at the broken pieces and they will react to the bullets.
 
-Alright, now switch back to ``Target.tscn``, select the ``Target`` :ref:`StaticBody <class_StaticBody>` node and created a new script called ``Target.gd``.
+Alright, now switch back to ``Target.tscn``, select the ``Target`` :ref:`StaticBody <class_StaticBody>` node and create a new script called ``Target.gd``.
 
 Add the following code to ``Target.gd``:
 
@@ -619,7 +619,7 @@ Add the following code to ``Target.gd``:
                 current_health = TARGET_HEALTH
 
 
-    func bullet_hit(damage, bullet_hit_pos):
+    func bullet_hit(damage, bullet_transform):
         current_health -= damage
         
         if current_health <= 0:
@@ -638,7 +638,7 @@ Add the following code to ``Target.gd``:
             target_collision_shape.disabled = true
             visible = false
 
-Let's go over what this script does, starting with the global variables:
+Let's go over what this script does, starting with the class variables:
 
 * ``TARGET_HEALTH``: The amount of damage needed to break a fully healed target.
 * ``current_health``: The amount of health this target currently has.
@@ -648,8 +648,8 @@ Let's go over what this script does, starting with the global variables:
 * ``target_respawn_timer``: A variable to track how long a target has been broken.
 * ``destroyed_target``: A :ref:`PackedScene <class_PackedScene>` to hold the broken target scene.
 
-Notice how we're using an exported variable (a :ref:`PackedScene <class_PackedScene>`) to get the broken target scene instead of
-using ``preload``. By using an exported variable, we can chose the scene from the editor, and when/if we need to use a different scene,
+Notice how we're using a exported variable (a :ref:`PackedScene <class_PackedScene>`) to get the broken target scene instead of
+using ``preload``. By using an exported variable, we can chose the scene from the editor, and if we need to use a different scene,
 it's as easy as selecting a different scene in the editor, we don't need to go to the code to change the scene we're using.
 
 ______
@@ -675,42 +675,42 @@ We're only going to be using ``_physics_process`` for respawning, and so the fir
 If it is, we then remove ``delta`` from it.
 
 Then we check to see if ``target_respawn_timer`` is ``0`` or less. The reason behind this is since we just removed ``delta`` from ``target_respawn_timer``, if it's
-``0`` or less then we've just got here, effectively allowing us to do whatever we need to do when the timer is finished.
+``0`` or less then the target just got here, effectively allowing us to do whatever we need to do when the timer is finished.
 
-In this case, we want to respawn our target.
+In this case, we want to respawn the target.
 
-The first thing we do is remove all children in the broken target holder. We do this by iterating over all of the children in ``broken_target_holder`` and free them.
+The first thing we do is remove all children in the broken target holder. We do this by iterating over all of the children in ``broken_target_holder`` and free them using ``queue_free``.
 
-Next we enable our collision shape by setting its ``disabled`` boolean to ``false``.
+Next we enable the collision shape by setting its ``disabled`` boolean to ``false``.
 
-Then we make ourselves, and all of our children nodes, visible.
+Then we make the target, and all of it's children nodes, visible again.
 
-Finally, we reset ``current_health`` to ``TARGET_HEALTH``.
+Finally, we reset the target's health (``current_health``) to ``TARGET_HEALTH``.
 
 ______
 
 Finally, let's look at ``bullet_hit``.
 
-The first the we do is remove however much damage the bullet does from our health.
+The first the we do is remove however much damage the bullet does from the target's health.
 
-Next we check to see if we're at ``0`` health or lower. If we are, then we've just died and need to spawn a broken target.
+Next we check to see if the target is at ``0`` health or lower. If it is, the target has just died and we need to spawn a broken target.
 
 We first instance a new destroyed target scene, and assign it to a new variable, ``clone``.
 
-Next we add ``clone`` as a child of our broken target holder.
+Next we add ``clone`` as a child of the broken target holder.
 
-For an added bonus, we want to make all of the target pieces explode outwards. Do to this, we iterate over all of the children in ``clone``.
+For bonus effect, we want to make all of the target pieces explode outwards. To do this, we iterate over all of the children in ``clone``.
 
 For each child, we first check to see if it's a :ref:`RigidBody <class_RigidBody>` node. If it is, we then calculate the center position of the target relative
-to the child node. Then we figure out which direction we are relative to the center. Using those calculated variables, we push the child from the calculated center,
+to the child node. Then we figure out which direction the child node is relative to the center. Using those calculated variables, we push the child from the calculated center,
 in the direction away from the center, using the damage of the bullet as the force.
 
 .. note:: We multiply the damage by ``12`` so it has a more dramatic effect. You can change this to a higher or lower value depending on how explosive you want
           your targets to shatter.
 
-Next we set our respawn timer for our non-broken target. We set it to ``TARGET_RESPAWN_TIME``, so it takes ``TARGET_RESPAWN_TIME`` many seconds to respawn.
+Next we set the target's respawn timer. We set the timer to ``TARGET_RESPAWN_TIME``, so it takes ``TARGET_RESPAWN_TIME`` many seconds for the target to respawn.
 
-Then we disable the non-broken target's collision shape, and set our visibility to ``false``.
+Then we disable the non-broken target's collision shape, and set the target's visibility to ``false``.
 
 ______
 

tutorials/3d/fps_tutorial/part_one.rst

@@ -90,7 +90,7 @@ _________
 
 Let's take a second to see what we have in the starter assets.
 
-Included in the starter assets are several scenes. For example, in `res://` we have 14 scenes, most of which we will be visiting as
+Included in the starter assets are several scenes. For example, in ``res://`` we have 14 scenes, most of which we will be visiting as
 we go through this tutorial series.
 
 For now let's open up ``Player.tscn``.
@@ -251,14 +251,13 @@ This is a lot of code, so let's break it down function by function:
 
 _________
 
-First, we define some global variables to dictate how our player will move about the world.
+First, we define some class variables to dictate how our player will move about the world.
 
 .. note:: Throughout this tutorial, **variables defined outside functions will be
-          referred to as "global variables"**. This is because we can access any of these
-          variables from any place in the script. We can "globally" access them, hence the
-          name.
+          referred to as "class variables"**. This is because we can access any of these
+          variables from any place in the script.
 
-Let's go through each of the global variables:
+Let's go through each of the class variables:
 
 - ``GRAV``: How strong gravity pulls us down.
 - ``vel``: Our :ref:`KinematicBody <class_KinematicBody>`'s velocity.
@@ -330,7 +329,7 @@ World space can be defined as: The space in which all objects are placed in, rel
 Every object, no matter if it is 2D or 3D, has a position in world space.
 
 To put it another way: world space is the space in a universe where every object's position, rotation, and scale
-can be measured by a known, fixed point called the origin.
+can be measured by a single, known, fixed point called the origin.
 
 In Godot, the origin is at position ``(0, 0, 0)`` with a rotation of ``(0, 0, 0)`` and a scale of ``(1, 1, 1)``.
 
@@ -433,8 +432,8 @@ Based on which directional movement action is pressed, we add or remove from ``i
 After we've checked each of the directional movement actions, we normalize ``input_movement_vector``. This makes it where ``input_movement_vector``'s values
 are within a ``1`` radius unit circle.
 
-Next we add the camera's local ``Z`` vector times ``input_movement_vector.y`` to ``dir``. This where when we pressed forward or backwards we add the camera's
-local ``Z`` axis, so we move forward in relation to the camera.
+Next we add the camera's local ``Z`` vector times ``input_movement_vector.y`` to ``dir``. This is so when the player presses forward or backwards, we add the camera's
+local ``Z`` axis so the player moves forward or backwards in relation to the camera.
 
 .. note:: Because the camera is rotated by ``-180`` degrees, we have to flip the ``Z`` directional vector.
           Normally forward would be the positive Z axis, so using ``basis.z.normalized()`` would work,
@@ -442,19 +441,19 @@ local ``Z`` axis, so we move forward in relation to the camera.
           to the rest of the player.
 
 We do the same thing for the camera's local ``X`` vector, and instead of using ``input_movement_vector.y`` we instead use ``input_movement_vector.x``.
-This makes it where when we press left or right, we move left/right in relation to the camera.
+This makes it where the player moves left/right in relation to the camera when the player presses left/right.
 
 Next we check if the player is on the floor using :ref:`KinematicBody <class_KinematicBody>`'s ``is_on_floor`` function. If it is, then we
-check to see if the "movement_jump" action has just been pressed. If it has, then we set our ``Y`` velocity to
+check to see if the "movement_jump" action has just been pressed. If it has, then we set the player's ``Y`` velocity to
 ``JUMP_SPEED``.
 
-Because we're setting the Y velocity, we will jump into the air.
+Because we're setting the Y velocity, the player will jump into the air.
 
 Then we check for the ``ui_cancel`` action. This is so we can free/capture the mouse cursor when the ``escape`` button
 is pressed. We do this because otherwise we'd have no way to free the cursor, meaning it would be stuck until you terminate the
 runtime.
 
-To free/capture the cursor, we check to see if the mouse is visible (freed) or not. If it is, then we capture it, and if it's not we make it visible (free it).
+To free/capture the cursor, we check to see if the mouse is visible (freed) or not. If it is, we capture it, and if it's not we make it visible (free it).
 
 That's all we're doing right now for ``process_input``. We'll come back several times to this function as we add more complexities to our player.
 
@@ -465,26 +464,26 @@ Now let's look at ``process_movement``:
 First we assure that ``dir`` does not have any movement on the ``Y`` axis by setting it's ``Y`` value to zero.
 
 Next we normalize ``dir`` to assure we're within a ``1`` radius unit circle. This makes it where we're moving at a constant speed regardless
-of whether we've moving straight, or moving diagonal. If we did not normalize, we would move faster on the diagonal than when we're going straight.
+of whether the player is moving straight, or moving diagonally. If we did not normalize, the player would move faster on the diagonal than when going straight.
 
-Next we add gravity to our player by adding ``GRAVITY * delta`` to our ``Y`` velocity.
+Next we add gravity to the player by adding ``GRAVITY * delta`` to the player's ``Y`` velocity.
 
-After that we assign our velocity to a new variable (called ``hvel``) and remove any movement on the ``Y`` axis.
+After that we assign the player's velocity to a new variable (called ``hvel``) and remove any movement on the ``Y`` axis.
 
-Next we set a new variable (``target``) to our direction vector.
-Then we multiply that by our max speed so we know how far we will can move in the direction provided by ``dir``.
+Next we set a new variable (``target``) to the player's direction vector.
+Then we multiply that by the player's max speed so we know how far the player will move in the direction provided by ``dir``.
 
-After that we make a new variable for our acceleration, named ``accel``.
+After that we make a new variable for acceleration, named ``accel``.
 
-We then take the dot product of ``hvel`` to see if we are moving according to ``hvel``. Remember, ``hvel`` does not have any
-``Y`` velocity, meaning we are only checking if we are moving forwards, backwards, left, or right.
+We then take the dot product of ``hvel`` to see if the player is moving according to ``hvel``. Remember, ``hvel`` does not have any
+``Y`` velocity, meaning we are only checking if the player is moving forwards, backwards, left, or right.
 
 
-If we are moving according to ``hvel``, then we set ``accel`` to our ``ACCEL`` constant so we accelerate, otherwise we set ``accel` to
-our ``DEACCEL`` constant so we decelerate.
+If the player is moving according to ``hvel``, then we set ``accel`` to the ``ACCEL`` constant so the player will accelerate, otherwise we set ``accel` to
+our ``DEACCEL`` constant so the player will decelerate.
 
-Then we interpolate our horizontal velocity, set our ``X`` and ``Z`` velocity to the interpolated horizontal velocity,
-and call ``move_and_slide`` to let the :ref:`KinematicBody <class_KinematicBody>` handle moving through the physics world.
+Then we interpolate the horizontal velocity, set the player's ``X`` and ``Z`` velocity to the interpolated horizontal velocity,
+and call ``move_and_slide`` to let the :ref:`KinematicBody <class_KinematicBody>` handle moving the player through the physics world.
 
 .. tip:: All of the code in ``process_movement`` is exactly the same as the movement code from the Kinematic Character demo!
 
@@ -515,14 +514,14 @@ Then we rotate the entire :ref:`KinematicBody <class_KinematicBody>` on the ``Y`
          in the same direction.
 
 Finally, we clamp the ``rotation_helper``'s ``X`` rotation to be between ``-70`` and ``70``
-degrees so we cannot rotate ourselves upside down.
+degrees so the player cannot rotate themselves upside down.
 
 .. tip:: see :ref:`using transforms <doc_using_transforms>` for more information on rotating transforms.
 
 _________
 
 To test the code open up the scene named ``Testing_Area.tscn``, if it's not already opened up. We will be using
-this scene as we go through the tutorial, so be sure to keep it open in one of your scene tabs.
+this scene as we go through the next few tutorial parts, so be sure to keep it open in one of your scene tabs.
 
 Go ahead and test your code either by pressing ``F4`` with ``Testing_Area.tscn`` as the open tab, by pressing the
 play button in the top right corner, or by pressing ``F6``.
@@ -534,10 +533,10 @@ Giving the player a flash light and the option to sprint
 
 Before we get to making the weapons work, there is a couple more things we should add.
 
-Many FPS games have an option to sprint and a flash light. We can easily add these to our player,
+Many FPS games have an option to sprint and a flashlight. We can easily add these to our player,
 so let's do that!
 
-First we need a few more global variables in our player script:
+First we need a few more class variables in our player script:
 
 ::
 
@@ -551,7 +550,7 @@ All of the sprinting variables work exactly the same as the non sprinting variab
 similar names.
 
 ``is_sprinting`` is a boolean to track whether the player is currently sprinting, and ``flashlight`` is a variable
-we will be using to hold our flash light node.
+we will be using to hold the player's flash light node.
 
 Now we need to add a few lines of code, starting in ``_ready``. Add the following to ``_ready``:
 
@@ -559,7 +558,7 @@ Now we need to add a few lines of code, starting in ``_ready``. Add the followin
     
     flashlight = $Rotation_Helper/Flashlight
 
-This gets our flash light node and assigns it to the ``flashlight`` variable.
+This gets the flash light node and assigns it to the ``flashlight`` variable.
 
 _________
 
@@ -586,11 +585,11 @@ Now we need to change some of the code in ``process_input``. Add the following s
 
 Let's go over the additions:
 
-We set ``is_sprinting`` to true when we are holding down the ``movement_sprint`` action, and false
+We set ``is_sprinting`` to true when the player is holding down the ``movement_sprint`` action, and false
 when the ``movement_sprint`` action is released. In ``process_movement`` we'll add the code that makes the player faster when
-they sprint. Here in ``process_input`` we're going to change the ``is_sprinting`` variable.
+they sprint. Here in ``process_input`` we are just going to change the ``is_sprinting`` variable.
 
-We do something similar freeing/capturing the cursor for handling the flash light. We first check to see if the ``flashlight`` action
+We do something similar to freeing/capturing the cursor for handling the flashlight. We first check to see if the ``flashlight`` action
 was just pressed. If it was, we then check to see if ``flashlight`` is visible in the scene tree. If it is, then we hide it, and if it's not we show it.
 
 _________
@@ -604,10 +603,10 @@ Now we need to change a couple things in ``process_movement``. First, replace ``
     else:
         target *= MAX_SPEED
 
-Now instead of always multiplying ``target`` by ``MAX_SPEED``, we first check to see if we are sprinting or not.
-If we are sprinting, we instead multiply ``target`` by ``MAX_SPRINT_SPEED``. 
+Now instead of always multiplying ``target`` by ``MAX_SPEED``, we first check to see if the player is sprinting or not.
+If the player is sprinting, we instead multiply ``target`` by ``MAX_SPRINT_SPEED``. 
 
-Now all that's left is changing the accleration when sprinting. Change ``accel = ACCEL`` to the following:
+Now all that's left is changing the acceleration when sprinting. Change ``accel = ACCEL`` to the following:
 
 ::
     
@@ -617,13 +616,13 @@ Now all that's left is changing the accleration when sprinting. Change ``accel =
         accel = ACCEL
 
 
-Now when we are sprinting we'll use ``SPRINT_ACCEL`` instead of ``ACCEL``, which will accelerate us faster.        
+Now when the player is sprinting we'll use ``SPRINT_ACCEL`` instead of ``ACCEL``, which will accelerate the player faster.        
 
 _________
 
 You should now be able to sprint if you press the ``shift`` button, and can toggle the flash light on and off by pressing the ``F`` button!
 
-Go give it a whirl! You can change the sprint related global variables to make the player faster or slower when sprinting!
+Go give it a whirl! You can change the sprint related class variables to make the player faster or slower when sprinting!
 
 Final notes
 -----------

tutorials/3d/fps_tutorial/part_six.rst

@@ -125,7 +125,7 @@ Most of the code here relates to making UIs, which is outside of the purpose of
 
 .. tip:: See :ref:`doc_ui_main_menu` and the tutorials following for better ways to make GUIs and UIs!
 
-Let's look at the global variables first.
+Let's look at the class variables first.
 
 * ``start_menu``: A variable to hold the ``Start_Menu`` :ref:`Panel <class_Panel>`.
 * ``level_select_menu``: A variable to hold the ``Level_Select_Menu`` :ref:`Panel <class_Panel>`.
@@ -144,7 +144,7 @@ First we get all of the :ref:`Panel <class_Panel>` nodes and assign them to the
 
 Next we connect all of the buttons ``pressed`` signals to their respective ``[panel_name_here]_button_pressed`` functions.
 
-We then set the mouse mode to ``MOUSE_MODE_VISIBLE`` to ensure whenever we return to this scene our mouse will be visible.
+We then set the mouse mode to ``MOUSE_MODE_VISIBLE`` to ensure whenever the player returns to this scene the mouse will be visible.
 
 Then we get a singleton, called ``Globals``. We then set the values for the :ref:`HSlider <class_HSlider>` nodes so their values line up with the mouse and joypad sensitivity
 in the singleton.
@@ -155,16 +155,17 @@ ______
 
 In ``start_menu_pressed``, we check to see which button is pressed.
 
-Based on the button pressed, we either change the currently visible panel, quit the application, or open the Godot engine website.
+Based on the button pressed, we either change the currently visible panel, quit the application, or open the Godot website.
 
 ______
 
 In ``level_select_menu_button_pressed``, we check to see which button is pressed.
 
-If the ``back`` button has been pressed, we change the currently visible panels so we return to the main menu.
+If the ``back`` button has been pressed, we change the currently visible panels to return to the main menu.
 
-If one of the scene changing buttons are pressed, we fist call ``set_mouse_and_joypad_sensitivity`` so our singleton has the values from the :ref:`HSlider <class_HSlider>` nodes.
-Then we tell the singleton to change nodes using it's ``load_new_scene`` function, passing in the file path of the scene we're wanting to change to.
+If one of the scene changing buttons are pressed, we fist call ``set_mouse_and_joypad_sensitivity`` so the singleton (``Globals.gd``) has the values from the :ref:`HSlider 
+<class_HSlider>` nodes.
+Then we tell the singleton to change nodes using it's ``load_new_scene`` function, passing in the file path of the scene the player has selected.
 
 .. note:: Don't worry about the singleton, we'll get there soon!
 
@@ -172,7 +173,7 @@ ______
 
 In ``options_menu_button_pressed``, we check to see which button is pressed.
 
-If the ``back`` button has been pressed, we change the currently visible panels so we return to the main menu.
+If the ``back`` button has been pressed, we change the currently visible panels to return to the main menu.
 
 If the ``fullscreen`` button is pressed we toggle the :ref:`OS <class_OS>`'s full screen mode by setting it to the flipped version of it's current value.
 
@@ -207,13 +208,13 @@ Add the following to ``Globals.gd``.
         get_tree().change_scene(new_scene_path)
 
 As you can see, it's quite small and simple. As this part progresses we will
-keeping adding complexities to ``Global.gd``, but for now all it is doing is holding two variables for us, and abstracting how we change scenes.
+keeping adding complexities to ``Global.gd``, but for now all it is doing is holding two class variables, and abstracting how we change scenes.
 
 * ``mouse_sensitivity``: The current sensitivity for our mouse, so we can load it in ``Player.gd``.
 * ``joypad_sensitivity``: The current sensitivity for our joypad, so we can load it in ``Player.gd``.
 
-Right now all we're using ``Globals.gd`` for is a way to carry variables across scenes. Because the sensitivity for our mouse and joypad are
-stored in ``Globals.gd``, any changes we make in one scene (like ``Main_Menu``) effect the sensitivity for our player.
+Right now all we will be using ``Globals.gd`` for is a way to carry variables across scenes. Because the sensitivity for our mouse and joypad are
+stored in ``Globals.gd``, any changes we make in one scene (like ``Main_Menu``) will effect the sensitivity for the player.
 
 All we're doing in ``load_new_scene`` is calling :ref:`SceneTree <class_SceneTree>`'s ``change_scene`` function, passing in the scene path given in ``load_new_scene``.
 
@@ -226,23 +227,23 @@ Open up the project settings and click the ``AutoLoad`` tab.
 Then select the path to ``Globals.gd`` in the ``Path`` field by clicking the button beside it. Make sure the name in the ``Node Name`` field is ``Globals``. If you
 have everything like the picture above, then press ``Add``!
 
-This will make ``Globals.gd`` a singleton/autoload script, which will allow us to access it from anywhere in any scene.
+This will make ``Globals.gd`` a singleton/autoload script, which will allow us to access it from any script, in any scene.
 
 .. tip:: For more information on singleton/autoload scripts, see :ref:`doc_singletons_autoload`.
 
 Now that ``Globals.gd`` is a singleton/autoload script, you can test the main menu!
 
-You may also want to change the main scene from ``Testing_Area.tscn`` to ``Main_Menu.tscn`` so when we export the game we start at the main menu. You can do this
+You may want to change the main scene from ``Testing_Area.tscn`` to ``Main_Menu.tscn`` so when we export the game the player will start at the main menu. You can do this
 through the project settings, under the ``General`` tab. Then in the ``Application`` category, click the ``Run`` subcategory and you can change the main scene by changing
 the value in ``Main Scene``.
 
 .. warning:: You'll have to set the paths to the correct files in ``Main_Menu`` in the editor before testing the main menu!
-            Otherwise you will not be able to change scenes from the level select menu/screen.
+             Otherwise you will not be able to change scenes from the level select menu/screen.
 
 Adding the debug menu
 ---------------------
 
-Now let's add a simple debugging scene so we can track things like FPS in game. Open up ``Debug_Display.tscn``.
+Now let's add a simple debugging scene so the we can track things like FPS (Frames Per Second) in game. Open up ``Debug_Display.tscn``.
 
 You can see it's a :ref:`Panel <class_Panel>` positioned in the top right corner of the screen. It has three :ref:`Labels <class_Label>`,
 one for displaying the FPS the game is running at, one for showing what OS the game is running on, and a label for showing the Godot version the game is running with.
@@ -269,11 +270,11 @@ name of the OS (or Operating System) that Godot was compiled for. For example, w
 are running Linux it will return ``X11``.
 
 Then we set the ``Engine_Label``'s text to the version info provided by ``Engine.get_version_info``. ``Engine.get_version_info`` returns a dictionary full
-of useful information about the version Godot is currently running with. We only care for the string version for the purposes of this display, so we get the string
+of useful information about the version Godot is currently running with. We only care for the string version, for this label at least, so we get the string
 and assign that as the ``text`` in ``Engine_Label``. See :ref:`Engine <class_Engine>` for more information on the values ``get_version_info`` returns.
 
 In ``_process`` we set the text of the ``FPS_Label`` to ``Engine.get_frames_per_second``, but because ``get_frames_per_second`` returns a integer, we have to cast
-it to a string using ``str`` before we can add it to our label.
+it to a string using ``str`` before we can add it to the :ref:`Label <class_Label>`.
 
 ______
 
@@ -295,7 +296,7 @@ This will call a new function in our singleton called ``set_debug_display``, so
 
 ______
 
-Open up ``Globals.gd`` and add the following global variables:
+Open up ``Globals.gd`` and add the following class variables:
 
 ::
     
@@ -309,11 +310,11 @@ Open up ``Globals.gd`` and add the following global variables:
     
     # ------------------------------------
 
-* ``canvas_layer``: A canvas layer so our GUI/UI is always drawn on top.
+* ``canvas_layer``: A canvas layer so the GUI/UI created in ``Globals.gd`` is always drawn on top.
 * ``DEBUG_DISPLAY``: The debug display scene we worked on earlier.
-* ``debug_display``: A variable to hold the debug display when there is one.
+* ``debug_display``: A variable to hold the debug display when/if there is one.
 
-Now that we have our global variables defined, we need to add a few lines to ready so we have a canvas layer to use in ``canvas_layer``.
+Now that we have the class variables defined, we need to add a few lines to ready so ``Globals.gd`` will have a canvas layer to use (which we will store in ``canvas_layer``).
 Change ``_ready`` to the following:
 
 ::
@@ -322,7 +323,9 @@ Change ``_ready`` to the following:
         canvas_layer = CanvasLayer.new()
         add_child(canvas_layer)
 
-Now in ``_ready`` we're creating a new canvas layer and adding it as a child of the autoload script.
+Now in ``_ready``, we creating a new canvas layer, assign it to ``canvas_layer`` and add it as a child.
+Because ``Globals.gd`` is a autoload/singleton, Godot will make a :ref:`Node <class_Node>` when the game is launched, and it will have ``Globals.gd`` attached to it.
+Since Godot makes a :ref:`Node <class_Node>`, we can treat ``Globals.gd`` like any other node with regard to adding/removing children nodes.
 
 The reason we're adding a :ref:`CanvasLayer <class_CanvasLayer>` is so all of our GUI and UI nodes we instance/spawn in ``Globals.gd``
 are always drawn on top of everything else.
@@ -349,12 +352,13 @@ Now we need to add ``set_debug_display`` to ``Globals.gd``:
                 
 Let's go over what's happening.
 
-First we check to see if we're trying to turn on the debug display, or turn it off.
+First we check to see if ``Globals.gd`` is trying to turn on the debug display, or turn it off.
 
-If we are turning off the display, we then check to see if ``debug_display`` is not equal to ``null``. If ``debug_display`` is not equal to ``null``, then we
-most have a debug display currently active. If we have a debug display active, we free it using ``queue_free`` and then assign ``debug_display`` to ``null``.
+If ``Globals.gd`` is turning off the display, we then check to see if ``debug_display`` is not equal to ``null``. If ``debug_display`` is not equal to ``null``, then ``Globals.gd``
+must have a debug display currently active. If ``Globals.gd`` has a debug display active, we free it using ``queue_free`` and then assign ``debug_display`` to ``null``.
 
-If we are turning on the display, we then check to make sure we do not already have a debug display active. We do this by making sure ``debug_display`` is equal to ``null``.
+If ``Globals.gd`` is turning on the display, we then check to make sure ``Globals.gd`` do not already have a debug display active.
+We do this by making sure ``debug_display`` is equal to ``null``.
 If ``debug_display`` is ``null``, we instance a new ``DEBUG_DISPLAY_SCENE``, and add it as a child of ``canvas_layer``.
 
 ______
@@ -383,7 +387,7 @@ Now that we've looked at how ``Pause_Popup.tscn`` is set up, lets write the code
 the scene, ``Pause_Popup`` in this case, but since we'll need to receive a couple of signals in ``Globals.gd``, we'll write all of the code for
 the pop up there.
 
-Open up ``Globals.gd`` and add the following global variables:
+Open up ``Globals.gd`` and add the following class variables:
 
 ::
     
@@ -395,7 +399,7 @@ Open up ``Globals.gd`` and add the following global variables:
 * ``POPUP_SCENE``: The pop up scene we looked at earlier.
 * ``popup``: A variable to hold the pop up scene.
 
-Now we need to add ``_process`` to ``Globals.gd`` so we can respond when the ``ui_cancel`` action is pressed.
+Now we need to add ``_process`` to ``Globals.gd`` so it can respond when the ``ui_cancel`` action is pressed.
 Add the following to ``_process``:
 
 ::
@@ -420,10 +424,10 @@ Let's go over what's happening here.
 
 ______
 
-First we check to see if the ``ui_cancel`` action is pressed. Then we check to make sure we do not already
+First we check to see if the ``ui_cancel`` action is pressed. Then we check to make sure ``Globals.gd`` does not already
 have a ``popup`` open by checking to see if ``popup`` is equal to ``null``.
 
-If we do not have a pop up open, we instance ``POPUP_SCENE`` and assign it to ``popup``.
+If ``Globals.gd`` do not have a pop up open, we instance ``POPUP_SCENE`` and assign it to ``popup``.
 
 We then get the quit button and assign it's ``pressed`` signal to ``popup_quit``, which we will be adding shortly.
 
@@ -432,8 +436,8 @@ to ``popup_closed``, which we will be adding shortly.
 
 Then we add ``popup`` as a child of ``canvas_layer`` so it's drawn on top. We then tell ``popup`` to pop up at the center of the screen using ``popup_centered``.
 
-Next we make sure the mouse mode is ``MOUSE_MODE_VISIBLE`` to we can interact with the pop up. If we did not do this, we would not be able to interact with the pop up
-in any scene where the mouse mode is ``MOUSE_MODE_CAPTURED``.
+Next we make sure the mouse mode is ``MOUSE_MODE_VISIBLE`` so the player can interact with the pop up. If we did not do this, the player would not be able to
+interact with the pop up in any scene where the mouse mode is ``MOUSE_MODE_CAPTURED``.
 
 Finally, get pause the entire :ref:`SceneTree <class_SceneTree>`.
 
@@ -499,12 +503,12 @@ Now the pause menu pop up is finished. You can now pause at any point in the gam
 Starting the respawn system
 ---------------------------
 
-Since our player can lose all their health, it would be ideal if our players died and respawned too, so let's add that!
+Since the player can lose all their health, it would be ideal if the player died and respawned too, so let's add that next!
 
-First, open up ``Player.tscn`` and expand ``HUD``. Notice how there's a :ref:`ColorRect <class_ColorRect>` called ``Death_Screen``.
-When the player dies, we're going to make ``Death_Screen`` visible, and show them how long they have to wait before they're able to respawn.
+First, open up ``Player.tscn`` and expand ``HUD``. Notice how there is a :ref:`ColorRect <class_ColorRect>` called ``Death_Screen``.
+When the player dies, we're going to make ``Death_Screen`` visible, and show them how long they have to wait before the player is able to respawn.
 
-Open up ``Player.gd`` and add the following global variables:
+Open up ``Player.gd`` and add the following class variables:
 
 ::
     
@@ -521,7 +525,7 @@ Open up ``Player.gd`` and add the following global variables:
 
 ______
 
-We now need to add a couple lines to ``_ready``, so we can use ``Globals.gd``. Add the following to ``_ready``:
+We now need to add a couple lines to ``_ready``, so we can use ``Globals.gd`` in ``Player.gd``. Add the following to ``_ready``:
 
 ::
     
@@ -529,10 +533,10 @@ We now need to add a couple lines to ``_ready``, so we can use ``Globals.gd``. A
     global_transform.origin = globals.get_respawn_position()
     
 
-Now we're getting the ``Globals.gd`` singleton and assigning it to ``globals``. We also set our global position
-using the origin from our global :ref:`Transform <class_Transform>` to the position returned by ``globals.get_respawn_position``.
+Now we're getting the ``Globals.gd`` singleton and assigning it to ``globals``. We also set the player's global position
+by setting the origin in the player's global :ref:`Transform <class_Transform>` to the position returned by ``globals.get_respawn_position``.
 
-.. note:: Don't worry, we'll add ``get_respawn_position`` further below!
+.. note:: Don't worry, we will be adding ``get_respawn_position`` further below!
     
 ______
     
@@ -554,8 +558,8 @@ Next we need to make a few changes to ``physics_process``. Change ``physics_proc
         process_UI(delta)
         process_respawn(delta)
 
-Now we're not processing input or movement input when we're dead. We're also now calling ``process_respawn``, but we haven't written
-``process_respawn`` yet, so let's change that.
+Now the player will not be processing input or movement input when the player is dead. We are also now calling ``process_respawn``.
+We have not made ``process_respawn`` yet, so let's change that.
 
 ______
 
@@ -622,41 +626,42 @@ Let's go through what this function is doing.
 
 ______
 
-First we check to see if we just died by checking to see if ``health`` is equal or less than ``0`` and ``is_dead`` is ``false``.
+First we check to see if the player has just died by checking to see if ``health`` is equal or less than ``0`` and ``is_dead`` is ``false``.
 
-If we just died, we disable our collision shapes for the player. We do this to make sure we're not blocking anything with our dead body.
+If the player has just died, we disable the collision shapes for the player. We do this to make sure the player is not blocking anything with their dead body.
 
-We next set ``changing_weapon`` to ``true`` and set ``changing_weapon_name`` to ``UNARMED``. This is so if we are using a weapon, we put it away
-when we die.
+Next we set ``changing_weapon`` to ``true`` and set ``changing_weapon_name`` to ``UNARMED``. This is so if the player is using a weapon, it is put away
+when the player dies.
 
-We then make the ``Death_Screen`` :ref:`ColorRect <class_ColorRect>` visible so we get a nice grey overlay over everything. We then make the rest of the UI,
-the ``Panel`` and ``Crosshair`` nodes, invisible.
+We then make the ``Death_Screen`` :ref:`ColorRect <class_ColorRect>` visible so the player gets a nice grey overlay over everything when they have died.
+We then make the rest of the UI, the ``Panel`` and ``Crosshair`` nodes, invisible.
 
-Next we set ``dead_time`` to ``RESPAWN_TIME`` so we can start counting down how long we've been dead. We also set ``is_dead`` to ``true`` so we know we've died.
+Next we set ``dead_time`` to ``RESPAWN_TIME`` so we can start counting down how long the player has been dead. We also set ``is_dead`` to ``true`` so we know the player has died.
 
-If we are holding an object when we died, we need to throw it. We first check to see if we are holding an object or not. If we are, we then throw it,
-using the same code as the throwing code we added in :ref:`doc_fps_tutorial_part_five`.
+If the player is holding an object when they died, we need to throw it. We first check to see if the player is holding an object or not.
+If the player is holding a object, we throw it using the same code as the throwing code we added in :ref:`doc_fps_tutorial_part_five`.
 
 ______
 
-Then we check to see if we are dead. If we are, we then remove ``delta`` from ``dead_time``.
+Then we check to see if the player is dead. If the player is dead, we then remove ``delta`` from ``dead_time``.
 
 We then make a new variable called ``dead_time_pretty``, where we convert ``dead_time`` to a string, using only the first three characters starting from the left. This gives
-us a nice looking string showing how much time we have left to wait before we respawn.
+the player a nice looking string showing how much time the player has left to wait before the player can respawn.
 
-We then change the :ref:`Label <class_Label>` in ``Death_Screen`` to show how much time we have left.
+We then change the :ref:`Label <class_Label>` in ``Death_Screen`` to show how much time the player has left.
 
-Next we check to see if we've waited long enough and can respawn. We do this by checking to see if ``dead_time`` is ``0`` or less.
+Next we check to see if the player has waited long enough and can respawn. We do this by checking to see if ``dead_time`` is ``0`` or less.
 
-If we have waited long enough to respawn, we set the player's position to a new respawn position provided by ``get_respawn_position``.
+If the player has waited long enough to respawn, we set the player's position to a new respawn position provided by ``get_respawn_position``.
 
-We then enable both of our collision shapes so the player can collide with the environment.
+We then enable both of the player's collision shapes so the player can collide with the environment.
 
 Next we make the ``Death_Screen`` invisible and make the rest of the UI, the ``Panel`` and ``Crosshair`` nodes, visible again.
 
-We then go through each weapon and call it's ``reset_weapon`` function. We'll add ``reset_weapon`` soon.
+We then go through each weapon and call it's ``reset_weapon`` function, which we will add soon.
 
 Then we reset ``health`` to ``100``, ``grenade_amounts`` to it's default values, and change ``current_grenade`` to ``Grenade``.
+This effectively resets these variables to their default values.
 
 Finally, we set ``is_dead`` to ``false``.
 
@@ -669,7 +674,7 @@ Before we leave ``Player.gd``, we need to add one quick thing to ``_input``. Add
     if is_dead:
         return
 
-Now when we're dead we cannot look around with the mouse.
+Now when the player is dead, the player cannot look around with the mouse.
 
 Finishing the respawn system
 ----------------------------
@@ -682,7 +687,7 @@ First let's open ``Weapon_Pistol.gd`` and add the ``reset_weapon`` function. Add
         ammo_in_weapon = 10
         spare_ammo = 20
 
-Now when we call ``reset_weapon``, the ammo in our weapon and the ammo in the spares will be reset to their default values.
+Now when we call ``reset_weapon``, the ammo in the pistol and the ammo in the spares will be reset to their default values.
 
 Now let's add ``reset_weapon`` in ``Weapon_Rifle.gd``:
 
@@ -700,11 +705,11 @@ And add the following to ``Weapon_Knife.gd``:
         ammo_in_weapon = 1
         spare_ammo = 1
 
-Now our weapons will reset when we die.
+Now all of the weapons will reset when the player dies.
 
 ______
 
-Now we need to add a few things to ``Globals.gd``. First, add the following global variable:
+Now we need to add a few things to ``Globals.gd``. First, add the following class variable:
 
 ::
     
@@ -735,25 +740,25 @@ Let's go over what this function does.
 
 ______
 
-First we check to see if we have any ``respawn_points`` by checking to see if ``respawn_points`` is ``null`` or not.
+First we check to see if ``Globals.gd`` has any ``respawn_points`` by checking to see if ``respawn_points`` is ``null`` or not.
 
 If ``respawn_points`` is ``null``, we return a position of empty :ref:`Vector 3 <class_Vector3>` with the position ``(0, 0, 0)``.
 
 If ``respawn_points`` is not ``null``, we then get a random number between ``0`` and the number of elements we have in ``respawn_points``, minus ``1`` since
-most programming languages (including ``GDScript``) start counting from ``0`` when you are accessing elements in a list.
+most programming languages, including ``GDScript``, start counting from ``0`` when you are accessing elements in a list.
 
 We then return the position of the :ref:`Spatial <class_Spatial>` node at ``respawn_point`` position in ``respawn_points``.
 
 ______
 
-Before we're done with ``Globals.gd``. We need to add the following to ``load_new_scene``:
+Before we are done with ``Globals.gd``. We need to add the following to ``load_new_scene``:
 
 ::
     
     respawn_points = null
 
-We set ``respawn_points`` to ``null`` so when/if we get to a level with no respawn points, we do not respawn
-at the respawn points in the level prior.
+We set ``respawn_points`` to ``null`` so when/if the player gets to a level with no respawn points, we do not respawn the player
+at the respawn points that were in the level prior.
 
 ______
 
@@ -777,7 +782,7 @@ to ``respawn_points`` in ``Globals.gd``.
 
 ______
 
-Now when you die you'll respawn after waiting ``4`` seconds!
+Now when the player dies, they will respawn after waiting ``4`` seconds!
 
 .. note:: No spawn points are already set up for any of the levels besides ``Ruins_Level.tscn``!
           Adding spawn points to ``Space_Level.tscn`` is left as an exercise for the reader.
@@ -830,39 +835,39 @@ First, open up ``SimpleAudioPlayer.gd`` and change it to the following:
             queue_free()
 
             
-There's several changes from the old version, first and foremost being we're no longer storing the sound files in ``SimpleAudioPlayer.gd`` anymore.
-This is much better for performance since we're no longer loading each audio clip when we create a sound, but instead we're forcing a audio stream to be passed
+There are several changes from the old version, first and foremost being we are no longer storing the sound files in ``SimpleAudioPlayer.gd`` anymore.
+This is much better for performance since we're no longer loading each audio clip when we create a sound, but instead we are forcing a audio stream to be passed
 in to ``play_sound``.
 
-Another change is we have a new global variable called ``should_loop``. Instead of just destroying the audio player every time it's finished, we instead want check to
-see if we are set to loop or not. This allows us to have audio like looping background music without having to spawn a new audio player with the music
+Another change is we have a new class variable called ``should_loop``. Instead of just destroying the audio player every time it's finished, we instead want check to
+see if the audio player is set to loop or not. This allows us to have audio like looping background music without having to spawn a new audio player with the music
 when the old one is finished.
 
-Finally, instead of being instanced/spawned in ``Player.gd``, we're instead going to be spawned in ``Globals.gd`` so we can create sounds from any scene. We now need
-to store the ``Globals.gd`` singleton so when we destroy the audio player, we also remove it from a list in ``Globals.gd``.
+Finally, instead of being instanced/spawned in ``Player.gd``, the audio player is instead going to be spawned in ``Globals.gd`` so we can create sounds from any scene.
+Now the audio player stores ``Globals.gd`` singleton so when the audio player is destroyed, we can also remove it from a list in ``Globals.gd``.
 
 Let's go over the changes.
 
 ______
 
-For the global variables
-we removed all of the ``audio_[insert name here]`` variables since we will instead have these passed in to.
-We also added two new global variables, ``should_loop`` and ``globals``. We'll use ``should_loop`` to tell whether we want to loop when the sound has
+For the class variables we removed all of the ``audio_[insert name here]`` variables since we will instead have these passed in.
+
+We also added two new class variables, ``should_loop`` and ``globals``. We'll use ``should_loop`` to tell whether the audio player should loop when the sound has
 finished, and ``globals`` will hold the ``Globals.gd`` singleton.
 
-The only change in ``_ready`` is now we're getting the ``Globals.gd`` singleton and assigning it to ``globals``
+The only change in ``_ready`` is now audio player is getting the ``Globals.gd`` singleton and assigning it to ``globals``
 
-In ``play_sound`` we now expect a audio stream, named ``audio_stream``, to be passed in, instead of ``sound_name``. Instead of checking the
+``play_sound`` now expects a audio stream, named ``audio_stream``, to be passed in, instead of ``sound_name``. Instead of checking the
 sound name and setting the stream for the audio player, we instead check to make sure an audio stream was passed in. If a audio stream is not passed
 in, we print an error message, remove the audio player from a list in the ``Globals.gd`` singleton called ``created_audio``, and then free the audio player.
 
-Finally, in ``sound_finished`` we first check to see if we are supposed to loop or not using ``should_loop``. If we are supposed to loop, we play the sound
-again from the start of the audio, at position ``0.0``. If we are not supposed to loop, we remove the audio player from a list in the ``Globals.gd`` singleton
+Finally, in ``sound_finished`` we first check to see if the audio player is supposed to loop or not using ``should_loop``. If the audio player is supposed to loop,
+we play the sound again from the start, at position ``0.0``. If the audio player is not supposed to loop, we remove the audio player from a list in the ``Globals.gd`` singleton
 called ``created_audio``, and then free the audio player.
 
 ______
 
-Now that we've finished our changes to ``SimpleAudioPlayer.gd``, we now need to turn our attention to ``Globals.gd``. First, add the following global variables:
+Now that we've finished our changes to ``SimpleAudioPlayer.gd``, we now need to turn our attention to ``Globals.gd``. First, add the following class variables:
 
 ::
     
@@ -882,9 +887,9 @@ Now that we've finished our changes to ``SimpleAudioPlayer.gd``, we now need to
 
 Lets go over these global variables.
 
-* ``audio_clips``: A dictionary holding all of the audio clips we can play.
+* ``audio_clips``: A dictionary holding all of the audio clips ``Globals.gd`` can play.
 * ``SIMPLE_AUDIO_PLAYER_SCENE``: The simple audio player scene.
-* ``created_audio``: A list to hold all of the simple audio players we create
+* ``created_audio``: A list to hold all of the simple audio players ``Globals.gd`` has created
 
 .. note:: If you want to add additional audio, you need to add it to ``audio_clips``. No audio files are provided in this tutorial,
           so you will have to provide your own.
@@ -916,21 +921,21 @@ Now we need to add a new function called ``play_sound`` to ``Globals.gd``:
         else:
             print ("ERROR: cannot play sound that does not exist in audio_clips!")
 
-Let's go over what this script does.
+Let's go over what this function does.
 
-First we check to see if we have a audio clip with the name ``sound_name`` in ``audio_clips``. If we do not, we print an error message.
+First we check to see if ``Globals.gd`` has a audio clip with the name ``sound_name`` in ``audio_clips``. If it does not, we print an error message.
 
-If we do have a audio clip with the name ``sound_name``, we then instance/spawn a new ``SIMPLE_AUDIO_PLAYER_SCENE`` and assign it to ``new_audio``.
+If ``Globals.gd`` has a audio clip with the name ``sound_name``, we then instance/spawn a new ``SIMPLE_AUDIO_PLAYER_SCENE`` and assign it to ``new_audio``.
 
 We then set ``should_loop``, and add ``new_audio`` as a child of ``Globals.gd``.
 
 .. note:: Remember, we have to be careful adding nodes to a singleton, since these nodes will not be destroyed when changing scenes.
 
-We then call ``play_sound``, passing in the audio clip associated with ``sound_name``, and the sound position.
+We then call ``play_sound``, passing in the audio clip associated with ``sound_name`` and the sound position.
 
 ______
 
-Before we leave ``Globals.gd``, we need to add a few lines of code to ``load_new_scene`` so when we change scenes, we destroy all of the audio.
+Before we leave ``Globals.gd``, we need to add a few lines of code to ``load_new_scene`` so when the player changes scenes, all of the audio is destroyed.
 
 Add the following to ``load_new_scene``:
 
@@ -941,13 +946,13 @@ Add the following to ``load_new_scene``:
             sound.queue_free()
     created_audio.clear()
     
-Now before we change scenes we go through each simple audio player in ``created_sounds`` and free/destroy them. Once we've gone through
-all of the sounds in ``created_audio``, we clear ``created_audio`` so it no longer holds any references to any of the previously created simple audio players.
+Now before ``Globals.gd`` changes scenes, it goes through each simple audio player in ``created_sounds`` and frees/destroys them. Once ``Globals.gd`` has gone through
+all of the sounds in ``created_audio``, we clear ``created_audio`` so it no longer holds any references to any (noew freed/destroyed) simple audio players.
 
 ______
 
-Let's change ``create_sound`` in ``Player.gd`` to use this new system. First, remove ``simple_audio_player`` from ``Player.gd``'s global variables, since we will
-no longer be directly instancing/spawning sounds from ``Player.gd``.
+Let's change ``create_sound`` in ``Player.gd`` to use this new system. First, remove ``simple_audio_player`` from ``Player.gd``'s class variables, since we will
+no longer be directly instancing/spawning sounds in ``Player.gd``.
 
 Now, change ``create_sound`` to the following:
 
@@ -956,17 +961,17 @@ Now, change ``create_sound`` to the following:
     func create_sound(sound_name, position=null):
         globals.play_sound(sound_name, false, position)
 
-Now whenever ``create_sound`` is called, we simply call ``play_sound`` in ``Globals.gd``, passing in all of the arguments we've revived.
+Now whenever ``create_sound`` is called, we simply call ``play_sound`` in ``Globals.gd``, passing in all of the arguments revived.
 
 ______
 
-Now all of the sounds in our FPS can be played from anywhere. All we have to do is get the ``Globals.gd`` singleton, and call ``play_sound``, passing in the name of the sound
+Now all of the sounds in our FPS can be played from anywhere. All we have to do is get the ``Globals.gd`` singleton, and call ``play_sound``, pass in the name of the sound
 we want to play, whether we want it to loop or not, and the position to play the sound from.
 
 For example, if you want to play an explosion sound when the grenades explode you'd need to add a new sound to ``audio_clips`` in ``Globals.gd``,
 get the ``Globals.gd`` singleton, and then you just need to add something like
 ``globals.play_sound("explosion", false, global_transform.origin)`` in the grenades
-``_process`` function, right after the grenade damages all of the bodies within it's blast radius.
+``_process`` function, right after the grenade damages all of the bodies within its blast radius.
 
 Final notes
 -----------

tutorials/3d/fps_tutorial/part_three.rst

@@ -6,15 +6,12 @@ Part 3
 Part Overview
 -------------
 
-In this part we will be limiting our weapons by giving them ammo. We will also
+In this part we will be limiting the player's weapons by giving them ammo. We will also
 be giving the player the ability to reload, and we will be adding sounds when the
 weapons fire.
 
 .. image:: img/PartThreeFinished.png
 
-By the end of this part, the player will have limited ammo, the ability to reload,
-and sounds will play when the player fires and changes weapons.
-
 .. note:: You are assumed to have finished :ref:`doc_fps_tutorial_part_two` before moving on to this part of the tutorial.
           
           The finished project from :ref:`doc_fps_tutorial_part_two` will be the starting project for part 3
@@ -74,16 +71,16 @@ Follow the instructions below for either (or both) of the scenes you want to use
     
     Return back to "Ruins_Level.tscn".
 
-Now you can fire at all of the rigid bodies in either level!
+Now you can fire at all of the rigid bodies in either level and they will react to bullets hitting them!
 
 Adding ammo
 -----------
 
-Now that we've got working guns, let's give them a limited amount of ammo.
+Now that the player has working guns, let's give them a limited amount of ammo.
 
 First we need to define a few variables in each of our weapon scripts.
 
-Open up ``Weapon_Pistol.gd`` and add the following global variables:
+Open up ``Weapon_Pistol.gd`` and add the following class variables:
 
 ::
     
@@ -99,8 +96,8 @@ Now all we need to do is add a single line of code to ``fire_weapon``.
 
 Add the following right under ``Clone.BULLET_DAMAGE = DAMAGE``: ``ammo_in_weapon -= 1``
 
-This will remove one from ``ammo_in_weapon`` every time we fire. Notice we're not checking to see
-if we have ammo count of ``0`` or greater in ``fire_weapon``. Instead we're going to check that the ammo count in ``Player.gd``.
+This will remove one from ``ammo_in_weapon`` every time the player fires. Notice we're not checking to see
+if the player has enough ammo or not in ``fire_weapon``. Instead we're going to check to see if the player has enough ammo in ``Player.gd``.
 
 _______
 
@@ -112,7 +109,7 @@ Now we need to add ammo for both the rifle and the knife.
           If we did not add ammo variables for the knife, we would have to add checks for the knife. By adding the ammo
           variables to the knife, we don't need to worry about whether or all our weapons have the same variables.
 
-Add the following global variables to ``Weapon_Rifle.gd``:
+Add the following class variables to ``Weapon_Rifle.gd``:
 
 ::
     
@@ -121,7 +118,7 @@ Add the following global variables to ``Weapon_Rifle.gd``:
     const AMMO_IN_MAG = 50
 
 And then add the following to ``fire_weapon``: ``ammo_in_weapon -= 1``. Make sure that ``ammo_in_weapon -= 1`` is outside of the ``if ray.is_colliding()`` check so
-we lost ammo regardless of whether we've hit something or not.
+the player loses ammo regardless of whether the player hit something or not.
 
 Now all that's left is the knife. Add the following to ``Weapon_Knife.gd``:
 
@@ -131,13 +128,13 @@ Now all that's left is the knife. Add the following to ``Weapon_Knife.gd``:
     var spare_ammo = 1
     const AMMO_IN_MAG = 1
 
-And because our knife does not consume ammo, that is all we need to add.
+And because the knife does not consume ammo, that is all we need to add.
 
 _______
 
 Now all we need to do is change a one thing in ``Player.gd``.
 
-All we need to change how we're firing our weapons in ``process_input``. Change the code for firing weapons to the following:
+All we need to change how we're firing the weapons in ``process_input``. Change the code for firing weapons to the following:
 
 ::
     
@@ -152,11 +149,11 @@ All we need to change how we're firing our weapons in ``process_input``. Change
                         animation_manager.set_animation(current_weapon.FIRE_ANIM_NAME)
     # ----------------------------------
     
-Now our weapons have a limited amount of ammo, and will stop firing when we run out.
+Now the weapons have a limited amount of ammo, and will stop firing when the player runs out.
 
 _______
 
-Ideally we'd like to be able to see how much ammo we have left. Let's make a new function called ``process_ui``.
+Ideally we'd like to let the player be able to see how much ammo is left. Let's make a new function called ``process_ui``.
 
 First, add ``process_UI(delta)`` to ``_physics_process``.
 
@@ -175,24 +172,24 @@ Now add the following to ``Player.gd``:
 Let's go over what's happening:
 
 First we check to see if the current weapon is either ``UNARMED`` or ``KNIFE``. If it is, we
-change the ``UI_status_label``'s text to only show our health, since ``UNARMED`` and ``KNIFE`` do not consume ammo.
+change the ``UI_status_label``'s text to only show the player's health, since ``UNARMED`` and ``KNIFE`` do not consume ammo.
 
-If we are using a weapon that does consume ammo, we first get the weapon node.
+If the player is using a weapon that consumes ammo, we first get the weapon node.
 
-Then change ``UI_status_label``'s text to show our health, how much ammo we have in the weapon,
-along with how much spare ammo we have for that weapon.
+Then change ``UI_status_label``'s text to show the player's health, along how much ammo the player has in the weapon
+and how much spare ammo the player has for that weapon.
 
 
-Now we can see how much ammo we have through the HUD.
+Now we can see how much ammo the player has through the HUD.
 
 Adding reloading to the weapons
 -------------------------------
 
-Now that we can run our weapons out of ammo, we need a way to fill them back up. Let's add reloading next!
+Now that the player can run out of ammo, we need a way to let the player fill them back up. Let's add reloading next!
 
 For reloading we need to add a few more variables and a function to every weapon.
 
-Open up ``Weapon_Pistol.gd`` and add the following global variables:
+Open up ``Weapon_Pistol.gd`` and add the following class variables:
 
 ::
     
@@ -236,27 +233,27 @@ Now we need to add a function for handling reloading. Add the following function
     
 Let's go over what's happening:
 
-First we define a variable to see whether or not we can reload.
+First we define a variable to see whether or not this weapon can reload.
 
-We first check to see if we are in this weapon's idle animation state because we only want to be able to reload when we are not
-firing. equipping, or unequipping.
+Then we check to see if the player is in this weapon's idle animation state because we only want to be able to reload when the player is not
+firing, equipping, or unequipping.
 
-Next we check to see if we have spare ammo, and if the ammo already in our weapon is equal to a fully reloaded weapon.
-This way we can assure we're not going to reload when we have no ammo or when the weapon is already full of ammo.
+Next we check to see if the player has spare ammo, and if the ammo already in the weapon is equal to a fully reloaded weapon.
+This way we can assure the player cannot reload when the player has no ammo or when the weapon is already full of ammo.
 
 If we still can reload, then we calculate the amount of ammo needed to reload the weapon.
 
-If we have enough ammo to fill the weapon, we remove the ammo needed from ``spare_ammo`` and then set ``ammo_in_weapon`` to a full weapon/magazine.
+If the player has enough ammo to fill the weapon, we remove the ammo needed from ``spare_ammo`` and then set ``ammo_in_weapon`` to a full weapon/magazine.
 
-If we do not have enough ammo, we add all of the ammo left in ``spare_ammo``, then set ``spare_ammo`` to ``0``.
+If the player does not have enough ammo, we add all of the ammo left in ``spare_ammo``, and then set ``spare_ammo`` to ``0``.
 
 Next we play the reloading animation for this weapon, and then return ``true``.
 
-If we could not reload, we return ``false``.
+If the player could not reload, we return ``false``.
 
 _______
 
-Now we need to add reloading to the rifle. Open up ``Weapon_Rifle.gd`` and add the following global variables:
+Now we need to add reloading to the rifle. Open up ``Weapon_Rifle.gd`` and add the following class variables:
 
 ::
     
@@ -300,7 +297,7 @@ This code is exactly the same as the pistol.
 
 _______
 
-The last bit we need to do for the weapons is add 'reloading' to the knife. Add the following global variables to ``Weapon_Knife.gd``:
+The last bit we need to do for the weapons is add 'reloading' to the knife. Add the following class variables to ``Weapon_Knife.gd``:
 
 ::
     
@@ -324,13 +321,13 @@ Since we cannot reload a knife, we always return ``false``.
 Adding reloading to the player
 ------------------------------
 
-Now we need to add a few things to ``Player.gd``. First we need to define a new global variable:
+Now we need to add a few things to ``Player.gd``. First we need to define a new class variable:
 
 ::
     
     var reloading_weapon = false
     
-* ``reloading_weapon``: A variable to track whether or not we are currently trying to reload.
+* ``reloading_weapon``: A variable to track whether or not the player is currently trying to reload.
 
 
 Next we need to add another function call to ``_physics_process``.
@@ -359,20 +356,20 @@ Now we need to add ``process_reloading``. Add the following function to ``Player
 
 Let's go over what's happening here.
 
-First we check to make sure we are trying to reload.
+First we check to make sure the player is trying to reload.
 
-If we are, we then get the current weapon. If the current weapon does not equal ``null``, we call its ``reload_weapon`` function.
+If the player is trying to reload, we then get the current weapon. If the current weapon does not equal ``null``, we call its ``reload_weapon`` function.
 
 .. note:: If the current weapon is equal to ``null``, then the current weapon is ``UNARMED``.
 
-Finally, we set ``reloading_weapon`` to ``false``, because regardless of whether we've successfully reloaded, we've tried reloading
+Finally, we set ``reloading_weapon`` to ``false``, because regardless of whether the player successfully reloaded, we've tried reloading
 and no longer need to keep trying.
 
 _______
 
-Before we can reload, we need to change a few things in ``process_input``.
+Before we can let the player reload, we need to change a few things in ``process_input``.
 
-The first thing we need to change is in the code for changing weapons. We need to add a additional check (``if reloading_weapon == false:``) to see if we are reloading:
+The first thing we need to change is in the code for changing weapons. We need to add a additional check (``if reloading_weapon == false:``) to see if the player is reloading:
 
 ::
     
@@ -383,7 +380,7 @@ The first thing we need to change is in the code for changing weapons. We need t
                 changing_weapon_name = WEAPON_NUMBER_TO_NAME[weapon_change_number]
                 changing_weapon = true
 
-This makes it where we cannot change weapons if we are reloading.
+This makes it where the player cannot change weapons if the player is reloading.
 
 Now we need to add the code to trigger a reload when the player pushes the ``reload`` action. Add the following code to ``process_input``:
 
@@ -410,24 +407,24 @@ Now we need to add the code to trigger a reload when the player pushes the ``rel
 
 Let's go over what's happening here.
 
-First we make sure we're not reloading already, nor are we trying to change weapons.
+First we make sure the player is not reloading already, nor is the player trying to change weapons.
 
 Then we check to see if the ``reload`` action has been pressed.
 
-If we have pressed ``reload``, we then get the current weapon and check to make sure it is not ``null``. Then we check to see if the
+If the player has pressed ``reload``, we then get the current weapon and check to make sure it is not ``null``. Then we check to see if the
 weapon can reload or not using its ``CAN_RELOAD`` constant.
 
-If the weapon can reload, we then get the current animation state, and make a variable for tracking whether we are already reloading or not.
+If the weapon can reload, we then get the current animation state, and make a variable for tracking whether the player is already reloading or not.
 
-We then go through every weapon to make sure we're not already playing that weapon's reloading animation.
+We then go through every weapon to make sure the player is not already playing that weapon's reloading animation.
 
-If we are not reloading with any weapon, we set ``reloading_weapon`` to ``true``.
+If the player is not reloading with any weapon, we set ``reloading_weapon`` to ``true``.
 
 _______
 
-One thing I like to add is where the weapon will reload itself if you try to fire it when it's out of ammo.
+One thing I like to add is where the weapon will reload itself if you try to fire it and it's out of ammo.
 
-We also need to add a additional if check (``is_reloading_weapon == false:``) so we cannot fire the current weapon while
+We also need to add a additional if check (``is_reloading_weapon == false:``) so the player cannot fire the current weapon while
 reloading.
 
 Let's change our firing code in ``process_input`` so it reloads when trying to fire an empty weapon:
@@ -448,20 +445,19 @@ Let's change our firing code in ``process_input`` so it reloads when trying to f
                         reloading_weapon = true
     # ----------------------------------
 
-Now we check to make sure we're not reloading before we fire out weapon, and when we have ``0`` or less ammo in our weapon
-we set ``reloading_weapon`` to ``true`` if we try to fire.
+Now we check to make sure the player is not reloading before we fire the weapon, and when we have ``0`` or less ammo in the current weapon
+we set ``reloading_weapon`` to ``true`` if the player tries to fire.
 
-This will make it where we will try to reload when we try to fire a empty weapon.
+This will make it where the player will try to reload when the player tries to fire a empty weapon.
     
 _______
     
-With that we can reload our weapons! Give it a try! Now you can fire all of the spare ammo for each weapon.
+With that done, the player can now reload! Give it a try! Now you can fire all of the spare ammo for each weapon.
     
 Adding sounds
 -------------
 
-Finally, let's add some sounds that play when we are reloading, changing guns, and when we
-are firing them.
+Finally, let's add some sounds that play when the player is reloading, changing weapons, and when the player is firing.
 
 .. tip:: There are no game sounds provided in this tutorial (for legal reasons).
          https://gamesounds.xyz/ is a collection of **"royalty free or public domain music and sounds suitable for games"**.
@@ -538,7 +534,7 @@ Let's go over what's happening here:
 
 _________
 
-In ``_ready`` we get the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` and connect its ``finished`` signal to ourselves.
+In ``_ready`` we get the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` and connect its ``finished`` signal to the ``destroy_self`` function.
 It doesn't matter if it's a :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` or :ref:`AudioStreamPlayer3D <class_AudioStreamPlayer3D>` node,
 as they both have the finished signal. To make sure it is not playing any sounds, we call ``stop`` on the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>`.
 
@@ -546,10 +542,10 @@ as they both have the finished signal. To make sure it is not playing any sounds
              the sounds will continue to play infinitely and the script will not work!
 
 The ``play_sound`` function is what we will be calling from ``Player.gd``. We check if the sound
-is one of the three possible sounds, and if it is we set the audio stream for our :ref:`AudioStreamPlayer <class_AudioStreamPlayer>`
+is one of the three possible sounds, and if it is one of the three sounds we set the audio stream in :ref:`AudioStreamPlayer <class_AudioStreamPlayer>`
 to the correct sound.
 
-If it is an unknown sound, we print an error message to the console and free ourselves.
+If it is an unknown sound, we print an error message to the console and free the audio player.
 
 If you are using a :ref:`AudioStreamPlayer3D <class_AudioStreamPlayer3D>`, remove the ``#`` to set the position of
 the audio player node so it plays at the correct position.
@@ -557,7 +553,7 @@ the audio player node so it plays at the correct position.
 Finally, we tell the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` to play.
 
 When the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` is finished playing the sound, it will call ``destroy_self`` because
-we connected the ``finished`` signal in ``_ready``. We stop the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` and free ourself
+we connected the ``finished`` signal in ``_ready``. We stop the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` and free the audio player
 to save on resources.
 
 .. note:: This system is extremely simple and has some major flaws:
@@ -567,8 +563,8 @@ to save on resources.
           Ideally we'd place these sounds in some sort of container with exposed variables so we do not have
           to remember the name(s) of each sound effect we want to play.
 
-          Another flaw is we cannot play looping sounds effects, nor background music easily with this system.
-          Because we cannot play looping sounds, certain effects like footstep sounds are harder to accomplish
+          Another flaw is we cannot play looping sounds effects, nor background music, easily with this system.
+          Because we cannot play looping sounds, certain effects, like footstep sounds, are harder to accomplish
           because we then have to keep track of whether or not there is a sound effect and whether or not we
           need to continue playing it.
           
@@ -578,7 +574,7 @@ to save on resources.
 _________
 
 With that done, let's open up ``Player.gd`` again.
-First we need to load the ``SimpleAudioPlayer.tscn``. Place the following code in your global variables:
+First we need to load the ``SimpleAudioPlayer.tscn``. Place the following code in the class variables:
 
 ::
 
@@ -586,7 +582,7 @@ First we need to load the ``SimpleAudioPlayer.tscn``. Place the following code i
 
 Now we need to instance the simple audio player when we need it, and then call its
 ``play_sound`` function and pass the name of the sound we want to play. To make the process simpler,
-let's create a ``create_sound`` function:
+let's create a ``create_sound`` function in ``Player.gd``:
 
 ::
 
@@ -603,20 +599,22 @@ _________
 The first line instances the ``Simple_Audio_Player.tscn`` scene and assigns it to a variable,
 named ``audio_clone``.
 
-The second line gets the scene root, using one large assumption. We first get this node's :ref:`SceneTree <class_SceneTree>`,
+The second line gets the scene root, and this has a large (though safe) assumption.
+
+We first get this node's :ref:`SceneTree <class_SceneTree>`,
 and then access the root node, which in this case is the :ref:`Viewport <class_Viewport>` this entire game is running under.
 Then we get the first child of the :ref:`Viewport <class_Viewport>`, which in our case happens to be the root node in
-``Test_Area.tscn`` or any of the other provided levels. We are making a huge assumption that the first child of the root
-is the root node that our player is under, which could not always be the case.
+``Test_Area.tscn`` or any of the other provided levels. **We are making a huge assumption that the first child of the root node
+is the root scene that the player is under, which may not always be the case**.
 
-If this doesn't make sense to you, don't worry too much about it. The second line of code only doesn't work
-reliably if you have multiple scenes loaded as children to the root node at a time, which will rarely happen for most projects.
+If this doesn't make sense to you, don't worry too much about it. The second line of code only does not work
+reliably if you have multiple scenes loaded as children to the root node at a time, which will rarely happen for most projects and will not be happening in this tutorial series.
 This is only potentially a issue depending on how you handle scene loading.
 
 The third line adds our newly created ``SimpleAudioPlayer`` scene to be a child of the scene root. This
 works exactly the same as when we are spawning bullets.
 
-Finally, we call the ``play_sound`` function and pass in the arguments we're given. This will call
+Finally, we call the ``play_sound`` function and pass in the arguments passed in to ``create_sound``. This will call
 ``SimpleAudioPlayer.gd``'s ``play_sound`` function with the passed in arguments.
 
 _________
@@ -625,22 +623,22 @@ Now all that is left is playing the sounds when we want to. Let's add sound to t
 
 Open up ``Weapon_Pistol.gd``.
 
-Now, we want to make a noise when we fire the pistol, so add the following to the end of the ``fire_weapon`` function:
+Now, we want to make a noise when the player fires the pistol, so add the following to the end of the ``fire_weapon`` function:
 
 ::
     
     player_node.create_sound("pistol_shot", self.global_transform.origin)
 
-Now when we fire our pistol, we'll play the ``pistol_shot`` sound.
+Now when the player fires the pistol, we'll play the ``pistol_shot`` sound.
 
-To make a sound when we reload, we need to add the following right under ``player_node.animation_manager.set_animation(RELOADING_ANIM_NAME)`` in the
+To make a sound when the player reloads, we need to add the following right under ``player_node.animation_manager.set_animation(RELOADING_ANIM_NAME)`` in the
 ``reload_weapon`` function:
 
 ::
     
     player_node.create_sound("gun_cock", player_node.camera.global_transform.origin)
 
-Now when we reload we'll play the ``gun_cock`` sound.
+Now when the player reloads, we'll play the ``gun_cock`` sound.
 
 _________
 
@@ -653,16 +651,16 @@ To play sounds when the rifle is fired, add the following to the end of the ``fi
     
     player_node.create_sound("rifle_shot", ray.global_transform.origin)
 
-Now when we fire our rifle, we'll play the ``rifle_shot`` sound.
+Now when the player fires the rifle, we'll play the ``rifle_shot`` sound.
 
-To make a sound when we reload, we need to add the following right under ``player_node.animation_manager.set_animation(RELOADING_ANIM_NAME)`` in the
+To make a sound when the player reloads, we need to add the following right under ``player_node.animation_manager.set_animation(RELOADING_ANIM_NAME)`` in the
 ``reload_weapon`` function:
 
 ::
     
     player_node.create_sound("gun_cock", player_node.camera.global_transform.origin)
 
-Now when we reload we'll play the ``gun_cock`` sound.
+Now when the player reloads, we'll play the ``gun_cock`` sound.
 
 Final notes
 -----------

tutorials/3d/fps_tutorial/part_two.rst

@@ -154,7 +154,7 @@ Lets go over what this script is doing:
 
 _________
 
-Lets start with this script's global variables:
+Lets start with this script's class variables:
 
 - ``states``: A dictionary for holding our animation states. (Further explanation below)
 - ``animation_speeds``: A dictionary for holding all of the speeds we want to play our animations at.
@@ -165,11 +165,11 @@ If you are familiar with state machines, then you may have noticed that ``states
 like a basic state machine. Here is roughly how ``states`` is set up:
 
 ``states`` is a dictionary with the key being the name of the current state, and the value being
-an array holding all of the states we can transition to. For example, if we are in currently in
+an array holding all of the animations (states) we can transition to. For example, if we are in currently in
 state ``Idle_unarmed``, we can only transition to ``Knife_equip``, ``Pistol_equip``, ``Rifle_equip``, and
 ``Idle_unarmed``.
 
-If we try to transition to a state that is not included in our possible transitions states,
+If we try to transition to a state that is not included in the possible transitions states for the state we are in,
 then we get a warning message and the animation does not change. We can also automatically
 transition from some states into others, as will be explained further below in ``animation_ended``
 
@@ -188,7 +188,7 @@ and in an effort to make everything look smooth, we need to play them at faster
 
 ``current_state`` will hold the name of the animation state we are currently in.
 
-Finally, ``callback_function`` will be a :ref:`FuncRef <class_FuncRef>` passed in by our player for spawning bullets
+Finally, ``callback_function`` will be a :ref:`FuncRef <class_FuncRef>` passed in by the player for spawning bullets
 at the proper frame of animation. A :ref:`FuncRef <class_FuncRef>` allows us to pass in a function as an argument,
 effectively allowing us to call a function from another script, which is how we will use it later.
 
@@ -244,7 +244,7 @@ Now lets look at ``animation_ended``.
 
 
 For certain animation states, we may need to transition into another state when its finished. To handle this, we
-check for every possible animation state. If we need to, we transition into another state.
+check for every possible animation state. If we need to, we will transition into another state.
 
 .. warning:: If you are using your own animated models, make sure that none of the animations are set
              to loop. Looping animations do not send the ``animation_finished`` signal when they reach
@@ -483,7 +483,7 @@ Here's the script that will control our bullet:
     func collided(body):
         if hit_something == false:
             if body.has_method("bullet_hit"):
-                body.bullet_hit(BULLET_DAMAGE, self.global_transform.origin)
+                body.bullet_hit(BULLET_DAMAGE, global_transform)
 
         hit_something = true
         queue_free()
@@ -493,7 +493,7 @@ Lets go through the script:
 
 _________
 
-First we define a few global variables:
+First we define a few class variables:
 
 - ``BULLET_SPEED``: The speed the bullet travels at.
 - ``BULLET_DAMAGE``: The damage the bullet will cause to whatever it collides with.
@@ -508,7 +508,7 @@ change how the bullet interacts with the world.
           get a bullet travelling forever. By using a kill timer, we can assure that
           no bullets will travel forever and consume resources.
 
-.. tip:: As in :ref:`doc_fps_tutorial_part_one`, we have a couple all uppercase global variables. The reason behind this is the same
+.. tip:: As in :ref:`doc_fps_tutorial_part_one`, we have a couple all uppercase class variables. The reason behind this is the same
          as the reason given in :ref:`doc_fps_tutorial_part_one`: We want to treat these variables like constants, but we want to be
          able to change them. In this case we will later need to change the damage and speed of these bullets,
          so we need them to be variables and not constants.
@@ -533,14 +533,15 @@ _________
 In ``collided`` we check if we've hit something yet or not.
 
 Remember that ``collided`` is only called when a body has entered the :ref:`Area <class_Area>` node.
-If we have not already collided with something, we then proceed to check if the body we've collided
-with has a function/method called ``bullet_hit``. If it does, we call it and pass in our damage and our position.
+If the bullet has not already collided with something, we then proceed to check if the body the bullet has collided
+with has a function/method called ``bullet_hit``. If it does, we call it and pass in the bullet's damage and the bullet's global transform
+so we can get the bullet's rotation and position.
 
 .. note:: in ``collided``, the passed in body can be a :ref:`StaticBody <class_StaticBody>`,
           :ref:`RigidBody <class_RigidBody>`, or :ref:`KinematicBody <class_KinematicBody>`
 
-We set ``hit_something`` to ``true`` because regardless of whether or not the body
-the bullet collided with has the ``bullet_hit`` function/method, it has hit something and so we need to not hit anything else.
+We set the Bullet's ``hit_something`` variable to ``true`` because regardless of whether or not the body
+the bullet collided with has the ``bullet_hit`` function/method, it has hit something and so we need to make sure the bullet does not hit anything else.
 
 Then we free the bullet using ``queue_free``.
 
@@ -665,7 +666,7 @@ Let's go over how the script works.
 
 _________
 
-First we define some global variables we'll need in the script:
+First we define some class variables we'll need in the script:
 
 * ``DAMAGE``: The amount of damage a single bullet does.
 * ``IDLE_ANIM_NAME``: The name of the pistol's idle animation.
@@ -726,16 +727,16 @@ _________
 Now let's look at ``equip_weapon``:
 
 The first thing we do is check to see if the animation manager is in the pistol's idle animation.
-If we are in the pistol's idle animation, we set ``is_weapon_enabled`` to ``true`` and return ``true`` because we have successfully
+If we are in the pistol's idle animation, we set ``is_weapon_enabled`` to ``true`` and return ``true`` because the pistol has successfully
 been equipped.
 
 Because we know our pistol's ``equip`` animation automatically transitions to the pistol's idle animation, if we are in the pistol's
-idle animation we most have finished playing the equip animation.
+idle animation the pistol most have finished playing the equip animation.
 
 .. note:: We know these animations will transition because we wrote to the code to make them transition in ``Animation_Manager.gd``
 
-Next we check to see if we are in the ``Idle_unarmed`` animation state. Because all unequipping animations go to this state, and because any
-weapon can be equipped from this state, we change animations to ``Pistol_equip`` if we are in ``Idle_unarmed``.
+Next we check to see if the player is in the ``Idle_unarmed`` animation state. Because all unequipping animations go to this state, and because any
+weapon can be equipped from this state, we change animations to ``Pistol_equip`` if the player is in the ``Idle_unarmed`` state.
 
 Since we know ``Pistol_equip`` will transition to ``Pistol_idle``, we do not need to do any more additional processing for equipping weapons,
 but since we were not able to equip the pistol yet, we return ``false``.
@@ -746,17 +747,17 @@ Finally, let's look at ``unequip_weapon``:
 
 ``unequip_weapon`` is similar to ``equip_weapon``, but instead we're checking things in reverse.
 
-First we check to see if we are in our idle animation. Then check to make sure we are not in the ``Pistol_unequip`` animation.
-If we are not in the ``Pistol_unequip`` animation, we want to play ``pistol_unequip``.
+First we check to see if the player is in the idle animation state. Then we check to make sure the player is not in the ``Pistol_unequip`` animation.
+If the player is not in the ``Pistol_unequip`` animation, we want to play ``pistol_unequip`` animation.
 
-.. note:: You may be wondering why we are checking to see if we are the pistol's idle animation, and then making sure we are not unequipping right after.
+.. note:: You may be wondering why we are checking to see if the player is in the pistol's idle animation, and then making sure the player is not unequipping right after.
           The reason behind the additional check is because we could (in rare cases) call ``unequip_weapon`` twice before we've had a chance to process ``set_animation``,
           so we add this additional check to make sure the unequip animation plays.
 
-Next we check to see if we are in ``Idle_unarmed``, which is the animation state we will transition into from ``Pistol_unequip``. If we are, then we set
-``is_weapon_enabled`` to false since we are no longer using this weapon, and return ``true`` because we have successfully unequipped the pistol.
+Next we check to see if the player is in ``Idle_unarmed``, which is the animation state we will transition into from ``Pistol_unequip``. If the player is are, then we set
+``is_weapon_enabled`` to ``false`` since we are no longer using this weapon, and return ``true`` because we have successfully unequipped the pistol.
 
-If we are not in ``Idle_unarmed``, we return ``false`` because we have not yet successfully unequipped the pistol.
+If the player is not in ``Idle_unarmed``, we return ``false`` because we have not yet successfully unequipped the pistol.
 
 Creating the other two weapons
 ------------------------------
@@ -792,7 +793,7 @@ then add the following:
             if body == player_node:
                 pass
             elif body.has_method("bullet_hit"):
-                body.bullet_hit(DAMAGE, ray.get_collision_point())
+                body.bullet_hit(DAMAGE, ray.global_transform)
 
     func equip_weapon():
         if player_node.animation_manager.current_state == IDLE_ANIM_NAME:
@@ -820,18 +821,18 @@ Most of this is exactly the same as ``Weapon_Pistol.gd``, so we're only going to
 
 The first thing we do is get the :ref:`Raycast <class_Raycast>` node, which is a child of ``Rifle_Point``.
 
-Next we force the raycast to update using ``force_raycast_update``. This will force the raycast to detect collisions when we call it, meaning
+Next we force the :ref:`Raycast <class_Raycast>` to update using ``force_raycast_update``. This will force the :ref:`Raycast <class_Raycast>` to detect collisions when we call it, meaning
 we get a frame perfect collision check with the 3D physics world.
 
-Then we check to see if the raycast collided with something.
+Then we check to see if the :ref:`Raycast <class_Raycast>` collided with something.
 
-If the raycast has collided with something, we first get the collision body it collided with. This can be a :ref:`StaticBody <class_StaticBody>`,
+If the :ref:`Raycast <class_Raycast>` has collided with something, we first get the collision body it collided with. This can be a :ref:`StaticBody <class_StaticBody>`,
 :ref:`RigidBody <class_RigidBody>`, or a :ref:`KinematicBody <class_KinematicBody>`.
 
 Next we want to make sure the body we've collided with is not the player, since we (probably) do not want to give the player the ability to shoot themselves in the foot.
 
 If the body is not the player, we then check to see if they have a function/method called ``bullet_hit``. If they do, we call it and pass in the amount of
-damage this bullet does (``DAMAGE``), and the point where the raycast collided with the body.
+damage this bullet does (``DAMAGE``), and the global transform of the :ref:`Raycast <class_Raycast>` so we can tell which direction the bullet came from.
 
 _________
 
@@ -865,7 +866,7 @@ then add the following:
                 continue
 
             if body.has_method("bullet_hit"):
-                body.bullet_hit(DAMAGE, area.global_transform.origin)
+                body.bullet_hit(DAMAGE, area.global_transform)
 
     func equip_weapon():
         if player_node.animation_manager.current_state == IDLE_ANIM_NAME:
@@ -892,19 +893,19 @@ As with ``Weapon_Rifle.gd``, the only differences are in ``fire_weapon``, so let
 
 The first thing we do is get the :ref:`Area <class_Area>` child node of ``Knife_Point``.
 
-Next we want to get all of the collision bodies inside the area using ``get_overlapping_bodies``. This will return a
-list of every body that touches the area.
+Next we want to get all of the collision bodies inside the :ref:`Area <class_Area>` using ``get_overlapping_bodies``. This will return a
+list of every body that touches the :ref:`Area <class_Area>`.
 
 We next want to go through each of those bodies.
 
-First we check to make sure the body is not the player, because we do not want to be able to stab ourselves. If the body is the player,
+First we check to make sure the body is not the player, because we do not want to let the player be able to stab themselves. If the body is the player,
 we use ``continue`` so we jump to looking at the next body in ``bodies``.
 
 If we have not jumped to the next body, we then check to see if the body has the ``bullet_hit`` function/method. If it does,
-we call it, passing in the amount of damage a single knife swipe does (``DAMAGE``) and the position of the :ref:`Area <class_Area>`.
+we call it, passing in the amount of damage a single knife swipe does (``DAMAGE``) and the global transform of the :ref:`Area <class_Area>`.
 
-.. note:: While we could attempt to calculate a rough location for where the knife hit, we
-          do not bother because using the area's position works well enough and the extra time
+.. note:: While we could attempt to calculate a rough location for where the knife hit exactly, we
+          are not going to because using the :ref:`Area <class_Area>`'s position works well enough and the extra time
           needed to calculate a rough position for each body is not worth the effort.
 
 Making the weapons work
@@ -912,7 +913,7 @@ Making the weapons work
 
 Lets start making the weapons work in ``Player.gd``.
 
-First lets start by adding some global variables we'll need for the weapons:
+First lets start by adding some class variables we'll need for the weapons:
 
 ::
 
@@ -978,19 +979,19 @@ Next we need to add a few things in ``_ready``. Here's the new ``_ready`` functi
 
 Let's go over what's changed.
 
-First we get the :ref:`AnimationPlayer <class_AnimationPlayer>` node and assign it to our animation_manager variable. Then we set the callback function
-to a :ref:`FuncRef <class_FuncRef>` that will call the player's ``fire_bullet`` function. Right now we haven't written our fire_bullet function,
+First we get the :ref:`AnimationPlayer <class_AnimationPlayer>` node and assign it to the ``animation_manager`` variable. Then we set the callback function
+to a :ref:`FuncRef <class_FuncRef>` that will call the player's ``fire_bullet`` function. Right now we haven't written the ``fire_bullet`` function,
 but we'll get there soon.
 
 Next we get all of the weapon nodes and assign them to ``weapons``. This will allow us to access the weapon nodes only with their name
 (``KNIFE``, ``PISTOL``, or ``RIFLE``).
 
-We then get ``Gun_Aim_Point``'s global position so we can rotate our weapons to aim at it.
+We then get ``Gun_Aim_Point``'s global position so we can rotate the player's weapons to aim at it.
 
 Then we go through each weapon in ``weapons``.
 
-We first get the weapon node. If the weapon node is not ``null``, we then set it's ``player_node`` variable to ourself.
-Then we have it look at ``gun_aim_point_pos``, and then rotate it by ``180`` degrees on the ``Y`` axis.
+We first get the weapon node. If the weapon node is not ``null``, we then set it's ``player_node`` variable to this script (``Player.gd``).
+Then we have it look at ``gun_aim_point_pos`` using the ``look_at`` function, and then rotate it by ``180`` degrees on the ``Y`` axis.
 
 .. note:: We rotate all of those weapon points by ``180`` degrees on their ``Y`` axis because our camera is pointing backwards.
           If we did not rotate all of these weapon points by ``180`` degrees, all of the weapons would fire backwards.
@@ -1068,18 +1069,18 @@ Then we check to see if any of the number keys (keys 1-4) are pressed. If they a
 Next we check to see if ``shift_weapon_positive`` or ``shift_weapon_negative`` is pressed. If one of them are, we add/subtract ``1`` from
 ``weapon_change_number``.
 
-Because we may have shifted ``weapon_change_number`` outside of the number of weapons we have, we clamp it so it cannot exceed the maximum number of weapons we have
-and has to be ``0`` or more.
+Because the player may have shifted ``weapon_change_number`` outside of the number of weapons the player has, we clamp it so it cannot exceed the maximum number of weapons
+the player has and it ensures ``weapon_change_number`` is ``0`` or more.
 
-Then we check to make sure we are not already changing weapons. If we are not, we then check to see if the weapon we want to change to
-is a new weapon and not the one we are currently using. If the weapon we're wanting to change to is a new weapon, we then set ``changing_weapon_name`` to
+Then we check to make sure the player is not already changing weapons. If the player is not, we then check to see if the weapon the player wants to change to
+is a new weapon and not the weapon the player is currently using. If the weapon the player is wanting to change to is a new weapon, we then set ``changing_weapon_name`` to
 the weapon at ``weapon_change_number`` and set ``changing_weapon`` to true.
 
 For firing the weapon we first check to see if the ``fire`` action is pressed.
-Then we check to make sure we are not changing weapons.
+Then we check to make sure the player is not changing weapons.
 Next we get the weapon node for the current weapon.
 
-If the current weapon node does not equal null, and we are in it's ``IDLE_ANIM_NAME`` state, we set our animation
+If the current weapon node does not equal null, and the player is in it's ``IDLE_ANIM_NAME`` state, we set the player's animation
 to the current weapon's ``FIRE_ANIM_NAME``.
 
 _________
@@ -1124,33 +1125,35 @@ Add the following code:
 
 Lets go over what's happening here:
 
-The first thing we do is make sure we've recived input to change weapons. We do this by making sure ``changing_weapons`` is ``true``.
+The first thing we do is make sure we've revived input to change weapons. We do this by making sure ``changing_weapons`` is ``true``.
 
 Next we define a variable (``weapon_unequipped``) so we can check whether the current weapon has been successfully unequipped or not.
 
 Then we get the current weapon from ``weapons``.
 
 If the current weapon is not ``null``, then we have need to check to see if the weapon is enabled or not. If the weapon is enabled, we call it's ``unequip_weapon`` function
-so it will start the unequip animation. If the weapon is not enabled, we set ``weapon_unequippped`` to ``true``, because we the weapon has successfully been unequipped.
+so it will start the unequip animation. If the weapon is not enabled, we set ``weapon_unequippped`` to ``true`` because the weapon has successfully been unequipped.
 
 If the current weapon is ``null``, then we can simply set ``weapon_unequipped`` to ``true``. The reason we do this check is because there is no weapon script/node for
-``UNARMED``, but there is also no animations for ``UNARMED``, so we can just start equipping the weapon we want to change to.
+``UNARMED``, but there is also no animations for ``UNARMED``, so we can just start equipping the weapon the player wants to change to.
 
-If we have successfully unequipped the current weapon (``weapon_unequipped == true``), we need to equip the new weapon.
+If the player has successfully unequipped the current weapon (``weapon_unequipped == true``), we need to equip the new weapon.
 
-First we define a new variable (``weapon_equipped``) for tracking whether we have successfully equipped the new weapon or not.
+First we define a new variable (``weapon_equipped``) for tracking whether the player has successfully equipped the new weapon or not.
 
-Then we get the weapon we want to change to. If the weapon we want to change to is not ``null``, we then check to see whether or not it's enabled. If it is not enabled,
-we call it's ``equip_weapon`` function so it starts to equip the weapon. If the weapon is enabled, we set ``weapon_equipped`` to ``true``.
+Then we get the weapon the player wants to change to. If the weapon the player wants to change to is not ``null``, we then check to see whether or not it's enabled.
+If it is not enabled, we call it's ``equip_weapon`` function so it starts to equip the weapon. If the weapon is enabled, we set ``weapon_equipped`` to ``true``.
 
-If the weapon we want to change to is ``null``, we simply set ``weapon_equipped`` to ``true`` because we do not have any node/script for ``UNARMED``, nor do we have any animations.
+If the weapon the player wants to change to is ``null``, we simply set ``weapon_equipped`` to ``true`` because we do not have any node/script for ``UNARMED``,
+nor do we have any animations.
 
-Finally, we check to see if we have successfully equipped the new weapon. If we have, we set ``changing_weapon`` to false because we are no longer changing weapons.
+Finally, we check to see if the player has successfully equipped the new weapon. If the player has, we set ``changing_weapon`` to ``false`` because the player is no
+longer changing weapons.
 We also set ``current_weapon_name`` to ``changing_weapon_name``, since the current weapon has changed, and then we set ``changing_weapon_name`` to a empty string.
 
 _________
 
-Now, we need to add one more function to the player, and then the player is ready to start the weapons!
+Now, we need to add one more function to the player, and then the player is ready to start firing the weapons!
 
 We need to add ``fire_bullet``, which will be called when by the :ref:`AnimationPlayer <class_AnimationPlayer>` at those
 points we set earlier in the :ref:`AnimationPlayer <class_AnimationPlayer>` function track:
@@ -1166,13 +1169,13 @@ points we set earlier in the :ref:`AnimationPlayer <class_AnimationPlayer>` func
 
 Lets go over what this function is doing:
 
-First we check if we are changing weapons or not. If we are changing weapons, we do not want shoot so we ``return``.
+First we check if to see if the player is changing weapons or not. If the player is changing weapons, we do not want shoot so we ``return``.
 
 .. tip:: Calling ``return`` stops the rest of the function from being called. In this case, we are not returning a variable
          because we are only interested in not running the rest of the code, and because we are not looking for a returned
          variable either when we call this function.
 
-Then we tell the current weapon we are using to fire by calling its ``fire_weapon`` function.
+Then we tell the current weapon the player is using to fire by calling its ``fire_weapon`` function.
 
 .. tip:: Remember how we mentioned the speed of the animations for firing was faster than
          the other animations? By changing the firing animation speeds, you can change how
@@ -1194,31 +1197,37 @@ Now we need to add this code:
 
     extends RigidBody
 
+    const BASE_BULLET_BOOST = 9;
+
     func _ready():
         pass
 
-    func bullet_hit(damage, bullet_hit_pos):
-        var direction_vect = global_transform.origin - bullet_hit_pos
-        direction_vect = direction_vect.normalized()
-
-        apply_impulse(bullet_hit_pos, direction_vect * damage)
+    func bullet_hit(damage, bullet_global_trans):
+        var direction_vect = bullet_global_trans.basis.z.normalized() * BASE_BULLET_BOOST;
+        
+        apply_impulse((bullet_global_trans.origin - global_transform.origin).normalized(), direction_vect * damage)
 
 
 Lets go over how ``bullet_hit`` works:
 
-First we get the direction from the bullet pointing towards our global :ref:`Transform <class_Transform>`.
-We do this by subtracting the bullet's hit position from the :ref:`RigidBody <class_RigidBody>`'s position.
-This results in a :ref:`Vector3 <class_Vector3>` that we can use to tell the direction the bullet collided into the
-:ref:`RigidBody <class_RigidBody>` at.
 
-We then normalize it so we do not get crazy results from collisions on the extremes
-of the collision shape attached to the :ref:`RigidBody <class_RigidBody>`. Without normalizing shots farther
-away from the center of the :ref:`RigidBody <class_RigidBody>` would cause a more noticeable reaction than
-those closer to the center.
+First we get the bullet's forward directional vector. This is so we can tell which direction the bullet will hit the :ref:`RigidBody <class_RigidBody>` at.
+We will use this to push the :ref:`RigidBody <class_RigidBody>` in the same direction as the bullet.
+
+.. note:: We need to boost the directional vector by ``BASE_BULLET_BOOST`` so the bullet's back a bit more of a punch
+          and move the :ref:`RigidBody <class_RigidBody>` nodes in a visible way. You can just ``BASE_BULLET_BOOST`` to lower or higher values if you want
+          less or more of a reaction when the bullets collide with the :ref:`RigidBody <class_RigidBody>`.
+
+Then we apply a impulse using ``apply_impulse``.
+
+First, we need to calculate the position for the impulse.
+Because ``apply_impulse`` takes a vector relative to the :ref:`RigidBody <class_RigidBody>`, we need to calculate the distance from
+the :ref:`RigidBody <class_RigidBody>` to the bullet. We do this by subtracting the :ref:`RigidBody <class_RigidBody>`'s global origin/position from the bullet's global origin/position.
+This gets us the distance from the :ref:`RigidBody <class_RigidBody>` to the bullet. We normalize this vector so the size of the collider does not effect how much
+the bullets move the :ref:`RigidBody <class_RigidBody>`.
 
-Finally, we apply an impulse at the passed in bullet collision position. With the force
-being the directional vector times the damage the bullet is supposed to cause. This makes
-the :ref:`RigidBody <class_RigidBody>` seem to move in response to the bullet colliding into it.
+Finally, we need to calculate the force for the impulse. For this we use the bullet is facing and multiply it by the bullet's damage.
+This gives a nice result and for stronger bullets, we get a stronger result.
 
 _______