diff --git a/about/faq.rst b/about/faq.rst index 9b7ce26b4..257e2af23 100644 --- a/about/faq.rst +++ b/about/faq.rst @@ -7,8 +7,8 @@ GDScript? Why your own scripting language? Why not Lua, Javascript, C#, etc.? ----------------------------------------------------------------------------- The short answer is, we'd rather a programmer does the small effort to -learn GDScript so he or she later has a seamless experience, than -attracting him or her with a familiar programming language that results +learn GDScript so they later have a seamless experience, than +attracting them with a familiar programming language that results in a worse experience. We are OK if you would rather not give Godot a chance because of this, but we strongly encourage you to try it and see the benefits yourself. diff --git a/classes/class_inputeventjoypadbutton.rst b/classes/class_inputeventjoypadbutton.rst index ba7aab891..b18980fcc 100644 --- a/classes/class_inputeventjoypadbutton.rst +++ b/classes/class_inputeventjoypadbutton.rst @@ -29,7 +29,7 @@ Member Variables .. _class_InputEventJoypadButton_pressure: -- :ref:`float` **pressure** - Represents the pressure the user puts on the button with his finger, if the controller supports it. Ranges from ``0`` to ``1``. +- :ref:`float` **pressure** - Represents the pressure the user puts on the button with their finger, if the controller supports it. Ranges from ``0`` to ``1``. Description diff --git a/classes/class_textedit.rst b/classes/class_textedit.rst index d2c1066ce..468dd8d27 100644 --- a/classes/class_textedit.rst +++ b/classes/class_textedit.rst @@ -413,7 +413,7 @@ Set the maximum amount of characters editable. - void **set_wrap** **(** :ref:`bool` enable **)** -Enable text wrapping when it goes beyond he edge of what is visible. +Enable text wrapping when it goes beyond the edge of what is visible. .. _class_TextEdit_toggle_fold_line: diff --git a/learning/features/2d/custom_drawing_in_2d.rst b/learning/features/2d/custom_drawing_in_2d.rst index 86e4bcd8b..fa9da5f73 100644 --- a/learning/features/2d/custom_drawing_in_2d.rst +++ b/learning/features/2d/custom_drawing_in_2d.rst @@ -227,7 +227,7 @@ Also, don't forget to modify the _draw() function to make use of these variables Let's run! It works, but the arc is rotating insanely fast! What's wrong? -The reason is that your GPU is actually displaying the frames as fast as he can. We need to "normalize" the drawing by this speed. To achieve, we have to make use of the 'delta' parameter of the _process() function. 'delta' contains the time elapsed between the two last rendered frames. It is generally small (about 0.0003 seconds, but this depends on your hardware). So, using 'delta' to control your drawing ensures that your program runs at the same speed on everybody's hardware. +The reason is that your GPU is actually displaying the frames as fast as it can. We need to "normalize" the drawing by this speed. To achieve, we have to make use of the 'delta' parameter of the _process() function. 'delta' contains the time elapsed between the two last rendered frames. It is generally small (about 0.0003 seconds, but this depends on your hardware). So, using 'delta' to control your drawing ensures that your program runs at the same speed on everybody's hardware. In our case, we simply need to multiply our 'rotation_ang' variable by 'delta' in the _process() function. This way, our 2 angles will be increased by a much smaller value, which directly depends on the rendering speed. diff --git a/learning/features/2d/particle_systems_2d.rst b/learning/features/2d/particle_systems_2d.rst index 61742b2ad..9b2e62182 100644 --- a/learning/features/2d/particle_systems_2d.rst +++ b/learning/features/2d/particle_systems_2d.rst @@ -11,7 +11,7 @@ provided. Particle systems are used to simulate complex physical effects such as sparks, fire, magic particles, smoke, mist, magic, etc. The idea is that a "particle" is emitted at a fixed interval and with a -fixed lifetime. During his lifetime, every particle will have the same +fixed lifetime. During its lifetime, every particle will have the same base behavior. What makes every particle different and provides a more organic look is the "randomness" associated to each parameter. In essence, creating a particle system means setting base physics diff --git a/learning/features/3d/baked_lightmaps.rst b/learning/features/3d/baked_lightmaps.rst index 37b53ed30..4017693f2 100644 --- a/learning/features/3d/baked_lightmaps.rst +++ b/learning/features/3d/baked_lightmaps.rst @@ -151,7 +151,7 @@ Besides the capture size, quality can be modified by setting the **Bake Mode**. Baking ------ -To begin he bake process, just push the big **Bake Lightmaps** button on top, when selecting the BakedLightmap node: +To begin the bake process, just push the big **Bake Lightmaps** button on top, when selecting the BakedLightmap node: .. image:: img/baked_light_bake.png diff --git a/learning/features/3d/high_dynamic_range.rst b/learning/features/3d/high_dynamic_range.rst index 05653cc30..0bcef5303 100644 --- a/learning/features/3d/high_dynamic_range.rst +++ b/learning/features/3d/high_dynamic_range.rst @@ -7,7 +7,7 @@ Introduction ------------ Normally, an artist does all the 3D modelling, then all the texturing, -looks at his or her awesome looking model in the 3D DCC and says "looks +looks at their awesome looking model in the 3D DCC and says "looks fantastic, ready for integration!" then goes into the game, lighting is setup and the game runs. diff --git a/learning/features/math/matrices_and_transforms.rst b/learning/features/math/matrices_and_transforms.rst index ca40b5331..722e4d8a0 100644 --- a/learning/features/math/matrices_and_transforms.rst +++ b/learning/features/math/matrices_and_transforms.rst @@ -108,7 +108,7 @@ were computed. Calculating distance in a direction or plane was one of the uses for the dot product. This was enough to obtain back the design coordinates for every point in the ship. -So, what he have been working with so far (with X, Y and Origin) is an +So, what we have been working with so far (with X, Y and Origin) is an *Oriented Coordinate System\*. X an Y are the **Basis**, and \*Origin* is the offset. diff --git a/learning/features/platform/android_in_app_purchases.rst b/learning/features/platform/android_in_app_purchases.rst index 783637f49..d9a863834 100644 --- a/learning/features/platform/android_in_app_purchases.rst +++ b/learning/features/platform/android_in_app_purchases.rst @@ -57,7 +57,7 @@ When starting our game, we can check if the user has purchased any product. YOU print(item_name) #print the name of purchased items -Google IAP policy says the game should restore the user's purchases if the user replaces his phone or reinstall the same app. We can use the above code to do check what products the user has purchased and we can make our game respond accordingly. +Google IAP policy says the game should restore the user's purchases if the user replaces their phone or reinstalls the same app. We can use the above code to check what products the user has purchased and we can make our game respond accordingly. Simple Purchase --------------- @@ -120,7 +120,7 @@ We should set the auto consume value only once when the game starts. Testing ------- -If we add a gmail id as a tester in Google dashboard, that tester can purchase items and he will not be charged. Another way to test IAP is using redeem codes generated by us for our game because the purchase flow is the same. +If we add a gmail id as a tester in Google dashboard, that tester can purchase items and they will not be charged. Another way to test IAP is using redeem codes generated by us for our game because the purchase flow is the same. Third way of testing is in development side. If we put the product ids as shown below, we will get a static fixed response according to the product id. This is a quick way of testing things before going to the dashboard. diff --git a/learning/step_by_step/ui_code_a_life_bar.rst b/learning/step_by_step/ui_code_a_life_bar.rst index 06eafdb01..ec4fadf41 100644 --- a/learning/step_by_step/ui_code_a_life_bar.rst +++ b/learning/step_by_step/ui_code_a_life_bar.rst @@ -114,7 +114,7 @@ Set up the Lifebar with the Player's max\_health We have to tell the GUI somehow what the player's current health is, to update the lifebar's texture, and to display the remaining health in the HP counter in the top left corner of the screen. To do this we send the -player's health to the GUI every time he takes damage. The GUI will then +player's health to the GUI every time they take damage. The GUI will then update the ``Lifebar`` and ``Number`` nodes with this value. We could stop here to display the number, but we need to initialize the @@ -550,7 +550,7 @@ And that is it. You may now play the game to see the final result! .. note:: - Using the exact same techniques, you can change the color of the bar when the Player gets poisoned, turn the bar red when its health drops low, shake the UI when he takes a critical hit... the principle is the same: emit a signal to forward the information from the `Player` to the `GUI` and let the `GUI` process it. + Using the exact same techniques, you can change the color of the bar when the Player gets poisoned, turn the bar red when its health drops low, shake the UI when they take a critical hit... the principle is the same: emit a signal to forward the information from the `Player` to the `GUI` and let the `GUI` process it. .. raw:: html diff --git a/learning/workflow/project_setup/project_organization.rst b/learning/workflow/project_setup/project_organization.rst index 4fa90d050..f633f52ea 100644 --- a/learning/workflow/project_setup/project_organization.rst +++ b/learning/workflow/project_setup/project_organization.rst @@ -7,8 +7,8 @@ Introduction ------------ This tutorial is aimed to propose a simple workflow on how to organize -projects. Since Godot allows the programmer to use the file-system as he -or she pleases, figuring out a way to organize the projects when +projects. Since Godot allows the programmer to use the file-system as +they please, figuring out a way to organize the projects when starting to use the engine can be a little challenging. Because of this, a simple workflow will be described, which can be used or not, but should work as a starting point.