From 034bb63e84cb2ce16364f08903bc2a8a04b4d1f9 Mon Sep 17 00:00:00 2001 From: "M. Huri" Date: Fri, 19 Oct 2018 14:36:56 +0700 Subject: [PATCH] Repaired mistyped of 'its'. --- development/file_formats/tscn.rst | 4 ++-- .../workflow/assets/escn_exporter/physics.rst | 2 +- tutorials/2d/using_tilemaps.rst | 2 +- tutorials/3d/baked_lightmaps.rst | 2 +- tutorials/3d/fps_tutorial/part_four.rst | 4 ++-- tutorials/3d/fps_tutorial/part_one.rst | 2 +- tutorials/3d/fps_tutorial/part_six.rst | 12 ++++++------ tutorials/3d/fps_tutorial/part_three.rst | 2 +- tutorials/3d/fps_tutorial/part_two.rst | 12 ++++++------ tutorials/plugins/editor/import_plugins.rst | 2 +- tutorials/shading/screen-reading_shaders.rst | 2 +- tutorials/vr/vr_starter_tutorial.rst | 4 ++-- 12 files changed, 25 insertions(+), 25 deletions(-) diff --git a/development/file_formats/tscn.rst b/development/file_formats/tscn.rst index e012f9ed7..66e3981ac 100644 --- a/development/file_formats/tscn.rst +++ b/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: diff --git a/getting_started/workflow/assets/escn_exporter/physics.rst b/getting_started/workflow/assets/escn_exporter/physics.rst index 66db79988..171f36ee6 100644 --- a/getting_started/workflow/assets/escn_exporter/physics.rst +++ b/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:: diff --git a/tutorials/2d/using_tilemaps.rst b/tutorials/2d/using_tilemaps.rst index f307d7357..00293b4e8 100644 --- a/tutorials/2d/using_tilemaps.rst +++ b/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. diff --git a/tutorials/3d/baked_lightmaps.rst b/tutorials/3d/baked_lightmaps.rst index dc7121743..bf40853ac 100644 --- a/tutorials/3d/baked_lightmaps.rst +++ b/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 diff --git a/tutorials/3d/fps_tutorial/part_four.rst b/tutorials/3d/fps_tutorial/part_four.rst index 530e7cc3b..81705e080 100644 --- a/tutorials/3d/fps_tutorial/part_four.rst +++ b/tutorials/3d/fps_tutorial/part_four.rst @@ -340,7 +340,7 @@ have a single :ref:`MeshInstance ` as their children. Next expand ``Health_Pickup_Trigger``. This is an :ref:`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 ` 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``. diff --git a/tutorials/3d/fps_tutorial/part_one.rst b/tutorials/3d/fps_tutorial/part_one.rst index 131bca0a4..a8b360d0d 100644 --- a/tutorials/3d/fps_tutorial/part_one.rst +++ b/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: _________ diff --git a/tutorials/3d/fps_tutorial/part_six.rst b/tutorials/3d/fps_tutorial/part_six.rst index dcb1060df..2189c57c0 100644 --- a/tutorials/3d/fps_tutorial/part_six.rst +++ b/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 ` 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 `'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 `'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 `'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 ` 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``. diff --git a/tutorials/3d/fps_tutorial/part_three.rst b/tutorials/3d/fps_tutorial/part_three.rst index c52709726..fb5c0e645 100644 --- a/tutorials/3d/fps_tutorial/part_three.rst +++ b/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 ` with a :ref:`AudioStreamPlayer ` as it's child. +Open up ``Simple_Audio_Player.tscn``. It is simply a :ref:`Spatial ` with a :ref:`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. diff --git a/tutorials/3d/fps_tutorial/part_two.rst b/tutorials/3d/fps_tutorial/part_two.rst index be40236fe..1d1ac3c2f 100644 --- a/tutorials/3d/fps_tutorial/part_two.rst +++ b/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. diff --git a/tutorials/plugins/editor/import_plugins.rst b/tutorials/plugins/editor/import_plugins.rst index 3659e1c02..f01d94393 100644 --- a/tutorials/plugins/editor/import_plugins.rst +++ b/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. diff --git a/tutorials/shading/screen-reading_shaders.rst b/tutorials/shading/screen-reading_shaders.rst index f00172df5..5e11a13e9 100644 --- a/tutorials/shading/screen-reading_shaders.rst +++ b/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. diff --git a/tutorials/vr/vr_starter_tutorial.rst b/tutorials/vr/vr_starter_tutorial.rst index 346efe8c4..cd51eb0f5 100644 --- a/tutorials/vr/vr_starter_tutorial.rst +++ b/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 ` 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 ` 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 ` 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 ` node.