Repaired mistyped of 'its'.

development/file_formats/tscn.rst

@@ -28,7 +28,7 @@ There are five main sections inside the TSCN File:
 
 The file descriptor looks like :code:`[gd_scene load_steps=1 format=2]` And 
 should be the first entry in the file. The load_steps parameter should (in 
-theory) be the number of resources within the file, though in practice it's 
+theory) be the number of resources within the file, though in practice its 
 value seems not to matter.
 
 These sections should appear in order, but it can be hard to distinguish 
@@ -62,7 +62,7 @@ The scene tree
 --------------
 
 The scene tree is made up of... nodes! The heading of each node consists of
-it's name, parent and (most of the time) a type. For example
+its name, parent and (most of the time) a type. For example
 :code:`[node type="Camera" name="PlayerCamera" parent="Player/Head"]`
 
 Other valid keywords include:

getting_started/workflow/assets/escn_exporter/physics.rst

@@ -34,7 +34,7 @@ There are the following caveats:
    Godot
  - In Godot, you can have different collision groups and collision masks. In
    Blender you only have collision groups. As a result, the exported object's
-   collision mask is equal to it's collision group. Most of the time, this is
+   collision mask is equal to its collision group. Most of the time, this is
    what you want.
 
 .. important::

tutorials/2d/using_tilemaps.rst

@@ -178,6 +178,6 @@ one that looks better for you:
 -  Enable pixel snap (Set ``Project > Project Settings >
    Rendering > Quality > 2d > Use Pixel Snap`` to true, you can also search for ``Pixel Snap``).
 -  Viewport Scaling can often help with shrinking the map (see the
-   :ref:`doc_viewports` tutorial). Simply adding a camera, setting it to ``Current`` and playing around with it's ``Zoom`` may be a good starting point.
+   :ref:`doc_viewports` tutorial). Simply adding a camera, setting it to ``Current`` and playing around with its ``Zoom`` may be a good starting point.
 -  You can use a single, separate image for each tile. This will remove all artifacts but
    can be more cumbersome to implement and is less optimized.

tutorials/3d/baked_lightmaps.rst

@@ -170,7 +170,7 @@ More subdivision results in more detail but also takes more time to bake.
 
 In general, the defaults are good enough. There is also a **Capture Subdivision**
 (that must always be equal or less to the main subdivision), which is used
-for capturing light in dynamic objects (more on that later). It's default value
+for capturing light in dynamic objects (more on that later). Its default value
 is also good enough for more cases.
 
 .. image:: img/baked_light_capture.png

tutorials/3d/fps_tutorial/part_four.rst

@@ -340,7 +340,7 @@ have a single :ref:`MeshInstance <class_MeshInstance>` as their children.
 
 Next expand ``Health_Pickup_Trigger``. This is an :ref:`Area <class_Area>` node we're going to use to check if the player has walked close enough to pick up
 the health kit. If you expand it you'll find two collision shapes, one for each size. We will be using a different collision shape size based on the size of the
-health pick up, so the smaller health pick up has a trigger collision shape closer to it's size.
+health pick up, so the smaller health pick up has a trigger collision shape closer to its size.
 
 The last thing to note is how we have a :ref:`AnimationPlayer <class_AnimationPlayer>` node so the health kit spins around slowly and bobs up and down.
 
@@ -738,7 +738,7 @@ The first thing we do is remove all children in the broken target holder. We do
 
 Next we enable the collision shape by setting its ``disabled`` boolean to ``false``.
 
-Then we make the target, and all of it's children nodes, visible again.
+Then we make the target, and all of its children nodes, visible again.
 
 Finally, we reset the target's health (``current_health``) to ``TARGET_HEALTH``.
 

tutorials/3d/fps_tutorial/part_one.rst

@@ -320,7 +320,7 @@ want the player's previous input to effect the player beyond a single ``process_
 
 Next we get the camera's global transform and store it as well, into the ``cam_xform`` variable.
 
-The reason we need the camera's global transform is so we can use it's directional vectors.
+The reason we need the camera's global transform is so we can use its directional vectors.
 Many have found directional vectors confusing, so let's take a second to explain how they work:
 
 _________

tutorials/3d/fps_tutorial/part_six.rst

@@ -165,7 +165,7 @@ If the ``back`` button has been pressed, we change the currently visible panels
 
 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.
+Then we tell the singleton to change nodes using its ``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!
 
@@ -175,7 +175,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 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.
+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 its current value.
 
 If the ``vsync`` button is pressed we set the :ref:`OS <class_OS>`'s Vsync based on the state of the Vsync check button.
 
@@ -431,7 +431,7 @@ have a ``popup`` open by checking to see if ``popup`` is equal to ``null``.
 
 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.
+We then get the quit button and assign its ``pressed`` signal to ``popup_quit``, which we will be adding shortly.
 
 Next we assign both the ``popup_hide`` signal from the :ref:`WindowDialog <class_WindowDialog>` and the ``pressed`` signal from the resume button
 to ``popup_closed``, which we will be adding shortly.
@@ -679,9 +679,9 @@ We then enable both of the player's collision shapes so the player can collide a
 
 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, which we will add soon.
+We then go through each weapon and call its ``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``.
+Then we reset ``health`` to ``100``, ``grenade_amounts`` to its default values, and change ``current_grenade`` to ``Grenade``.
 This effectively resets these variables to their default values.
 
 Finally, we set ``is_dead`` to ``false``.
@@ -794,7 +794,7 @@ Now all we need is a way to set the respawn points. Open up ``Ruins_Level.tscn``
         var globals = get_node("/root/Globals")
         globals.respawn_points = get_children()
         
-Now when a node with ``Respawn_Point_Setter.gd`` has it's ``_ready`` function called, all of the children
+Now when a node with ``Respawn_Point_Setter.gd`` has its ``_ready`` function called, all of the children
 nodes of the node with ``Respawn_Point_Setter.gd``, ``Spawn_Points`` in the case of ``Ruins_Level.tscn``, will be added
 to ``respawn_points`` in ``Globals.gd``.
 

tutorials/3d/fps_tutorial/part_three.rst

@@ -463,7 +463,7 @@ Finally, let's add some sounds that play when the player is reloading, changing
          https://gamesounds.xyz/ is a collection of **"royalty free or public domain music and sounds suitable for games"**.
          I used Gamemaster's Gun Sound Pack, which can be found in the Sonniss.com GDC 2017 Game Audio Bundle.
 
-Open up ``Simple_Audio_Player.tscn``. It is simply a :ref:`Spatial <class_Spatial>` with a :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` as it's child.
+Open up ``Simple_Audio_Player.tscn``. It is simply a :ref:`Spatial <class_Spatial>` with a :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` as its child.
 
 .. note:: The reason this is called a 'simple' audio player is because we are not taking performance into account
           and because the code is designed to provide sound in the simplest way possible.

tutorials/3d/fps_tutorial/part_two.rst

@@ -400,7 +400,7 @@ because they generally bounce around the world before exploding.
 Another disadvantage with bullet objects is networking. Bullet objects have to sync the positions (at least) with all the clients that are connected
 to the server.
 
-While we are not implementing any form of networking (as that would be it's own entire tutorial series), it is a consideration
+While we are not implementing any form of networking (as that would be in its own entire tutorial series), it is a consideration
 to keep in mind when creating your first person shooter, especially if you plan on adding some form of networking in the future.
 
 _________
@@ -992,7 +992,7 @@ We then get ``Gun_Aim_Point``'s global position so we can rotate the player's we
 
 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 this script (``Player.gd``).
+We first get the weapon node. If the weapon node is not ``null``, we then set its ``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.
@@ -1082,7 +1082,7 @@ For firing the weapon we first check to see if the ``fire`` action is pressed.
 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 the player is in it's ``IDLE_ANIM_NAME`` state, we set the player's animation
+If the current weapon node does not equal null, and the player is in its ``IDLE_ANIM_NAME`` state, we set the player's animation
 to the current weapon's ``FIRE_ANIM_NAME``.
 
 _________
@@ -1133,7 +1133,7 @@ Next we define a variable (``weapon_unequipped``) so we can check whether the cu
 
 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
+If the current weapon is not ``null``, then we need to check to see if the weapon is enabled or not. If the weapon is enabled, we call its ``unequip_weapon`` function
 so it will start the unequip animation. If the weapon is not enabled, we set ``weapon_unequipped`` 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
@@ -1143,8 +1143,8 @@ If the player has successfully unequipped the current weapon (``weapon_unequippe
 
 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 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``.
+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 it's enabled or not.
+If it is not enabled, we call its ``equip_weapon`` function so it starts to equip the weapon. If the weapon is enabled, we set ``weapon_equipped`` to ``true``.
 
 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.

tutorials/plugins/editor/import_plugins.rst

@@ -406,7 +406,7 @@ system is scanned, making the custom resource appear on the FileSystem dock. If
 you select it and focus the Import dock, you can see the only option to select
 there.
 
-Create a MeshInstance node in the scene and for it's Mesh property set up a new
+Create a MeshInstance node in the scene, and for its Mesh property set up a new
 SphereMesh. Unfold the Material section in the Inspector and then drag the file
 from the FileSystem dock to the material property. The object will update in the
 viewport with the blue color of the imported material.

tutorials/shading/screen-reading_shaders.rst

@@ -34,7 +34,7 @@ the current fragment. As a result, this simple 2D fragment shader:
 results in an invisible object, because it just shows what lies behind.
 
 The reason why textureLod must be used is because, when Godot copies back
-a chunk of the screen, it also does an efficient separatable gaussian blur to it's mipmaps.
+a chunk of the screen, it also does an efficient separatable gaussian blur to its mipmaps.
 
 This allows for not only reading from the screen, but reading from it with different amounts
 of blur at no cost.

tutorials/vr/vr_starter_tutorial.rst

@@ -817,7 +817,7 @@ Next, we need to add the ``remove_sphere`` function. Add the following to ``Game
 
 What this function does is it removes one from ``spheres_left``.
 
-Then it checks to see if ``sphere_ui`` is not null, and if it is not, then it calls it's ``update_ui`` function, passing in the amount of sphere's left.
+Then it checks to see if ``sphere_ui`` is not null, and if it is not, then it calls its ``update_ui`` function, passing in the amount of sphere's left.
 We'll add the UI code later in this part.
 
 Now that we have destroyable targets, we need a way to destroy them!
@@ -1160,7 +1160,7 @@ Let's go through what this script does, starting with the class variables:
 - ``fuse_timer``: A variable for tracking how long the fuse has been burning.
 - ``explosion_area``: The :ref:`Area <class_Area>` node used for detecting what nodes are inside the explosion.
 - ``EXPLOSION_DAMAGE``: The amount of damage the explosion does.
-- ``EXPLOSION_TIME``: The length of time the explosion :ref:`Particles <class_Particles>` take (you can calculate this number by multiplying the particles ``lifetime`` by it's ``speed scale``)
+- ``EXPLOSION_TIME``: The length of time the explosion :ref:`Particles <class_Particles>` take (you can calculate this number by multiplying the particles ``lifetime`` by its ``speed scale``)
 - ``explosion_timer``: A variable for tracking how long the explosion has lasted.
 - ``explode``: A boolean for tracking whether the bomb has exploded.
 - ``fuse_particles``: The fuse :ref:`Particles <class_Particles>` node.