Proofing/review: Remove filler words, adhere to style guide

README.md

@@ -12,13 +12,13 @@ Though arguably less convenient to edit than a wiki, this git repository is mean
 
 ### Editing existing pages
 
-To edit an existing page, just locate its .rst source file and open it in your favourite text editor. You can then commit the changes, push them to your fork and make a pull request. **Note that the pages in `classes/` should not be edited here, they are automatically generated from Godot's [XML class references](https://github.com/godotengine/godot/tree/master/doc/classes).**
+To edit an existing page, locate its .rst source file and open it in your favourite text editor. You can then commit the changes, push them to your fork and make a pull request. **Note that the pages in `classes/` should not be edited here, they are automatically generated from Godot's [XML class references](https://github.com/godotengine/godot/tree/master/doc/classes).**
 
 ### Adding new pages
 
 To add a new page, create a .rst file with a meaningful name in the section you want to add a file to, e.g. `tutorials/3d/light_baking.rst`. Write its content like you would do for any other file, and make sure to define a reference name for Sphinx at the beginning of the file (check other files for the syntax), based on the file name with a "doc_" prefix (e.g. `.. _doc_light_baking:`).
 
-You should then add your page to the relevant "toctree" (table of contents). By convention, the files used to define the various levels of toctree are prefixed with an underscore, so in the above example the file should be referenced in `tutorials/3d/_3d_graphics.rst`. Just add your new filename to the list on a new line, using a relative path and no extension, e.g. here `light_baking`.
+You should then add your page to the relevant "toctree" (table of contents). By convention, the files used to define the various levels of toctree are prefixed with an underscore, so in the above example the file should be referenced in `tutorials/3d/_3d_graphics.rst`. Add your new filename to the list on a new line, using a relative path and no extension, e.g. here `light_baking`.
 
 ### Sphinx and reStructuredText syntax
 

about/faq.rst

@@ -83,8 +83,8 @@ in Godot (see list of supported options above),
 but we strongly encourage you to try it and see the benefits for yourself.
 
 GDScript is designed to integrate from the ground to the way Godot
-works, more than any other language, and is very simple and easy to
-learn. Takes at most a day or two to get comfortable and it's very easy
+works, more than any other language, and is simple and easy to
+learn. Takes at most a day or two to get comfortable and it's easy
 to see the benefits once you do. Please do the effort to learn
 GDScript, you will not regret it.
 
@@ -122,13 +122,13 @@ The main reasons are:
 5. Garbage collector results in stalls or unnecessarily large memory
    usage (Lua, Python, JS, AS, etc.).
 6. Difficulty to integrate with the code editor for providing code
-   completion, live editing, etc. (all of them). This is very well
+   completion, live editing, etc. (all of them). This is well
    supported by GDScript.
 
-GDScript was designed to solve the issues above, and performs very well
+GDScript was designed to solve the issues above, and performs well
 in all the above scenarios. Please learn GDScript and enjoy a
-very smooth integration of scripting with the game engine (yes, it's a
-rare but very enjoyable situation when things just work). It's worth
+smooth integration of scripting with the game engine (yes, it's a
+rare but enjoyable situation when things just work). It's worth
 it, give it a try!
 
 I want to extend Godot. What are my options for creating plugins?
@@ -151,11 +151,11 @@ the Godot modules as well as the `unofficial Python support <https://github.com/
 Why is FBX not supported for import?
 ------------------------------------
 
-FBX SDK has a very `restrictive license <http://www.blender.org/bf/Autodesk_FBX_License.rtf>`_,
+FBX SDK has a `restrictive license <http://www.blender.org/bf/Autodesk_FBX_License.rtf>`_,
 that is incompatible with the `open license <http://opensource.org/licenses/MIT>`_
 provided by Godot.
 
-That said, Godot's Collada support is really good, please use the
+That said, Godot's Collada support is good, please use the
 `OpenCollada <https://github.com/KhronosGroup/OpenCOLLADA/wiki/OpenCOLLADA-Tools>`_
 exporter for maximum compatibility if you are using Maya or 3DS Max.
 If you are using Blender, take a look at our own
@@ -220,7 +220,7 @@ Camera XFov or YFov.
 
 And that's it! Your game should work in multiple resolutions.
 
-If there really is a desire to make your game also work on ancient
+If there is a desire to make your game also work on ancient
 devices with tiny screens (less than 300 pixels in width), you can use
 the export option to shrink images, and set that build to be used for
 certain screen sizes in the App Store or Google Play.

about/introduction.rst

@@ -31,7 +31,7 @@ if you need a quick writeup about Godot Engine.
     platforms, including the major desktop platforms (Linux, macOS, Windows)
     as well as mobile (Android, iOS) and web-based (HTML5) platforms.
 
-    Godot is completely free and open source under the very permissive MIT
+    Godot is completely free and open source under the permissive MIT
     license. No strings attached, no royalties, nothing. Users' games are
     theirs, down to the last line of engine code. Godot's development is fully
     independent and community-driven, empowering users to help shape their

community/contributing/updating_the_class_reference.rst

@@ -75,7 +75,7 @@ You can check the list of all remote servers with:
 
     git remote -v
 
-You should have 2: ``origin``, your fork on github, that git adds by default, and ``upstream``, that you just added:
+You should have two: ``origin``, your fork on github, that git adds by default, and ``upstream``, that you just added:
 
 
 ::

community/contributing/ways_to_contribute.rst

@@ -126,7 +126,7 @@ Godot uses `GitHub's issue tracker <https://github.com/godotengine/godot/issues>
 for bug reports and enhancement suggestions. You will need a GitHub account to
 be able to open a new issue there, and click on the "New issue" button.
 
-When you report a bug, you should keep in mind that the process is very similar
+When you report a bug, you should keep in mind that the process is similar
 to an appointment with your doctor. You noticed *symptoms* that make you think
 that something might be wrong (the engine crashes, some features don't work as
 expected, etc.). It's the role of the bug triaging team and the developers to

development/compiling/compiling_for_android.rst

@@ -54,7 +54,7 @@ Toolchain
 ~~~~~~~~~
 
 We usually try to keep the Godot Android build code up to date, but
-Google changes their toolchain versions very often, so if compilation
+Google changes their toolchain versions often, so if compilation
 fails due to wrong toolchain version, go to your NDK directory and check
 the current number, then set the following environment variable:
 
@@ -142,9 +142,8 @@ were compiled against the same version/commit as the editor. If you are
 using official binaries for the editor, make sure to install the matching
 export templates, or to build your own from the same version.
 
-When exporting your game, Godot opens the APK, changes a few things inside,
-adds your file and spits it back. It's really handy! (and required some
-reverse engineering of the format).
+When exporting your game, Godot opens the APK, changes a few things inside and
+adds your files.
 
 Installing the templates
 ~~~~~~~~~~~~~~~~~~~~~~~~

development/compiling/compiling_for_uwp.rst

@@ -99,7 +99,7 @@ Create a new Windows App project using the "App for OpenGL ES
 ``Visual C++/Windows/Universal`` category.
 
 This is a base project with the ANGLE dependencies already set up. However, by
-default it picks the debug version of the DLLs which usually have a very poor
+default it picks the debug version of the DLLs which usually have poor
 performance. So in the "Binaries" filter, click in each of the DLLs there
 and in the "Properties" window and change the relative path from
 ``Debug_Win32`` to ``Release_Win32`` (or ``Release_ARM`` for devices).

development/compiling/compiling_for_windows.rst

@@ -334,7 +334,7 @@ make sure that you have installed Pywin32 so that parallel (-j) builds
 work properly.
 
 If you need to edit the compilation commands, they are located in
-"Godot" project settings, NMAKE sheet. SCons is called at the very end of
+"Godot" project settings, NMAKE sheet. SCons is called at the end of
 the commands. If you make a mistake, copy the command from one of the
 other build configurations (debug, release_debug, release) or
 architectures (Win32/x64). They are equivalent.

development/cpp/core_types.rst

@@ -41,12 +41,12 @@ Memory model
 
 PC is a wonderful architecture. Computers often have gigabytes of RAM,
 terabytes of storage and gigahertz of CPU, and when an application needs
-more resources the OS will just swap out the inactive ones. Other
+more resources the OS will swap out the inactive ones. Other
 architectures (like mobile or consoles) are in general more limited.
 
 The most common memory model is the heap, where an application will
 request a region of memory, and the underlying OS will try to fit it
-somewhere and return it. This often works best and is very flexible,
+somewhere and return it. This often works best and is flexible,
 but over time and with abuse, this can lead to segmentation.
 
 Segmentation slowly creates holes that are too small for most common
@@ -59,7 +59,7 @@ However, in many studies and tests, it is shown that given enough
 memory, if the maximum allocation size is below a given threshold in
 proportion to the maximum heap size and proportion of memory intended to
 be unused, segmentation will not be a problem over time as it will
-remain constant. In other words, just leave 10-20% of your memory free
+remain constant. In other words, leave 10-20% of your memory free
 and perform all small allocations and you are fine.
 
 Godot ensures that all objects that can be allocated dynamically are
@@ -103,14 +103,14 @@ which are equivalent to new, delete, new[] and delete[].
 memnew/memdelete also use a little C++ magic and notify Objects right
 after they are created, and right before they are deleted.
 
-For dynamic memory, the DVector<> template is provided. Just use it
-like:
+For dynamic memory, the DVector<> template is provided. Use it
+like this:
 
 .. code:: cpp
 
     DVector<int>
 
-DVector is just a standard vector class, it can be accessed using the []
+DVector is a standard vector class, it can be accessed using the []
 operator, but that's probably slow for large amount of accesses (as it
 has to lock internally). A few helpers exist for this:
 
@@ -145,7 +145,7 @@ Godot provides also a set of common containers:
 -  Set
 -  Map
 
-They are very simple and aim to be as minimal as possible, as templates
+They are simple and aim to be as minimal as possible, as templates
 in C++ are often inlined and make the binary size much fatter, both in
 debug symbols and code. List, Set and Map can be iterated using
 pointers, like this:
@@ -189,7 +189,7 @@ StringName
 
 StringNames are like a String, but they are unique. Creating a
 StringName from a string results in a unique internal pointer for all
-equal strings. StringNames are really useful for using strings as
+equal strings. StringNames are useful for using strings as
 identifier, as comparing them is basically comparing a pointer.
 
 Creation of a StringName (especially a new one) is slow, but comparison
@@ -204,7 +204,7 @@ Math types
 ----------
 
 There are several linear math types available in the core/math
-directory, they are basically just that.
+directory.
 
 References:
 ~~~~~~~~~~~

development/cpp/creating_android_modules.rst

@@ -202,7 +202,7 @@ SDK library
 
 So, finally it's time to add the SDK library. The library can come in
 two flavors, a JAR file or an Android project for ant. JAR is the
-easiest to integrate, just put it in the module directory and add it:
+easiest to integrate, put it in the module directory and add it:
 
 .. code:: python
 
@@ -263,7 +263,7 @@ This will cause your module to be included, the .jar will be copied to
 the java folder, the .java will be copied to the sources folder, etc.
 Each time you modify the .java, scons must be called.
 
-Afterwards, just continue the steps for compiling android  :ref:`doc_compiling_for_android`.
+Afterwards, continue the steps for compiling android  :ref:`doc_compiling_for_android`.
 
 Using the module
 ~~~~~~~~~~~~~~~~
@@ -285,7 +285,7 @@ More than one singleton module can be enabled by separating with commas:
 
     modules="org/godotengine/godot/MySingleton,corg/godotengine/godot/MyOtherSingleton"
 
-Then just request the singleton Java object from Globals like this:
+Then request the singleton Java object from Globals like this:
 
 ::
 

development/cpp/custom_modules_in_cpp.rst

@@ -157,7 +157,7 @@ this module:
     # SCsub
     Import('env')
 
-    env.add_source_files(env.modules_sources,"*.cpp") # just add all cpp files to the build
+    env.add_source_files(env.modules_sources,"*.cpp") # Add all cpp files to the build
 
 With multiple sources, you can also add each file individually to a Python
 string list:
@@ -227,8 +227,7 @@ your module will be included.
 Using the module
 ----------------
 
-Using your newly created module is very easy, from any script you can
-now do:
+You can now use your newly created moedule from any script:
 
 ::
 
@@ -406,15 +405,14 @@ one of the ``ClassName.xml`` files and recompile the engine from now on.
 Summing up
 ----------
 
-As you see, it's really easy to develop Godot in C++. Just write your
-stuff normally and remember to:
+Remember to:
 
 -  use ``GDCLASS`` macro for inheritance, so Godot can wrap it
 -  use ``_bind_methods`` to bind your functions to scripting, and to
    allow them to work as callbacks for signals.
 
 But this is not all, depending what you do, you will be greeted with
-some surprises.
+some (hopefully positive) surprises.
 
 -  If you inherit from :ref:`class_Node` (or any derived node type, such as
    Sprite), your new class will appear in the editor, in the inheritance

development/cpp/object_class.rst

@@ -204,7 +204,7 @@ example:
 
 If cast fails, NULL is returned. This system uses RTTI, but it also
 works fine (although a bit slower) when RTTI is disabled. This is useful
-on platforms where a very small binary size is ideal, such as HTML5 or
+on platforms where a small binary size is ideal, such as HTML5 or
 consoles (with low memory footprint).
 
 Signals

development/file_formats/tscn.rst

@@ -105,7 +105,7 @@ Internal Resources
 
 A TSCN file can contain meshes, materials and other data, and these are 
 contained in the internal resources section of the file. The heading
-for an internal resource looks very similar to those of external resources, but
+for an internal resource looks similar to those of external resources, but
 does not have a path. Internal resources also have :code:`key=value` pairs 
 under each heading. For example, a capsule collision shape looks like:
 
@@ -155,7 +155,7 @@ root's name. If it is a direct child of the scene root, it should be
     [node name="Finger" parent="Arm/Hand" type="Spatial"]
     
 Similar to the internal resource, the content for each node is currently 
-undocumented. Fortunately it is very easy to find out because you can simply 
+undocumented. Fortunately it is easy to find out because you can simply 
 save a file with that node in it. Some example nodes are:
 
 ::

getting_started/editor/command_line_tutorial.rst

@@ -48,9 +48,7 @@ For example, the full command for exporting your game (as explained below) might
 Creating a project
 ------------------
 
-Creating a project from the command line is simple, just navigate the
-shell to the desired place and just make project.godot file exist, even
-if empty.
+To create a project from the command line, navigate the to the desired place and create an empty project.godot file.
 
 ::
 
@@ -58,7 +56,7 @@ if empty.
     user@host:~$ cd newgame
     user@host:~/newgame$ touch project.godot
 
-That alone makes for an empty Godot project.
+The project can now be opened with Godot.
 
 Running the editor
 ------------------
@@ -135,7 +133,7 @@ that is headless (server build, no video) is ideal for this.
 
 The platform names recognized by the ``--export`` switch are the same as
 displayed in the export wizard of the editor. To get a list of supported
-platforms from the command line, just try exporting to a non-recognized
+platforms from the command line, try exporting to a non-recognized
 platform and the full listing of platforms your configuration supports
 will be shown.
 
@@ -146,7 +144,7 @@ Running a script
 ----------------
 
 It is possible to run a simple .gd script from the command line. This
-feature is especially useful in very large projects, for batch
+feature is especially useful in large projects, for batch
 conversion of assets or custom import/export.
 
 The script must inherit from SceneTree or MainLoop.

getting_started/editor/unity_to_godot.rst

@@ -62,7 +62,7 @@ Finally, the Toolbar at the top of the screen is similar in the sense that it al
 
 This approach has the disadvantage that the running game can't be explored from different angles (though this may be supported in the future, and displaying collision gizmos in the running game is already possible), but in exchange has several advantages:
 
-- Running the project and closing it is very fast (Unity has to save, run the project, close the project and then reload the previous state).
+- Running the project and closing it is fast (Unity has to save, run the project, close the project and then reload the previous state).
 - Live editing is a lot more useful, because changes done to the editor take effect immediately in the game, and are not lost (nor have to be synced) when the game is closed. This allows fantastic workflows, like creating levels while you play them.
 - The editor is more stable, because the game runs in a separate process.
 
@@ -157,7 +157,7 @@ Design
 
 As you may know already, Unity supports C#. C# benefits from its integration with Visual Studio and other features, such as static typing.
 
-Godot provides its own scripting language, :ref:`GDScript <doc_scripting>` as well as support for :ref:`Visual Script <toc-learn-scripting-visual_script>` and :ref:`C# <doc_c_sharp>`. GDScript borrows its syntax from Python, but is not related to it. If you wonder about the reasoning for a custom scripting language, please read :ref:`GDScript <doc_gdscript>` and `FAQ <faq>`_ pages. GDScript is strongly attached to the Godot API, but it is really easy to learn: between one evening for an experienced programmer and a week for a complete beginner.
+Godot provides its own scripting language, :ref:`GDScript <doc_scripting>` as well as support for :ref:`Visual Script <toc-learn-scripting-visual_script>` and :ref:`C# <doc_c_sharp>`. GDScript borrows its syntax from Python, but is not related to it. If you wonder about the reasoning for a custom scripting language, please read :ref:`GDScript <doc_gdscript>` and `FAQ <faq>`_ pages. GDScript is strongly attached to the Godot API, but it is easy to learn.
 
 Unity allows you to attach as many scripts as you want to a GameObject. Each script adds a behaviour to the GameObject: for example, you can attach a script so that it reacts to the player's controls, and another that controls its specific game logic.
 
@@ -179,6 +179,6 @@ But there's more! Certain nodes throw signals when certain actions happen. You c
 Using Godot in C++
 ------------------
 
-Just for your information, Godot also allows you to develop your project directly in C++ by using its API, which is not possible with Unity at the moment. As an example, you can consider Godot Engine's editor as a "game" written in C++ using Godot API.
+For your information, Godot also allows you to develop your project directly in C++ by using its API, which is not possible with Unity at the moment. As an example, you can consider Godot Engine's editor as a "game" written in C++ using Godot API.
 
 If you are interested in using Godot in C++, you may want to start reading the :ref:`Developing in C++ <doc_introduction_to_godot_development>` page.

getting_started/scripting/gdscript/gdscript_advanced.rst

@@ -22,7 +22,7 @@ Pros & cons of dynamic typing
 GDScript is a Dynamically Typed language. As such, its main advantages
 are that:
 
--  The language is very simple to learn.
+-  The language is simple and easy to learn.
 -  Most code can be written and changed quickly and without hassle.
 -  Less code written means less errors & mistakes to fix.
 -  Easier to read the code (less clutter).
@@ -41,7 +41,7 @@ While the main disadvantages are:
    known at run-time).
 
 This, translated to reality, means that Godot+GDScript are a combination
-designed to create games very quickly and efficiently. For games that are very
+designed to create games quickly and efficiently. For games that are very
 computationally intensive and can't benefit from the engine built-in
 tools (such as the Vector types, Physics Engine, Math library, etc), the
 possibility of using C++ is present too. This allows to still create the
@@ -230,7 +230,7 @@ Or unordered sets:
 Dictionaries
 ------------
 
-Dictionaries are a very powerful tool in dynamically typed languages.
+Dictionaries are a powerful tool in dynamically typed languages.
 Most programmers that come from statically typed languages (such as C++
 or C#) ignore their existence and make their life unnecessarily more
 difficult. This datatype is generally not present in such languages (or
@@ -238,7 +238,7 @@ only on limited form).
 
 Dictionaries can map any value to any other value with complete
 disregard for the datatype used as either key or value. Contrary to
-popular belief, they are very efficient because they can be implemented
+popular belief, they are efficient because they can be implemented
 with hash tables. They are, in fact, so efficient that some languages
 will go as far as implementing arrays as dictionaries.
 
@@ -293,7 +293,7 @@ easily with dictionaries. Here's a simple battleship game example:
 
 Dictionaries can also be used as data markup or quick structures. While
 GDScript dictionaries resemble python dictionaries, it also supports Lua
-style syntax and indexing, which makes it very useful for writing initial
+style syntax and indexing, which makes it useful for writing initial
 states and quick structs:
 
 ::

getting_started/scripting/gdscript/gdscript_basics.rst

@@ -48,7 +48,7 @@ built-in language has proven to be a huge advantage.
 Example of GDScript
 ~~~~~~~~~~~~~~~~~~~
 
-Some people can learn better by just taking a look at the syntax, so
+Some people can learn better by taking a look at the syntax, so
 here's a simple example of how GDScript looks.
 
 ::
@@ -473,12 +473,12 @@ Starting with Godot 2.1, indices may be negative like in Python, to count from t
     arr[0] = "Hi!" # Replacing value 1 with "Hi"
     arr.append(4) # Array is now ["Hi", 2, 3, 4]
 
-GDScript arrays are allocated linearly in memory for speed. Very
-large arrays (more than tens of thousands of elements) may however cause
+GDScript arrays are allocated linearly in memory for speed.
+Large arrays (more than tens of thousands of elements) may however cause
 memory fragmentation. If this is a concern special types of
 arrays are available. These only accept a single data type. They avoid memory
 fragmentation and also use less memory but are atomic and tend to run slower than generic
-arrays. They are therefore only recommended to use for very large data sets:
+arrays. They are therefore only recommended to use for large data sets:
 
 - :ref:`PoolByteArray <class_PoolByteArray>`: An array of bytes (integers from 0 to 255).
 - :ref:`PoolIntArray <class_PoolIntArray>`: An array of integers.
@@ -866,7 +866,7 @@ Classes
 
 By default, the body of a script file is an unnamed class and it can
 only be referenced externally as a resource or file. Class syntax is
-meant to be very compact and can only contain member variables or
+meant to be compact and can only contain member variables or
 functions. Static functions are allowed, but not static members (this is
 in the spirit of thread safety, since scripts can be initialized in
 separate threads without the user knowing). In the same way, member
@@ -1111,7 +1111,7 @@ can be set from the editor:
     export(int, FLAGS) var spell_elements = ELEMENT_WIND | ELEMENT_WATER
 
 Restricting the flags to a certain number of named flags is also
-possible. The syntax is very similar to the enumeration syntax:
+possible. The syntax is similar to the enumeration syntax:
 
 ::
 
@@ -1231,7 +1231,7 @@ Memory management
 ~~~~~~~~~~~~~~~~~
 
 If a class inherits from :ref:`class_Reference`, then instances will be
-freed when no longer in use. No garbage collector exists, just simple
+freed when no longer in use. No garbage collector exists, just 
 reference counting. By default, all classes that don't define
 inheritance extend **Reference**. If this is not desired, then a class
 must inherit :ref:`class_Object` manually and must call instance.free(). To
@@ -1253,8 +1253,8 @@ Declaring a signal in GDScript is easy using the `signal` keyword.
     # With arguments
     signal your_signal_name_with_args(a, b)
 
-These signals, just like regular signals, can be connected in the editor
-or from code. Just take the instance of a class where the signal was
+These signals can be connected in the editor or from code like regular signals.
+Take the instance of a class where the signal was
 declared and connect it to the method of another instance:
 
 ::
@@ -1277,7 +1277,7 @@ your custom values:
     func _at_some_func():
         instance.connect("your_signal_name", self, "_callback_args", [22, "hello"])
 
-This is very useful when a signal from many objects is connected to a
+This is useful when a signal from many objects is connected to a
 single callback and the sender must be identified:
 
 ::
@@ -1377,7 +1377,7 @@ signal is received, execution will recommence. Here are some examples:
 Onready keyword
 ~~~~~~~~~~~~~~~
 
-When using nodes, it's very common to desire to keep references to parts
+When using nodes, it's common to desire to keep references to parts
 of the scene in a variable. As scenes are only warranted to be
 configured when entering the active scene tree, the sub-nodes can only
 be obtained when a call to Node._ready() is made.

getting_started/scripting/visual_script/getting_started.rst

@@ -22,7 +22,7 @@ palette from where you can drag and drop all sorts of information to the script
 Creating a Script
 -----------------
 
-Creating scripts works the same as with other scripting languages: Just select any node in the scene
+Creating scripts works the same as with other scripting languages: Select any node in the scene
 and push the "New Script" button at the top right corner of the Scene Tree dock:
 
 .. image:: img/visual_script3.png

getting_started/scripting/visual_script/nodes_purposes.rst

@@ -17,7 +17,7 @@ Node Properties
 Like in most visual scripting implementations, each node has editable properties. In Godot, though, we try to avoid
 bloating the nodes with editable controls for the sake of readability. 
 
-Nodes still display the required information as text, but editing is done via the *Inspector*. To edit them, just
+Nodes still display the required information as text, but editing is done via the *Inspector*. To edit them,
 select any node and edit its properties in the *Inspector*.
 
 
@@ -40,7 +40,7 @@ There are two types of *Ports*: *Sequence* and *Data*.
 *Sequence Ports* indicate the order in which operations are executed. 
 Typically when a *Node* is done processing, it will go to the next node from one of the ports at the right. 
 If nothing is connected the function may end, or another output *Sequence Port* might be tried (this depends on the node). 
-Thanks to this, it's easy to understand the logic within a function by just following the white lines.
+Thanks to this, you can follow the logic flow within a function by following the white lines.
 Not every *Node* has *Sequence Ports*. In fact, most do not.
 
 *Data Ports* ports contain typed values. Types can be any regular Godot types, 
@@ -57,7 +57,7 @@ Pay special attention to colors and icons, as each type has a different represen
 Connections
 ~~~~~~~~~~~
 
-Connecting is a relatively simple process. Just drag an *Output Port* towards an *Input Port*. 
+Connecting is a relatively simple process. Drag an *Output Port* towards an *Input Port*. 
 
 .. image:: img/visual_script_connect.gif
 
@@ -119,7 +119,7 @@ This is the most common way to edit *Scene Nodes* in Visual Scripting. Select a
 
 The result is that this value can be changed from your script by writing to a *Data Port*.
 
-If instead reading this value is desired, just drag the node again but hold the *Control* key (or Command on Mac). This will create a getter:
+If instead reading this value is desired, drag the node again but hold the *Control* key (or Command on Mac). This will create a getter:
 
 .. image:: img/visual_script22.png
 
@@ -173,7 +173,7 @@ A signal can also be edited via right-click menu to customize its arguments:
 .. image:: img/visual_script30.png
 
 
-The signal you have just created will appear in the Inspector along with the built-in node signals. This allows you to connect it from another script from another *Scene Node*:
+The signal you have created will appear in the Inspector along with the built-in node signals. This allows you to connect it from another script from another *Scene Node*:
 
 .. image:: img/visual_script31.png
 
@@ -262,7 +262,7 @@ Remember that dragging a connection to empty space will help you call functions
 Local Variables
 ^^^^^^^^^^^^^^^
 
-These are nodes you can use as temporary storage for your graphs. Just make sure they all have the same name and type when using them and they will reference the same piece of memory.
+These are nodes you can use as temporary storage for your graphs. Make sure they all have the same name and type when using them and they will reference the same piece of memory.
 
 .. image:: img/visual_script41.png
 
@@ -273,7 +273,7 @@ As it can be seen above, there are two nodes available: A simple getter, and a s
 Scene Node
 ^^^^^^^^^^
 
-This is just a reference to a node in the tree, but it's easier to use this node by just dragging the actual node 
+This is just a reference to a node in the tree, but it's easier to use this node by dragging the actual node 
 from the scene tree to the canvas (this will create it and configure it).
 
 
@@ -281,7 +281,7 @@ Self
 ^^^^
 
 In some rare occasions, it may be desired to pass this Scene Node as argument. 
-It can be used to call functions and set/get properties, or just drag nodes (or event the node itself that has the script) from the Scene Tree to the canvas for this.
+It can be used to call functions and set/get properties, or drag nodes (or event the node itself that has the script) from the Scene Tree to the canvas for this.
 
 
 SceneTree
@@ -299,7 +299,7 @@ Preload
 ^^^^^^^
 
 This does the same function as preload() in GDScript. It maintains this resource loaded and ready to use. Rather than
-instancing the node, it's simpler to just drag the desired resource from the filesystem dock to the canvas.
+instancing the node, it's simpler to drag the desired resource from the filesystem dock to the canvas.
 
 
 Resource Path
@@ -363,7 +363,7 @@ This node is useful mostly for organizing your graph. It calls its sequence port
 TypeCast
 ^^^^^^^^
 
-This is a very useful and commonly used node. You can use it to cast arguments or other objects
+This is a useful and commonly used node. You can use it to cast arguments or other objects
 to the type you desire. Afterwards, you can even drag the object output to get full completion.
 
 .. image:: img/visual_script55.png
@@ -398,7 +398,7 @@ Built-In
 ^^^^^^^^
 
 There is a list of built in helpers. The list is almost identical to the one from GDScript (@TODO, link to gdscript methods?).
-Most of them are mathematical functions, but others can be very useful helpers. Just make sure to take a look at the list
+Most of them are mathematical functions, but others can be useful helpers. Make sure to take a look at the list
 at some point.
 
 
@@ -434,7 +434,7 @@ This is the opposite to Constructor, it allows to separate any basic type (ie, V
 Emit Signal
 ^^^^^^^^^^^
 
-Emits signals from any object. In general it's not very useful, as dragging a signal to the canvas works better.
+Emits signals from any object. In general it's not that useful, as dragging a signal to the canvas works better.
 
 
 Get/Set
@@ -483,7 +483,7 @@ Expression Node
 ^^^^^^^^^^^^^^^
 
 Among the operators, the *Expression* node is the most powerful. If well used, it allows you to enormously simplify
-visual scripts that are math or logic heavy. Just type any expression on it and it will be executed in real-time.
+visual scripts that are math or logic heavy. Type any expression on it and it will be executed in real-time.
 
 Expression nodes can:
 

getting_started/step_by_step/filesystem.rst

@@ -89,7 +89,7 @@ Host file system
 
 Alternatively host file system paths can also be used, but this is not recommended
 for a released product as these paths are not guaranteed to work on all platforms.
-However, using host file system paths can be very useful when writing development
+However, using host file system paths can be useful when writing development
 tools in Godot!
 
 Drawbacks
@@ -107,7 +107,7 @@ going the hardest route?).
 
 The second is that under Windows and macOS file and path names are case insensitive.
 If a developer working in a case insensitive host file system saves an asset as "myfile.PNG",
-but then references it as "myfile.png", it will work just fine on their platorm, but not
+but then references it as "myfile.png", it will work fine on their platorm, but not
 on other platforms, such as Linux, Android, etc. This may also apply to exported binaries,
 which use a compressed package to store all files.
 

getting_started/step_by_step/instancing.rst

@@ -23,7 +23,7 @@ extension.
 
 .. image:: img/instancingpre.png
 
-Once a scene has been saved, it can be instanced into another scene just as
+Once a scene has been saved, it can be instanced into another scene as
 if it were any other node.
 
 .. image:: img/instancing.png
@@ -111,5 +111,5 @@ value in the saved scene.
 Conclusion
 ----------
 
-Instancing can be very useful when you want to create many copies of the
+Instancing can be useful when you want to create many copies of the
 same object.

getting_started/step_by_step/instancing_continued.rst

@@ -32,8 +32,8 @@ For example, here's how a simple shooter game could be imagined:
 
 .. image:: img/shooter_instancing.png
 
-It's pretty easy to come up with a diagram like this for almost any kind
-of game. Just write down the parts of the game that you can visualize, and then
+You can come up with a diagram like this for almost any kind
+of game. Write down the parts of the game that you can visualize, and then
 add arrows to represent ownership of one component by another.
 
 Once you have a diagram like this, the recommended process for making a game is
@@ -79,4 +79,4 @@ scenes and instancing are used in real projects.
 
 Everything discussed here will become second nature to you once you start
 making games and putting these concepts into practice. For now, don't worry
-about it too much, and just go on to the next tutorial!
+about it too much, and go on to the next tutorial!

getting_started/step_by_step/resources.rst

@@ -35,7 +35,7 @@ considered a resource.
 
 When a resource is loaded from disk, **it is always loaded once**. That
 means, if there is a copy of that resource already loaded in memory,
-trying to load the resource again will just return the same copy again
+trying to load the resource again will return the same copy again
 and again. This corresponds with the fact that resources are just data
 containers, so there is no need to have them duplicated.
 

getting_started/step_by_step/scene_tree.rst

@@ -7,7 +7,7 @@ Introduction
 ------------
 
 This is where things start getting abstract, but don't panic. There's 
-not really much more depth than this.
+not much more depth than this.
 
 In previous tutorials, everything revolved around the concept of
 nodes. Scenes are simply a collection of nodes. They become active once 
@@ -34,9 +34,8 @@ see how this works internally).
 
 The user program, or game, starts in the MainLoop. This class has a few
 methods, for initialization, idle (frame-synchronized callback), fixed
-(physics-synchronized callback), and input. Again, this is really low
-level and when making games in Godot, writing your own MainLoop does not
-even make sense.
+(physics-synchronized callback), and input. Again, this is low
+level and when making games in Godot, writing your own MainLoop seldom makes sense.
 
 SceneTree
 ---------

getting_started/step_by_step/scenes_and_nodes.rst

@@ -40,7 +40,7 @@ functions. However, any given node always has the following attributes:
 
 .. image:: img/tree.png
 
-The last one is very important. Nodes can have other nodes as
+The last one is important. Nodes can have other nodes as
 children. When arranged in this way, the nodes become a **tree**.
 
 In Godot, the ability to arrange nodes in this way creates a powerful

getting_started/step_by_step/scripting.rst

@@ -15,7 +15,7 @@ it also makes our work supporting languages more difficult.
 
 The "Main" languages in Godot, though, are GDScript and VisualScript. The
 main reason to choose them is their level of integration with Godot, as this
-makes the experience smoother; both have very slick editor integration, while
+makes the experience smoother; both have slick editor integration, while
 C# and C++ need to be edited in a separate IDE. If you are a big fan of statically typed languages, go with C# and C++ instead.
 
 GDScript
@@ -190,7 +190,7 @@ For the first part, Godot provides two ways to create connections: through a
 visual interface the editor provides or through code.
 
 While we will use the code method for the remainder of this tutorial series, let's
-cover how the editor interface works just for future reference.
+cover how the editor interface works for future reference.
 
 Select the Button node in the scene tree and then select the "Node" tab. Next,
 make sure that you have "Signals" selected.

getting_started/step_by_step/scripting_continued.rst

@@ -270,7 +270,7 @@ the notification system.
 Creating nodes
 --------------
 
-To create a node from code, call the ``.new()`` method, just like for any 
+To create a node from code, call the ``.new()`` method, like for any 
 other class-based datatype. For example:
 
 
@@ -311,7 +311,7 @@ used:
     }
 
 When a node is freed, it also frees all its children nodes. Because of
-this, manually deleting nodes is much simpler than it appears. Just free
+this, manually deleting nodes is much simpler than it appears. Free
 the base node and everything else in the subtree goes away with it.
 
 A situation might occur where we want to delete a node that

getting_started/step_by_step/singletons_autoload.rst

@@ -6,10 +6,10 @@ Singletons (AutoLoad)
 Introduction
 ------------
 
-Scene singletons are very useful, catering to a common use case where you need
+Scene singletons are useful, catering to a common use case where you need
 to store persistent information between scenes.
 
-Albeit very powerful, the scene system by itself has a few drawbacks:
+Albeit powerful, the scene system by itself has a few drawbacks:
 
 -  There is no common place to store information (e.g. a player's items etc.)
    required by more than one scene.
@@ -215,7 +215,7 @@ current scene and replaces it with the requested one.
         GetTree().SetCurrentScene(CurrentScene);
     }
 
-As mentioned in the comments above, we really want to avoid the
+As mentioned in the comments above, we want to avoid the
 situation of having the current scene being deleted while being used
 (code from functions of it being run), so using
 :ref:`Object.call_deferred() <class_Object_call_deferred>`

getting_started/step_by_step/splash_screen.rst

@@ -7,7 +7,7 @@ Tutorial
 --------
 
 This is a simple tutorial to establish the basic idea of how the GUI
-subsystem works. The goal is to create a really simple, static
+subsystem works. The goal is to create a simple, static
 splash screen.
 
 .. image:: img/robisplash_result.png
@@ -25,7 +25,7 @@ Set the display resolution to 800x450 in Project Settings, and set up a new scen
 .. image:: img/robisplash_scene.png
 
 The nodes "background" and "logo" are of :ref:`TextureRect <class_TextureRect>`
-type. To display an image, just drag the corresponding asset to the texture property.
+type. To display an image, drag the corresponding asset to the texture property.
 
 .. image:: img/robisplash_background_inspector.png
 

getting_started/step_by_step/ui_code_a_life_bar.rst

@@ -198,7 +198,7 @@ Why don't we directly get the ``Player`` node in the ``_process``
 function and look at the health value? Accessing nodes this way creates
 tight coupling between them. If you did it sparingly it may work. As
 your game grows bigger, you may have many more connections. If you get
-nodes this way it gets very complex quickly. Not only that: you
+nodes this way it gets complex quickly. Not only that: you
 need to listen to the state change constantly in the ``_process``
 function. This check happens 60 times a second and you'll likely break
 the game because of the order in which the code runs.
@@ -223,7 +223,7 @@ to listen the one you selected.
 
 The first section lists custom signals defined in ``player.GD``:
 
--  ``died`` is emitted when the character just died. We will use it in a
+-  ``died`` is emitted when the character died. We will use it in a
    moment to hide the UI.
 -  ``health_changed`` is emitted when the character got hit.
 
@@ -306,7 +306,7 @@ Inside ``_on_Player_health_changed`` let's call a second function called
 
     We could directly update the health value on `LifeBar` and `Number`. There are two reasons to use this method instead:
 
-    1. The name makes it very clear for our future selves and teammates that when the player took damage, we update the health count on the GUI
+    1. The name makes it clear for our future selves and teammates that when the player took damage, we update the health count on the GUI
     2. We will reuse this method a bit later
 
 Create a new ``update_health`` method below ``_on_Player_health_changed``.
@@ -465,7 +465,7 @@ active. Add this code after the last line:
 
 .. note::
 
-    Although we could animate the `health` property on the `Player`, we really shouldn't. Characters should lose life instantly when they get hit. It makes it a lot easier to manage their state, like to know when one died. You always want to store animations in a separate data container or node. The `tween` node is perfect for code-controlled animations. For hand-made animations, check out `AnimationPlayer`.
+    Although we could animate the `health` property on the `Player`, we shouldn't. Characters should lose life instantly when they get hit. It makes it a lot easier to manage their state, like to know when one died. You always want to store animations in a separate data container or node. The `tween` node is perfect for code-controlled animations. For hand-made animations, check out `AnimationPlayer`.
 
 Assign the animated\_health to the LifeBar
 ------------------------------------------
@@ -563,7 +563,7 @@ Try the game again to see a nice blocky animation.
     ``_on_Player_health_changed``, which in turn calls ``update_health``. This
     updates the animation and the ``number_label`` and ``bar`` follow in
     ``_process``. The animated life bar that shows the health going down gradually
-    is just a trick. It makes the GUI feel alive. If the ``Player`` takes 3 damage,
+    is a trick. It makes the GUI feel alive. If the ``Player`` takes 3 damage,
     it happens in an instant.
 
 Fade the bar when the Player dies
@@ -575,7 +575,7 @@ bar as well when the character died. We will reuse the same ``Tween``
 node as it manages multiple animations in parallel for us.
 
 First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal
-to know when it just died. Press :kbd:`F1` to jump back to the 2D
+to know when it died. Press :kbd:`F1` to jump back to the 2D
 Workspace. Select the ``Player`` node in the Scene dock and click on the
 Node tab next to the Inspector.
 

getting_started/step_by_step/ui_game_user_interface.rst

@@ -61,7 +61,7 @@ separate scenes and put them together, or prototype everything in a
 single scene and break it down later. I recommend working with a single
 scene as you can play with your UI's placement and proportions faster
 this way. Once it looks good, you can save entire sections of the node
-tree as reusable sub-scenes. We'll do just that in a moment.
+tree as reusable sub-scenes. We'll do that in a moment.
 
 For now, let's start with a few containers.
 
@@ -217,7 +217,7 @@ again and tweak the ``Bottom`` property until the text aligns with the
 
    With a Bottom value of 2 pixels, the Number aligns with the Title
 
-With this, we just finished the hardest part of the GUI.
+With this, we finished the hardest part of the GUI.
 Congratulations! Let's move on to the simpler nodes.
 
 Add the progress bar

getting_started/step_by_step/ui_introduction_to_the_ui_system.rst

@@ -156,7 +156,7 @@ NinePatchRect
 
 **NinePatchRect** takes a texture split in 3 rows and 3 columns. The
 center and the sides tile when you scale the texture, but it never
-scales the corners. It is very useful to build panels, dialogue boxes
+scales the corners. It is useful to build panels, dialogue boxes
 and scalable backgrounds for your UI.
 
 .. figure:: img/five_common_nodes_ninepatchrect.png

getting_started/step_by_step/your_first_game.rst

@@ -170,7 +170,7 @@ Start by declaring the member variables this object will need:
 
 
 Using the ``export`` keyword on the first variable ``SPEED`` allows us to
-set its value in the Inspector. This can be very handy for values that you
+set its value in the Inspector. This can be handy for values that you
 want to be able to adjust just like a node's built-in properties. Click on
 the ``Player`` node and set the speed property to ``400``.
 
@@ -273,7 +273,7 @@ We can prevent that if we *normalize* the velocity, which means we set
 its *length* to ``1``, and multiply by the desired speed. This means no
 more fast diagonal movement.
 
-.. tip:: If you've never used vector math before, or just need a refresher,
+.. tip:: If you've never used vector math before, or need a refresher,
          you can see an explanation of vector usage in Godot at :ref:`doc_vector_math`.
          It's good to know but won't be necessary for the rest of this tutorial.
 
@@ -281,7 +281,7 @@ We also check whether the player is moving so we can start or stop the
 AnimatedSprite animation.
 
 .. tip:: ``$`` returns the node at the relative path from this node, or returns ``null`` if the node is not found.
-         Since AnimatedSprite is a child of the current node, we can just use ``$AnimatedSprite``.
+         Since AnimatedSprite is a child of the current node, we can use ``$AnimatedSprite``.
          
          ``$`` is shorthand for ``get_node()``.
          So in the code above, ``$AnimatedSprite.play()`` is the same as ``get_node("AnimatedSprite").play()``.
@@ -895,7 +895,7 @@ StartButton
 
 -  Text: ``Start``
 
-The default font for ``Control`` nodes is very small and doesn't scale
+The default font for ``Control`` nodes is small and doesn't scale
 well. There is a font file included in the game assets called
 "Xolonium-Regular.ttf". To use this font, do the following for each of
 the three ``Control`` nodes:
@@ -904,7 +904,7 @@ the three ``Control`` nodes:
 
 .. image:: img/custom_font1.png
 
-2. Click on the "DynamicFont" you just added, and under "Font Data",
+2. Click on the "DynamicFont" you added, and under "Font Data",
    choose "Load" and select the "Xolonium-Regular.ttf" file. You must
    also set the font's ``Size``. A setting of ``64`` works well.
 
@@ -1134,7 +1134,7 @@ For one last bit of visual appeal, let's add a trail effect to the
 player's movement. Choose your ``Player`` scene and add a
 :ref:`Particles2D <class_Particles2D>` node named ``Trail``.
 
-There are a very large number of properties to choose from when
+There are a large number of properties to choose from when
 configuring particles. Feel free to experiment and create different
 effects. For the effect in this example, use the following settings:
 

getting_started/workflow/assets/import_process.rst

@@ -24,11 +24,11 @@ Changing import parameters
 
 Changing the import parameters of an asset in Godot (again, keep in mind
 import parameters are only present in non-native Godot resource types) is
-easy. Just select in the filesystem dock the relevant resource:
+easy. Select the relevant resource in the filesystem dock:
 
 .. image:: img/asset_workflow1.png
 
-And, after adjusting the parameters, just press "Reimport". The parameters
+Then, after adjusting the parameters, press "Reimport". The parameters
 used will be only for this asset and will be used on future reimports.
 
 Changing import parameters of several assets at the same time is also
@@ -64,7 +64,7 @@ Changing import resource type
 -----------------------------
 
 Some source assets can be imported as different types of resources.
-For this, just select the relevant type of resource desired and
+For this, select the relevant type of resource desired and
 press "Reimport":
 
 .. image:: img/asset_workflow2.png

getting_started/workflow/assets/importing_scenes.rst

@@ -6,7 +6,7 @@ Importing 3D Scenes
 Godot Scene Importer
 --------------------
 
-When dealing with 3D assets, Godot has a very flexible and configurable importer.
+When dealing with 3D assets, Godot has a flexible and configurable importer.
 
 Godot works with *scenes*. This means that the entire scene being worked on in your favorite 3D DCC will be
 transferred as close as possible.
@@ -36,7 +36,7 @@ Autodesk added built-in collada support to Maya and 3DS Max, but it's
 broken by default and should not be used. The best way to export this format
 is by using the
 `OpenCollada <https://github.com/KhronosGroup/OpenCOLLADA/wiki/OpenCOLLADA-Tools>`__
-plugins. They work really well, although they are not always up-to date
+plugins. They work well, although they are not always up-to date
 with the latest version of the software.
 
 Exporting DAE files from Blender
@@ -92,7 +92,7 @@ A special script to process the whole scene after import can be provided.
 This is great for post processing, changing materials, doing funny stuff
 with the geometry etc.
 
-Create a script that basically looks like this:
+Create a script that like this:
 
 ::
 
@@ -237,16 +237,16 @@ In general, this should always be turned on unless you suspect that an animation
 Clips
 ~~~~~~~~~~~~~~~~~~~~~
 
-It is possible to specify multiple animations from a single timeline as clips. Just specify from which frame to which frame each
+It is possible to specify multiple animations from a single timeline as clips. Specify from which frame to which frame each
 clip must be taken (and, of course, don't forget to specify the FPS option above).
 
 Scene Inheritance
 -----------------
 
-In many cases, it may be desired to do modifications to the imported scene. By default, this is not really possible because
+In many cases, it may be desired to do modifications to the imported scene. By default, this is not possible because
 if the source asset changes (source .dae,.gltf,.obj file re-exported from 3D modelling app), Godot will re-import the whole scene.
 
-It is possible, however, to do local modifications by using *Scene Inheritance*. Just try to open the imported scene and the
+It is possible, however, to do local modifications by using *Scene Inheritance*. Try to open the imported scene and the
 following dialog will appear:
 
 .. image:: img/scene_import4.png

getting_started/workflow/export/exporting_projects.rst

@@ -17,7 +17,7 @@ became evident that this was a bottleneck.
 On PC
 ~~~~~
 
-Distributing a game project on PC with Godot is rather easy. Just drop
+Distributing a game project on PC with Godot is rather easy. Drop
 the godot.exe (or godot) binary together in the same place as the
 engine.cfg file, zip it and you are done. This can be taken advantage of to
 make custom installers.
@@ -25,7 +25,7 @@ make custom installers.
 It sounds simple, but there are probably a few reasons why the developer
 may not want to do this. The first one is that it may not be desirable
 to distribute loads of files. Some developers may not like curious users
-peeking at how the game was made, others may just find it inelegant,
+peeking at how the game was made, others may find it inelegant,
 etc.
 
 Another reason is that, for distribution, the developer might prefer a
@@ -61,7 +61,7 @@ After many attempts at different export workflows, the current one has
 proven to work the best. At the time of this writing, not all platforms are
 supported yet, but the supported platforms continue to grow.
 
-To open the export menu, just click the "Export" button:
+To open the export menu, click the "Export" button:
 
 .. image:: img/export.png
 
@@ -149,7 +149,7 @@ template can be found, will export to ``some_name.exe``. The output
 path is relative to the project path or absolute. It does not respect
 the directory the command was invoked from.
 
-You can also configure it to export just the .pck or .zip file (allowing 
+You can also configure it to export only the .pck or .zip file (allowing 
 a single export to be used with multiple Godot executables). This
 takes place if:
 

getting_started/workflow/export/feature_tags.rst

@@ -74,7 +74,7 @@ Here is a list of most feature tags in Godot. Keep in mind they are *case sensit
 Custom features
 ---------------
 
-It is possible to add custom features to a build, just use the relevant
+It is possible to add custom features to a build, use the relevant
 field in the *export preset* used to generate it:
 
 .. image:: img/feature_tags1.png

getting_started/workflow/project_setup/project_organization.rst

@@ -52,7 +52,7 @@ Importing
 ---------
 
 Godot version previous to 3.0 did the import process from files outside
-the project. While this can be useful in very large projects, it
+the project. While this can be useful in large projects, it
 resulted in an organization hassle for most developers.
 
 Because of this, assets are now imported from within the project

tutorials/2d/2d_movement.rst

@@ -109,7 +109,7 @@ due to the two directions being added together.
 We can prevent that if we *normalize* the velocity, which means we set
 its *length* to ``1``, and multiply by the desired speed.
 
-.. tip:: If you've never used vector math before, or just need a refresher,
+.. tip:: If you've never used vector math before, or need a refresher,
          you can see an explanation of vector usage in Godot at :ref:`doc_vector_math`.
 
 
@@ -202,7 +202,7 @@ Again, pressing both keys at once will cancel out and result in no rotation.
 The rotation is applied directly to the body's ``rotation`` property.
 
 To set the velocity, we use the ``Vector2.rotated()`` method so that it points
-in the same direction as the body. ``rotated()`` is a very useful vector function
+in the same direction as the body. ``rotated()`` is a useful vector function
 that you can use in many circumstances where you would otherwise need to apply
 trigonometric functions.
 

tutorials/2d/custom_drawing_in_2d.rst

@@ -192,11 +192,11 @@ Remember the number of points our shape has to be decomposed into? We fixed this
 
 The next step consists of computing the actual positions of these 32 points that compose an arc. This is done in the first for-loop: we iterate over the number of points for which we want to compute the positions, plus one to include the last point. We first determine the angle of each point, between the starting and ending angles. 
 
-The reason why each angle is reduced by 90° is that we will compute 2D positions out of each angle using trigonometry (you know, cosine and sine stuff...). However, to be simple, cos() and sin() use radians, not degrees. The angle of 0° (0 radian) starts at 3 o'clock, although we want to start counting at 0 o'clock. So, we just reduce each angle by 90° in order to start counting from 0 o'clock.
+The reason why each angle is reduced by 90° is that we will compute 2D positions out of each angle using trigonometry (you know, cosine and sine stuff...). However, to be simple, cos() and sin() use radians, not degrees. The angle of 0° (0 radian) starts at 3 o'clock, although we want to start counting at 0 o'clock. So we reduce each angle by 90° in order to start counting from 0 o'clock.
 
 The actual position of a point located on a circle at angle 'angle' (in radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() return values between -1 and 1, the position is located on a circle of radius 1. To have this position on our support circle, which has a radius of 'radius', we simply need to multiply the position by 'radius'. Finally, we need to position our support circle at the 'center' position, which is performed by adding it to our Vector2 value. Finally, we insert the point in the PoolVector2Array which was previously defined.
 
-Now, we need to actually draw our points. As you can imagine, we will not simply draw our 32 points: we need to draw everything that is between each of them. We could have computed every point ourselves using the previous method, and drew it one by one. But this is too complicated and inefficient (except if explicitly needed). So, we simply draw lines between each pair of points. Unless the radius of our support circle is very big, the length of each line between a pair of points will never be long enough to see them. If this happens, we simply would need to increase the number of points.
+Now, we need to actually draw our points. As you can imagine, we will not simply draw our 32 points: we need to draw everything that is between each of them. We could have computed every point ourselves using the previous method, and drew it one by one. But this is too complicated and inefficient (except if explicitly needed). So, we simply draw lines between each pair of points. Unless the radius of our support circle is big, the length of each line between a pair of points will never be long enough to see them. If this happens, we simply would need to increase the number of points.
 
 Draw the arc on screen
 ^^^^^^^^^^^^^^^^^^^^^^
@@ -273,7 +273,7 @@ We can take this a step further and not only write a function that draws the pla
 
 Dynamic custom drawing
 ^^^^^^^^^^^^^^^^^^^^^^
-Alright, we are now able to draw custom stuff on screen. However, it is very static: let's make this shape turn around the center. The solution to do this is simply to change the angle_from and angle_to values over time. For our example, we will simply increment them by 50. This increment value has to remain constant, else the rotation speed will change accordingly.
+Alright, we are now able to draw custom stuff on screen. However, it is static: let's make this shape turn around the center. The solution to do this is simply to change the angle_from and angle_to values over time. For our example, we will simply increment them by 50. This increment value has to remain constant, else the rotation speed will change accordingly.
 
 First, we have to make both angle_from and angle_to variables global at the top of our script. Also note that you can store them in other nodes and access them using get_node().
 
@@ -413,5 +413,5 @@ Drawing your own nodes might also be desired while running them in the
 editor, to use as preview or visualization of some feature or
 behavior.
 
-Remember, to just use the "tool" keyword at the top of the script
+Remember to use the "tool" keyword at the top of the script
 (check the :ref:`doc_gdscript` reference if you forgot what this does).

tutorials/2d/particle_systems_2d.rst

@@ -76,7 +76,7 @@ Preprocess
 ~~~~~~~~~~
 
 Particle systems begin with zero particles emitted, then start emitting.
-This can be an inconvenience when just loading a scene and systems like
+This can be an inconvenience when loading a scene and systems like
 a torch, mist, etc. begin emitting the moment you enter. Preprocess is
 used to let the system process a given number of seconds before it is
 actually drawn the first time.

tutorials/2d/using_tilemaps.rst

@@ -176,7 +176,7 @@ one that looks better for you:
 
 -  Disable filtering and mipmaps for either the tileset texture or all tile textures if using separate images (see the :ref:`doc_import_images` asset pipeline tutorial).
 -  Enable pixel snap (Set ``Project > Project Settings >
-   Rendering > Quality > 2d > Use Pixel Snap`` to true, you can also just search for ``Pixel Snap``).
+   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.
 -  You can use a single, separate image for each tile. This will remove all artifacts, but

tutorials/3d/3d_performance_and_limitations.rst

@@ -20,7 +20,7 @@ usability and flexibility. Some practical examples of this are:
    by material to reduce the costs, but at the same time sorting has a
    cost.
 -  In 3D physics a similar situation happens. The best algorithms to
-   handle large amounts of physics objects (such as SAP) are very slow
+   handle large amounts of physics objects (such as SAP) are slow
    at insertion/removal of objects and ray-casting. Algorithms that
    allow faster insertion and removal, as well as ray-casting will not
    be able to handle as many active objects.
@@ -63,7 +63,7 @@ Godot's priorities will be like this:
    configuration).
 
 If a scene has, for example, 20.000 objects with 20.000 different
-materials each, rendering will be really slow. If the same scene has
+materials each, rendering will be slow. If the same scene has
 20.000 objects, but only uses 100 materials, rendering will be blazing
 fast.
 
@@ -74,7 +74,7 @@ It is a common thought that the lower the number of polygons in a model, the
 faster it will be rendered. This is *really* relative and depends on
 many factors.
 
-On a modern PC and console, vertex cost is low. Very low. GPUs
+On a modern PC and console, vertex cost is low. GPUs
 originally only rendered triangles, so all the vertices:
 
 1. Had to be transformed by the CPU (including clipping).
@@ -96,7 +96,7 @@ to be a lot more power efficient.
 To be more efficient, mobile GPUs attempt to avoid *overdraw*. This
 means, the same pixel on the screen being rendered (as in, with lighting
 calculation, etc.) more than once. Imagine a town with several buildings,
-GPUs don't really know what is visible and what is hidden until they
+GPUs don't know what is visible and what is hidden until they
 draw it. A house might be drawn and then another house in front of it
 (rendering happened twice for the same pixel!). PC GPUs normally don't
 care much about this and just throw more pixel processors to the
@@ -162,7 +162,7 @@ Level of detail (LOD)
 ---------------------
 
 As also mentioned before, using objects with less vertices can improve
-performance in some cases. Godot has a very simple system to change level
+performance in some cases. Godot has a simple system to change level
 of detail,
 :ref:`GeometryInstance <class_GeometryInstance>`
 based objects have a visibility range that can be defined. Having

tutorials/3d/baked_lightmaps.rst

@@ -7,7 +7,7 @@ Introduction
 ------------
 
 Baked lightmaps are an alternative workflow for adding indirect (or baked) lighting to a scene. Unlike the :ref:`doc_gi_probes` approach,
-baked lightmaps work fine on very low end PCs and mobile as they consume almost no resources in run-time.
+baked lightmaps work fine on low end PCs and mobile devices as they consume almost no resources in run-time.
 
 Unlike GIProbes, Baked Lightmaps are completely static, once baked they can't be modified at all. They also don't provide the scene with
 reflections, so using :ref:`doc_reflection_probes` together with it on interiors (or using a Sky on exteriors) is a requirement to
@@ -40,7 +40,7 @@ Unwrap from your 3D DCC
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 One option is to do it from your favorite 3D app. This approach is generally not recommended but it's explained first so you know it exists.
-The main advantage is that, on very complex objects that you may want to re-import a lot, the texture generation process can be quite costly within Godot,
+The main advantage is that, on complex objects that you may want to re-import a lot, the texture generation process can be quite costly within Godot,
 so having it unwrapped before import can be faster.
 
 Simply do an unwrap on the second UV2 layer.
@@ -52,7 +52,7 @@ And import normally. Remember you will need to set the texture size on the mesh
 .. image:: img/baked_light_lmsize.png
 
 If you use external meshes on import, the size will be kept.
-Be wary that most unwrappers in 3D DCCs are not very quality oriented, as they are meant to work quick. You will mostly need to use seams or other techniques to create better unwrapping.
+Be wary that most unwrappers in 3D DCCs are not quality oriented, as they are meant to work quick. You will mostly need to use seams or other techniques to create better unwrapping.
 
 Unwrap from within Godot
 ~~~~~~~~~~~~~~~~~~~~~~~~
@@ -77,7 +77,7 @@ final size of the lightmap texture (and, in consequence, the UV padding in the m
 The effect of setting this option is that all meshes within the scene will have their UV2 maps properly generated.
 
 As a word of warning: When reusing a mesh within a scene, keep in mind that UVs will be generated for the first instance found. If the mesh is re-used with different scales (and the scales
-are wildly different, more than half or twice), this will result in inefficient lightmaps. Just don't reuse a source mesh at very different scales if you are planning to use lightmapping.
+are wildly different, more than half or twice), this will result in inefficient lightmaps. Just don't reuse a source mesh at different scales if you are planning to use lightmapping.
 
 Checking UV2
 ~~~~~~~~~~~~
@@ -144,7 +144,7 @@ Besides the capture size, quality can be modified by setting the **Bake Mode**.
 
 .. image:: img/baked_light_mode.png
 
-- **Voxel Cone**: Trace: Is the default one, it's less precise but very fast. Look similar (but slightly better) to GIProbe.
+- **Voxel Cone**: Trace: Is the default one, it's less precise but fast. Look similar (but slightly better) to GIProbe.
 - **Ray Tracing**: This method is more precise, but can take considerably longer to bake. If used in low or medium quality, some scenes may produce grain.
 
 
@@ -162,7 +162,7 @@ Configuring Bake
 
 Several more options are present for baking:
 
-- **Bake Subdiv**: Godot lightmapper uses a grid to transfer light information around. The default value is fine and should work for most cases. Increase it in case you want better lighting on very small details or your scene is very large. 
+- **Bake Subdiv**: Godot lightmapper uses a grid to transfer light information around. The default value is fine and should work for most cases. Increase it in case you want better lighting on small details or your scene is large. 
 - **Capture Subdiv**: This is the grid used for real-time capture information (lighting dynamic objects). Default value is generally OK, it's usually smaller than Bake Subdiv and can't be larger than it.
 - **Bake Quality**: Three bake quality modes are provided, Low, Medium and High. Each takes less and more time.
 - **Bake Mode**: The baker can use two different techniques: *Voxel Cone Tracing* (fast but approximate), or *RayTracing* (slow, but accurate).

tutorials/3d/environment_and_post_processing.rst

@@ -67,7 +67,7 @@ Ambient Light
 
 Ambient (as defined here) is a type of light that affects every piece of geometry with the same intensity. It is global and independent of lights that might be added to the scene. 
 
-There are two types of ambient light, the *Ambient Color* (which is just a constant color multiplied by the material albedo), and then one obtained from the *Sky* (as described before, but a sky needs to be set as background for this to be enabled). 
+There are two types of ambient light, the *Ambient Color* (which is a constant color multiplied by the material albedo), and then one obtained from the *Sky* (as described before, but a sky needs to be set as background for this to be enabled). 
 
 .. image:: img/environment_ambient.png
 
@@ -78,7 +78,7 @@ Here is a comparison of how different ambient light affects a scene:
 
 .. image:: img/environment_ambient2.png
 
-Finally there is a **Energy** setting, which is just a multiplier, useful when working with HDR.
+Finally there is a **Energy** setting, which is a multiplier, useful when working with HDR.
 
 In general, ambient light should only be used for simple scenes, large exteriors or for performance reasons (ambient light is cheap), as it does not provide the best lighting quality. It's better to generate
 ambient light from ReflectionProbe or GIProbe, which will more faithfully simulate how indirect light propagates. Below is a comparison in quality between using a flat ambient color and a GIProbe:
@@ -90,7 +90,7 @@ Using one of the methods described above, objects get constant ambient lighting
 Fog
 ^^^
 
-Fog, just as in real life, makes distant objects fade away into an uniform color. The physical effect is actually pretty complex, but Godot provides a good approximation. There are two kinds of fog in Godot:
+Fog, as in real life, makes distant objects fade away into an uniform color. The physical effect is actually pretty complex, but Godot provides a good approximation. There are two kinds of fog in Godot:
 
 - **Depth Fog:** This one is applied based on the distance from the camera.
 - **Height Fog:** This one is applied to any objects below (or above) a certain height, regardless of the distance from the camera.
@@ -179,7 +179,7 @@ This can be simulated with Screen Space Ambient Occlusion. As you can see in the
 
 It is a common mistake to enable this effect, turn on a light and not be able to appreciate it. This is because SSAO only acts on *ambient* light, not direct light. 
 
-This is why, in the image above, the effect is less noticeable under the direct light (at the left). If you want to force SSAO to work with direct light too, just use the **Light Affect** parameter (even though this is not correct, some artists like how it looks). 
+This is why, in the image above, the effect is less noticeable under the direct light (at the left). If you want to force SSAO to work with direct light too, use the **Light Affect** parameter (even though this is not correct, some artists like how it looks). 
 
 SSAO looks best when combined with a real source of indirect light, like GIProbe:
 
@@ -218,7 +218,7 @@ It has an initial **Distance** with a **Transition** region (in world units):
 
 The **Amount** parameter controls the amount of blur. For larger blurs, tweaking the **Quality** may be needed in order to avoid arctifacts.
 
-It is very common to use both blurs together to focus the viewer's attention on a given object:
+It is common to use both blurs together to focus the viewer's attention on a given object:
 
 .. image:: img/environment_mixed_blur.png
 
@@ -231,7 +231,7 @@ the **Glow** effect.
 
 .. image:: img/environment_glow1.png
 
-By default, even if the effect is enabled, it will be very weak or invisible. One of two conditions need to happen for it to actually show:
+By default, even if the effect is enabled, it will be weak or invisible. One of two conditions need to happen for it to actually show:
 
 - 1) The light in a pixel surpasses the **HDR Threshold** (where 0 is all light surpasses it, and 1.0 is light over the tonemapper **White** value). Normally this value is expected to be at 1.0, but it can be lowered to allow more light to bleed. There is also an extra parameter, **HDR Scale** that allows scaling (making brighter or darker) the light surpasing the threshold.
 

tutorials/3d/fps_tutorial/part_five.rst

@@ -126,7 +126,7 @@ 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.
 
-If ``grenade_timer`` is at ``GRENADE_TIMER`` or higher, we then need to check if we just 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 we waited long enough and need 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.
 
@@ -140,7 +140,7 @@ 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 just added ``delta``, this will only be called once.
+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.
 
 ______
@@ -241,7 +241,7 @@ 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 just go over what's changed.
+The code above is almost identical to the code for ``Grenade.gd``, so let's go over what's changed.
 
 First, we have a few more global variables:
 
@@ -262,10 +262,10 @@ ______
 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 just ignore it by returning.
+we need to make sure we're not going to stick to ourself. 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 just ignore it by returning.
+If the body we've collided with is indeed ``player_body``, we ignore it by returning.
 
 Next we check if we are attached already or not.
 
@@ -319,7 +319,7 @@ Okay, now lets start making the grenades work with our player. Add the following
 * ``sticky_grenade_scene``: The sticky grenade scene we worked on earlier.
 * ``GRENADE_THROW_FORCE``: The force at which we throw the grenade at.
          
-Most of these variables are very similar to how we have out weapons set up.
+Most of these variables are similar to how we have out weapons set up.
 
 .. tip:: While it's possible to make a more modular grenade system, I found it was not worth the additional complexity for just two grenades.
          If you were going to make a more complex FPS with more grenades, you'd likely want to make a system for grenades similar to how we have the weapons set up.
@@ -405,10 +405,10 @@ While we're still in ``Player.gd``, let's add a function to add grenades. Add th
 
 Now we can add a grenade using ``add_grenade``, and it will automatically be clamped to a maximum of ``4`` grenades.
 
-.. tip:: You can change the ``4`` to a constant if you want. You'd just need to make a new global constant, something like ``MAX_GRENADES``, and
+.. 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, just remove the line that clamps the grenades altogether!
+         If you do not want to limit how many grenades you 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,7 +427,7 @@ 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 just like we call ``add_ammo``.
+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``.
 
 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:
@@ -506,7 +506,7 @@ 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 just a design choice,
+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,
 but I feel it gives ``UNARMED`` a use.
 
 Next we check to see whether or not ``grabbed_object`` is ``null``.
@@ -565,7 +565,7 @@ If we are holding an object, we set its global position to the camera's position
 
 ______
 
-Before we test this, we need to change something in ``_physics_process``. While we're holding an object, we really don't
+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:
 
 ::
@@ -595,7 +595,7 @@ 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>`.
 
-Open up ``Base`` and you'll find it's just a :ref:`StaticBody <class_StaticBody>` and a mesh. Open up ``Head`` and you'll find there's several meshes,
+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
@@ -842,7 +842,7 @@ we subtract ``delta`` from ``ammo_reload_timer``. If ``ammo_reload_timer`` is eq
 we've waited long enough to refill the turret.
 
 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
-check to see if ``destroyed_timer`` is more than zero. If destroyed timer is more than zero, we just subtract ``delta`` from ``destroyed_timer``.
+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
 ``false``.
@@ -932,7 +932,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 just 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 our bullets use the ``bullet_hit`` function, we need to add that to our player.
 
 Open ``Player.gd`` and add the following:
 

tutorials/3d/fps_tutorial/part_four.rst

@@ -169,7 +169,7 @@ 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!
 
-We then account for the joypad's dead zone, just like in ``process_input``.
+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``.
 
@@ -190,7 +190,7 @@ Once ``process_view_input`` is added to ``_physics_process``, you should be able
 .. 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.
           
           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,
-          and check if it's over a certain value, say ``0.8`` for example. If it is, you just add the same code as when the ``fire`` action was pressed.
+          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
 -------------------------------
@@ -280,7 +280,7 @@ Open up ``Health_Pickup.tscn``.
 
 Expand ``Holder`` if it's not already expanded. Notice how we have two Spatial nodes, one called ``Health_Kit`` and another called ``Health_Kit_Small``.
 
-This is because we're actually going to be making two sizes of health pick ups, one small and one large/normal. ``Health_Kit`` and ``Health_Kit_Small`` just
+This is because we're actually going to be making two sizes of health pick ups, one small and one large/normal. ``Health_Kit`` and ``Health_Kit_Small`` only
 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
@@ -452,10 +452,10 @@ when a ``Health_Pickup`` instanced scene is selected, from a convenient drop dow
 Adding the ammo pick ups
 ------------------------
 
-While adding health is good and all, we can't really 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 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``, just with the meshes and trigger collision shapes changed slightly to adjust
+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
 for the difference in mesh sizes.
 
 Select ``Ammo_Pickup`` and add a new script called ``Ammo_Pickup.gd``. Add the following:
@@ -523,7 +523,7 @@ You may have noticed this code looks almost exactly the same as the health pick
 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.
-(Unlike ``HEALTH_AMMOUNTS`` which was how many health points, we instead just add an entire clip for the current weapon, instead of the raw ammo amount)
+(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``.
 
@@ -552,7 +552,7 @@ _______
 
 With that done, you should now be able to get additional ammo! Go place some ammo pick ups in one/both/all of the scenes and give it a try!
 
-.. note:: Notice how we're not limiting the amount of ammo you can carry. To limit the amount of ammo each weapon can carry, you just need to add a additional variable to
+.. note:: Notice how we're not limiting the amount of ammo you can carry. To limit the amount of ammo each weapon can carry, you need to add a additional variable to
           each weapon's script, and then clamp the weapon's ``spare_ammo`` variable after adding ammo in ``add_ammo``.
 
 Adding breakable targets

tutorials/3d/fps_tutorial/part_one.rst

@@ -351,7 +351,7 @@ If you want to move using the world space directional vectors, you'd do somethin
         node.translate(Vector3(-1, 0, 0))
 
 .. note:: Notice how we do not need to do any calculations to get world space directional vectors.
-          We can just define a few :ref:`Vector3 <class_Vector3>` variables and input the values pointing in each direction.
+          We can define a few :ref:`Vector3 <class_Vector3>` variables and input the values pointing in each direction.
 
 Here is what world space looks like in 2D:
 
@@ -553,7 +553,7 @@ 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.
 
-Now we just need to add a few lines of code, starting in ``_ready``. Add the following to ``_ready``:
+Now we need to add a few lines of code, starting in ``_ready``. Add the following to ``_ready``:
 
 ::
     
@@ -588,14 +588,14 @@ Let's go over the additions:
 
 We set ``is_sprinting`` to true when we are 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 just going to change the ``is_sprinting`` variable.
+they sprint. Here in ``process_input`` we're 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
 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.
 
 _________
 
-Now we just need to change a couple things in ``process_movement``. First, replace ``target *= MAX_SPEED`` with the following:
+Now we need to change a couple things in ``process_movement``. First, replace ``target *= MAX_SPEED`` with the following:
 
 ::
     

tutorials/3d/fps_tutorial/part_six.rst

@@ -28,9 +28,9 @@ The main menu is broken up into three different panels, each representing a diff
 'screen' of our main menu.
 
 .. note:: The ``Background_Animation`` node is just so the background of the menu is a bit more interesting than a solid color.
-          It's just a camera looking around the skybox, nothing fancy.
+          It's a camera looking around the skybox, nothing fancy.
 
-Feel free to expand all of the nodes and see how their set up. Just remember to keep only ``Start_Menu`` visible
+Feel free to expand all of the nodes and see how their set up. Remember to keep only ``Start_Menu`` visible
 when you're done, as that's the screen we want to show first when we enter the main menu.
 
 Select ``Main_Menu`` (the root node) and create a new script called ``Main_Menu.gd``. Add the following:
@@ -120,7 +120,7 @@ Select ``Main_Menu`` (the root node) and create a new script called ``Main_Menu.
         globals.joypad_sensitivity = $Options_Menu/HSlider_Joypad_Sensitivity.value
 
 
-Most of the code here relates to making UIs, which is really outside of the purpose of this tutorial series.
+Most of the code here relates to making UIs, which is outside of the purpose of this tutorial series.
 **We're only going to look at the UI related code briefly.**
 
 .. tip:: See :ref:`doc_ui_main_menu` and the tutorials following for better ways to make GUIs and UIs!
@@ -189,7 +189,7 @@ We then set the ``mouse_sensitivity`` and ``joypad_sensitvity`` variables to the
 Making the ``Globals`` singleton
 --------------------------------
 
-Now, for this all to work we really need to make the ``Globals`` singleton. Make a new script in the ``Script`` tab and call it ``Globals.gd``.
+Now, for this all to work we need to create the ``Globals`` singleton. Make a new script in the ``Script`` tab and call it ``Globals.gd``.
 
 Add the following to ``Globals.gd``.
 
@@ -206,8 +206,8 @@ Add the following to ``Globals.gd``.
     func load_new_scene(new_scene_path):
         get_tree().change_scene(new_scene_path)
 
-As you can see, it's really quite small and simple. As this part progresses we will
-keeping adding complexities to ``Global.gd``, but for now all it really is doing is holding two variables for us, and abstracting how we change scenes.
+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.
 
 * ``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``.
@@ -333,7 +333,7 @@ instancing/spawning lots of nodes and are not freeing them.
 
 ______
         
-Now we just need to add ``set_debug_display`` to ``Globals.gd``:
+Now we need to add ``set_debug_display`` to ``Globals.gd``:
 
 ::
     
@@ -456,7 +456,7 @@ Add the following to ``Globals.gd``:
             
 ``popup_closed`` will resume the game and destroy the pop up if there is one.
     
-``popup_quit`` is very similar, but we're also making sure the mouse is visible and changing scenes to the title screen.
+``popup_quit`` is similar, but we're also making sure the mouse is visible and changing scenes to the title screen.
 
 Add the following to ``Globals.gd``:
 
@@ -886,7 +886,7 @@ Lets go over these global variables.
 * ``SIMPLE_AUDIO_PLAYER_SCENE``: The simple audio player scene.
 * ``created_audio``: A list to hold all of the simple audio players we create
 
-.. note:: If you want to add additional audio, you just need to add it to ``audio_clips``. No audio files are provided in this tutorial,
+.. 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.
           
           One site I'd recommend is **GameSounds.xyz**.

tutorials/3d/fps_tutorial/part_three.rst

@@ -188,7 +188,7 @@ Now we can see how much ammo we have through the HUD.
 Adding reloading to the weapons
 -------------------------------
 
-Now that we can run our weapons out of ammo, we really need a way to fill them back up. Let's add reloading next!
+Now that we can run our weapons out of ammo, we need a way to 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.
 
@@ -267,7 +267,7 @@ Now we need to add reloading to the rifle. Open up ``Weapon_Rifle.gd`` and add t
     
 These variables are exactly the same as the pistol, just with ``RELOADING_ANIM_NAME`` changed to the rifle's reloading animation.
 
-Now we just need to add ``reload_weapon`` to ``Weapon_Rifle.gd``:
+Now we need to add ``reload_weapon`` to ``Weapon_Rifle.gd``:
 
 ::
     
@@ -312,19 +312,19 @@ The last bit we need to do for the weapons is add 'reloading' to the knife. Add
 Since we both cannot reload or refill a knife, we set both constants to ``false``. We also define ``RELOADING_ANIM_NAME`` as an empty string, since the knife
 has no reloading animation.
 
-Now we just need to add ``reloading_weapon``, and thankfully it's really simple:
+Now we need to add ``reloading_weapon``:
 
 ::
     
     func reload_weapon():
         return false
 
-Since we cannot reload a knife, we just always return ``false``.
+Since we cannot reload a knife, we always return ``false``.
 
 Adding reloading to the player
 ------------------------------
 
-Now we just 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 global variable:
 
 ::
     
@@ -584,7 +584,7 @@ First we need to load the ``SimpleAudioPlayer.tscn``. Place the following code i
 
     var simple_audio_player = preload("res://Simple_Audio_Player.tscn")
 
-Now we just need to instance the simple audio player when we need it, and then call its
+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:
 
@@ -611,7 +611,7 @@ is the root node that our player is under, which could 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.
-This is really only potentially a issue depending on how you handle scene loading.
+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.
@@ -633,7 +633,7 @@ Now, we want to make a noise when we fire the pistol, so add the following to th
 
 Now when we fire our pistol, we'll play the ``pistol_shot`` sound.
 
-To make a sound when we reload, we just need to add the following right under ``player_node.animation_manager.set_animation(RELOADING_ANIM_NAME)`` in the
+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
 ``reload_weapon`` function:
 
 ::
@@ -655,7 +655,7 @@ To play sounds when the rifle is fired, add the following to the end of the ``fi
 
 Now when we fire our rifle, we'll play the ``rifle_shot`` sound.
 
-To make a sound when we reload, we just need to add the following right under ``player_node.animation_manager.set_animation(RELOADING_ANIM_NAME)`` in the
+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
 ``reload_weapon`` function:
 
 ::
@@ -674,7 +674,7 @@ Now you have weapons with limited ammo that play sounds when you fire them!
 At this point we have all of the basics of a FPS working.
 There's still a few things that would be nice to add, and we're going to add them in the next three parts!
 
-For example, right now we have no way to add ammo to our spares, so we'll eventually run out. Also, we don't really
+For example, right now we have no way to add ammo to our spares, so we'll eventually run out. Also, we don't
 have anything to shoot at outside of the :ref:`RigidBody <class_RigidBody>` nodes.
 
 In In :ref:`doc_fps_tutorial_part_four` we'll add some targets to shoot at, along with some health and ammo pick ups!

tutorials/3d/fps_tutorial/part_two.rst

@@ -251,7 +251,7 @@ check for every possible animation state. If we need to, we transition into anot
              the end of the animation and are about to loop again.
 
 .. note:: the transitions in ``animation_ended`` ideally would be part of the data in ``states``, but in
-          an effort to make the tutorial easier to understand, we'll just hard code each state transition
+          an effort to make the tutorial easier to understand, we'll hard code each state transition
           in ``animation_ended``.
 
 _________
@@ -260,7 +260,7 @@ Finally we have ``animation_callback``. This function will be called by a functi
 If we have a :ref:`FuncRef <class_FuncRef>` assigned to ``callback_function``, then we call that passed in function. If we do not
 have a :ref:`FuncRef <class_FuncRef>` assigned to ``callback_function``, we print out a warning to the console.
 
-.. tip:: Try running ``Testing_Area.tscn`` just to make sure there is no runtime issues. If the game runs but nothing
+.. tip:: Try running ``Testing_Area.tscn`` to make sure there is no runtime issues. If the game runs but nothing
          seems to have changed, then everything is working correctly.
 
 Getting the animations ready
@@ -275,7 +275,7 @@ Open up ``Player.tscn`` if you don't have it open and navigate to the :ref:`Anim
 We need to attach a function track to three of our animations: The firing animation for the pistol, rifle, and knife.
 Let's start with the pistol. Click the animation drop down list and select "Pistol_fire".
 
-Now scroll down to the very bottom of the list of animation tracks. The final item in the list should read
+Now scroll down to the bottom of the list of animation tracks. The final item in the list should read
 ``Armature/Skeleton:Left_UpperPointer``. Now at the bottom of the list, click the plus icon on the bottom
 bar of animation window, right next to the loop button and the up arrow.
 
@@ -289,7 +289,7 @@ option that reads "Add Call Func Track". This will open a window showing the ent
 
 Now at the bottom of list of animation tracks you will have a green track that reads "AnimationPlayer".
 Now we need to add the point where we want to call our callback function. Scrub the timeline until you
-reach the point where the muzzle just starts to flash.
+reach the point where the muzzle starts to flash.
 
 .. note:: The timeline is the window where all of the points in our animation are stored. Each of the little
           points represents a point of animation data.
@@ -335,7 +335,7 @@ Let's repeat the process for the rifle and knife firing animations!
           Follow the steps in the above if you get lost! It is exactly the same, just on a different animation.
 
 Go to the "Rifle_fire" animation from the animation drop down. Add the function callback track once you reach the bottom of the
-animation track list by clicking the little plus icon at the bottom of the screen. Find the point where the muzzle just starts
+animation track list by clicking the little plus icon at the bottom of the screen. Find the point where the muzzle starts
 to flash and click the little green plus symbol to add a function callback point at that position on the track.
 
 Next, click the "enable editing of individual keys" button.
@@ -343,12 +343,12 @@ Select the newly created function callback point, put "animation_callback" into
 Click the "enable editing of individual keys" button again to turn off individual key editing.
 so we cannot change one of the transform tracks by accident.
 
-Now we just need to apply the callback function track to the knife animation. Select the "Knife_fire" animation and scroll to the bottom of the
+Now we need to apply the callback function track to the knife animation. Select the "Knife_fire" animation and scroll to the bottom of the
 animation tracks. Click the plus symbol at the bottom of the animation window and add a function callback track.
 Next find a point around the first third of the animation to place the animation callback function point at.
 
-.. note:: We will not actually be firing the knife, and the animation really is a stabbing animation rather than a firing one.
-         For this tutorial we are just reusing the gun firing logic for our knife, so the animation has been named in a style that
+.. note:: We will not actually be firing the knife, and the animation is a stabbing animation rather than a firing one.
+         For this tutorial we are reusing the gun firing logic for our knife, so the animation has been named in a style that
          is consistent with the other animations.
 
 From there click the little green plus to add a function callback point at the current position. Then click the "enable editing of individual keys"
@@ -359,7 +359,7 @@ so we cannot change one of the transform tracks by accident.
 
 .. tip:: Be sure to save your work!
 
-With that done, we are almost ready to start adding the ability to fire to our player script! We just need to setup one last scene:
+With that done, we are almost ready to start adding the ability to fire to our player script! We need to setup one last scene:
 The scene for our bullet object.
 
 Creating the bullet scene
@@ -378,15 +378,15 @@ There are several advantages to this method. The first being we do not have to s
 and then move on, and the bullet itself with handle checking for collisions, sending the proper signal(s) to the object it collides with, and destroying itself.
 
 Another advantage is we can have more complex bullet movement. If we want to make the bullet fall ever so slightly as time goes on, we can make the bullet
-controlling script slowly push the bullet towards the ground. Using a object also makes the bullet take time to reach its target, it doesn't just instantly
-hit whatever its pointed at. This feels more realistic because nothing in real life really moves instantly from one point to another.
+controlling script slowly push the bullet towards the ground. Using a object also makes the bullet take time to reach its target, it doesn't instantly
+hit whatever its pointed at. This feels more realistic because nothing in real life moves instantly from one point to another.
 
 One of the huge disadvantages performance. While having each bullet calculate their own paths and handle their own collision allows for a lot of flexibility,
 it comes at the cost of performance. With this method we are calculating every bullet's movement every step, and while this may not be a problem for a few dozen
 bullets, it can become a huge problem when you potentially have several hundred bullets.
 
 Despite the performance hit, many first person shooters include some form of object bullets. Rocket launchers are a prime example because in many
-first person shooters, Rockets do not just instantly explode at their target position. You can also find bullets as object many times with grenades
+first person shooters, rockets do not just instantly explode at their target position. You can also find bullets as object many times with grenades
 because they generally bounce around the world before exploding.
 
 .. note:: While I cannot say for sure this is the case, these games *probably* use bullet objects in some form or another:
@@ -420,19 +420,19 @@ We set the raycast's origin to the starting position of the bullet, and based on
           - Call of Duty (Assault rifles, light machine guns, sub machine guns, pistols, and more)
           - Battlefield (Assault rifles, SMGs, carbines, pistols, and more)
 
-One huge advantage for this method is it's really light on performance.
+One huge advantage for this method is it's light on performance.
 Sending a couple hundred rays through space is *way* easier for the computer to calculate than sending a couple hundred
 bullet objects.
 
 Another advantage is we can instantly know if we've hit something or not exactly when we call for it. For networking this is important because we do not need
-to sync the bullet movements over the Internet, we just need to send whether or not the raycast hit.
+to sync the bullet movements over the Internet, we only need to send whether or not the raycast hit.
 
 Raycasting does have some disadvantages though. One major disadvantage is we cannot easily cast a ray in anything but a linear line.
 This means we can only fire in a straight line for however long our ray length is. You can create the illusion of bullet movement by casting
 multiple rays at different positions, but not only is this hard to implement in code, it is also is heavier on performance.
 
 Another disadvantage is we cannot see the bullet. With bullet objects we can actually see the bullet travel through space if we attach a mesh
-to it, but because raycasts happen instantly, we do not really have a decent way of showing the bullets. You could draw a line from the origin of the
+to it, but because raycasts happen instantly, we do not have a decent way of showing the bullets. You could draw a line from the origin of the
 raycast to the point where the raycast collided, and that is one popular way of showing raycasts. Another way is simply not drawing the raycast
 at all, because theoretically the bullets move so fast our eyes could not see it anyway.
 
@@ -506,7 +506,7 @@ change how the bullet interacts with the world.
 
 .. note:: The reason we are using a kill timer is so we do not have a case where we
           get a bullet travelling forever. By using a kill timer, we can assure that
-          no bullets will just travel forever and consume resources.
+          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
          as the reason given in :ref:`doc_fps_tutorial_part_one`: We want to treat these variables like constants, but we want to be
@@ -686,14 +686,14 @@ By using a modular design with a consistent interface, we can keep ``Player.gd``
 
 _________
 
-In ``_ready`` we simply just pass over it.
+In ``_ready`` we simply pass over it.
 
 There is one thing of note though, an assumption we're assuming we'll fill in ``Player.gd``.
 
 We are going to assume that ``Player.gd`` will pass themselves in before calling any of the functions in ``Weapon_Pistol.gd``.
 
 While this can lead to situations where the player does not pass themselves in (because we forget), we would have to have a long string
-of ``get_parent`` calls to traverse up the scene tree to retrieve the player. This does not look very pretty (``get_parent().get_parent().get_parent()`` and so on)
+of ``get_parent`` calls to traverse up the scene tree to retrieve the player. This does not look pretty (``get_parent().get_parent().get_parent()`` and so on)
 and it is relatively safe to assume we will remember to pass ourselves to each weapon in ``Player.gd``.
 
 _________
@@ -744,7 +744,7 @@ _________
 
 Finally, let's look at ``unequip_weapon``:
 
-``unequip_weapon`` is very similar to ``equip_weapon``, but instead we're checking things in reverse.
+``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``.
@@ -905,7 +905,7 @@ we call it, passing in the amount of damage a single knife swipe does (``DAMAGE`
 
 .. 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
-          needed to calculate a rough position for each body is not really worth the effort.
+          needed to calculate a rough position for each body is not worth the effort.
 
 Making the weapons work
 -----------------------
@@ -939,7 +939,7 @@ Lets go over what these new variables will do:
 - ``WEAPON_NAME_TO_NUMBER``: A dictionary allowing us to convert from a weapon's name to its number. We'll use this for changing weapons.
 - ``changing_weapon``: A boolean to track whether or not we are changing guns/weapons.
 - ``changing_weapon_name``: The name of the weapon we want to change to.
-- ``health``: How much health our player has. In this part of the tutorial we will not really be using it.
+- ``health``: How much health our player has. In this part of the tutorial we will not be using it.
 - ``UI_status_label``: A label to show how much health we have, and how much ammo we have both in our gun and in reserves.
 
 _________
@@ -1150,9 +1150,9 @@ We also set ``current_weapon_name`` to ``changing_weapon_name``, since the curre
 
 _________
 
-Now, we just 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 the weapons!
 
-We just need to add ``fire_bullet``, which will be called when by the :ref:`AnimationPlayer <class_AnimationPlayer>` at those
+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 +1166,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 just ``return``.
+First we check if we are changing weapons or not. If we are 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 just tell the current weapon we are using to fire by calling its ``fire_weapon`` function.
+Then we tell the current weapon we are 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
@@ -1180,7 +1180,7 @@ Then we just tell the current weapon we are using to fire by calling its ``fire_
 
 _______
 
-Before we are ready to test our new weapons, we still have just a little bit of work to do.
+Before we are ready to test our new weapons, we still have a little bit of work to do.
 
 Creating some test subjects
 ---------------------------
@@ -1188,7 +1188,7 @@ Creating some test subjects
 Create a new script by going to the scripting window, clicking "file", and selecting new.
 Name this script ``RigidBody_hit_test`` and make sure it extends :ref:`RigidBody <class_RigidBody>`.
 
-Now we just need to add this code:
+Now we need to add this code:
 
 ::
 
@@ -1222,7 +1222,7 @@ the :ref:`RigidBody <class_RigidBody>` seem to move in response to the bullet co
 
 _______
 
-Now we just need to attach this script to all of the :ref:`RigidBody <class_RigidBody>` nodes we want to effect.
+Now we need to attach this script to all of the :ref:`RigidBody <class_RigidBody>` nodes we want to effect.
 
 Open up ``Testing_Area.tscn`` and select all of the cubes parented to the ``Cubes`` node.
 

tutorials/3d/gi_probes.rst

@@ -20,7 +20,7 @@ The main downside of GIProbes are:
 
 - A small amount of light leaking can occur if the level is not carefully designed. this must be artist-tweaked.
 - Performance requirements are higher than for lightmaps, so it may not run properly in low end integrated GPUs (may need to reduce resolution).
-- Reflections are voxelized, so they don't look as sharp as with ReflectionProbe, but in exchange they are volumetric so any room size or shape works for them. Mixing them with Screen Space Reflection also works very well.
+- Reflections are voxelized, so they don't look as sharp as with ReflectionProbe, but in exchange they are volumetric so any room size or shape works for them. Mixing them with Screen Space Reflection also works well.
 - They consume considerably more video memory than Reflection Probes, so they must be used by care in the right subdivision sizes.
 
 Setting Up
@@ -79,7 +79,7 @@ The difference becomes clear in the image below, where light from the sky goes f
 
 .. image:: img/giprobe_interior.png
 
-As complex buildings may mix interiors with exteriors, combining GIProbes for both parts works very well.
+As complex buildings may mix interiors with exteriors, combining GIProbes for both parts works well.
 
 
 Tweaking

tutorials/3d/introduction_to_3d.rst

@@ -6,7 +6,7 @@ Introduction to 3D
 Creating a 3D game can be challenging. That extra Z coordinate makes
 many of the common techniques that helped to make 2D games simple no
 longer work. To aid in this transition, it is worth mentioning that
-Godot uses very similar APIs for 2D and 3D. Most nodes are the same and
+Godot uses similar APIs for 2D and 3D. Most nodes are the same and
 are present in both 2D and 3D versions. In fact, it is worth checking
 the 3D platformer tutorial, or the 3D kinematic character tutorials,
 which are almost identical to their 2D counterparts.

tutorials/3d/inverse_kinematics.rst

@@ -16,7 +16,7 @@ Initial problem
 Talking in Godot terminology, the task we want to solve here is to position
 our 2 angles we talked about above so, that the tip of the lowerarm bone is
 as close to the target point (which is set by the target Vector3()) as possible
-using only rotations. This task is very calculation-intensive and never
+using only rotations. This task is calculation-intensive and never
 resolved by analytical equation solving. So, it is an underconstrained
 problem, which means there is an unlimited number of solutions to the
 equation.
@@ -63,7 +63,7 @@ IK bone and calculate using that.
 Implementation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-We will just use an exported variable for the bone length to make it easy.
+We will use an exported variable for the bone length to make it easy.
 
 ::
 
@@ -110,7 +110,7 @@ And for the ``_process()`` function:
     func _process(delta):
         pass_chain(delta)
 
-Executing this script will just pass through the bone chain, printing bone
+Executing this script will pass through the bone chain, printing bone
 transforms.
 
 ::

tutorials/3d/lights_and_shadows.rst

@@ -137,8 +137,8 @@ radius .
 
 .. image:: img/light_omni.png
 
-In real life, light attenuation is an inverse function, which means omni lights don't really have a radius.
-This is a problem, because it means computing several omni lights would become really demanding.
+In real life, light attenuation is an inverse function, which means omni lights don't have a radius.
+This is a problem, because it means computing several omni lights would become demanding.
 
 To solve this, a *Range* is introduced, together with an attenuation function. 
 
@@ -152,10 +152,10 @@ These two parameters allow tweaking how this works visually, in order to find ae
 Omni Shadow Mapping
 ^^^^^^^^^^^^^^^^^^^
 
-Omni light shadow mapping is relatively straightforward, as it just works. The main issue that needs to be
+Omni light shadow mapping is relatively straightforward. The main issue that needs to be
 considered is the algorithm used to render it. 
 
-Omni Shadows can be rendered as either **"Dual Paraboloid" or "Cube Mapped"**. The former renders very quickly but can cause deformations,
+Omni Shadows can be rendered as either **"Dual Paraboloid" or "Cube Mapped"**. The former renders quickly but can cause deformations,
 while the later is more correct but more costly. 
 
 .. image:: img/shadow_omni_dp_cm.png
@@ -183,7 +183,7 @@ Spot lights share the same **Range** and **Attenuation** as **OmniLight**, and a
 Spot Shadow Mapping
 ^^^^^^^^^^^^^^^^^^^
 
-Spots don't need any parameters for shadow mapping, they should just work. Keep in mind that, at more than 89 degrees of aperture, shadows
+Spots don't need any parameters for shadow mapping. Keep in mind that, at more than 89 degrees of aperture, shadows
 stop functioning for spots, and you should consider using an Omni light.
 
 Shadow Atlas

tutorials/3d/reflection_probes.rst

@@ -12,7 +12,7 @@ Reflection Probes are used as a source of reflected and ambient light for object
 A probe of this type captures the surroundings (as a sort of 360 degrees image), and stores versions
 of it with increasing levels of *blur*. This is used to simulate roughness in materials, as well as ambient lighting.
 
-While these probes are a very efficient way of storing reflections, they have a few shortcomings:
+While these probes are a efficient way of storing reflections, they have a few shortcomings:
 
 * They are efficient to render, but expensive to compute. This leads to a default behavior where they only capture on scene load.
 * They work best for rectangular shaped rooms or places, otherwise the reflections shown are not as faithful (especially when roughness is 0).
@@ -20,7 +20,7 @@ While these probes are a very efficient way of storing reflections, they have a
 Setting Up
 ----------
 
-Setting up reflection probes is really easy! Just create a ReflectionProbe node, and wrap it around the area where you want to have reflections:
+Create a ReflectionProbe node, and wrap it around the area where you want to have reflections:
 
 .. image:: img/refprobe_setup.png
 
@@ -43,7 +43,7 @@ can be displaced to an empty place by moving the handles in the center:
 .. image:: img/refprobe_center_gizmo.png
 
 By default, shadow mapping is disabled when rendering probes (only in the rendered image inside the probe, not the actual scene). This is
-a simple way to save on performance and memory. If you really want shadows in the probe, they can be toggled on/off with the *Enable Shadow* setting:
+a simple way to save on performance and memory. If you want shadows in the probe, they can be toggled on/off with the *Enable Shadow* setting:
 
 .. image:: img/refprobe_shadows.png
 
@@ -76,7 +76,7 @@ As you can see, this blending is never perfect (after all, these are box reflect
 are only visible when using perfectly mirrored reflections. Normally, scenes have normal mapping and varying levels of roughness which
 can hide this. 
 
-Alternatively, Reflection Probes work very well blended together with Screen Space Reflections to solve these problems. Combining them makes local reflections appear
+Alternatively, Reflection Probes work well blended together with Screen Space Reflections to solve these problems. Combining them makes local reflections appear
 more faithful, while probes only used as fallback when no screen-space information is found:
 
 .. image:: img/refprobe_ssr.png

tutorials/3d/spatial_material.rst

@@ -60,7 +60,7 @@ by running the lighting shader on every pixel.
 As these calculations are costly, performance can be brought down considerably in some corner cases such as drawing
 several layers of transparency (common in particle systems). Switching to per vertex lighting may help these cases.
 
-Additionally, on very low end devices such as mobile, switching to vertex lighting can considerably increase rendering performance.
+Additionally, on low end or mobile devices, switching to vertex lighting can considerably increase rendering performance.
 
 
 .. image:: img/spatial_material2.png
@@ -131,7 +131,7 @@ default one is Burley. Other modes are also available:
 * **Burley:** Default mode, the original Disney Principled PBS diffuse algorithm.
 * **Lambert:** Is not affected by roughness.
 * **Lambert Wrap:** Extends Lambert to cover more than 90 degrees when roughness increases. Works great for hair and simulating cheap subsurface scattering. This implementation is energy conserving.
-* **Oren Nayar:** This implementation aims to take microsurfacing into account (via roughness). Works really well for clay-like materials and some types of cloth.
+* **Oren Nayar:** This implementation aims to take microsurfacing into account (via roughness). Works well for clay-like materials and some types of cloth.
 * **Toon:** Provides a hard cut for lighting, with smoothing affected by roughness.
 
 .. image:: img/spatial_material6.png
@@ -233,8 +233,8 @@ This renders the object via the opaque pipeline, which is faster and allows it t
 Material colors, maps and channels
 ----------------------------------
 
-Besides the parameters, what defines materials themselves are the colors, textures and channels. Godot supports a very extensive list
-of them (arguably far more than any of the other prominent game engines). They will be described in detail below:
+Besides the parameters, what defines materials themselves are the colors, textures and channels. Godot supports a extensive list
+of them. They will be described in detail below:
 
 Albedo
 ~~~~~~
@@ -300,7 +300,7 @@ then the albedo of the material is used. Using intermediate values generally wor
 Clearcoat
 ~~~~~~~~~
 
-The *clearcoat* parameter is used mostly to add a *secondary* pass of transparent coat to the material. This is very common in car paint and toys.
+The *clearcoat* parameter is used mostly to add a *secondary* pass of transparent coat to the material. This is common in car paint and toys.
 In practice, it's a smaller specular blob added on top of the existing material.
 
 Anisotropy
@@ -331,7 +331,7 @@ It may not work for complex objets, but it produces a realistic depth effect for
 Subsurface Scattering
 ~~~~~~~~~~~~~~~~~~~~~
 
-This effect emulates light that goes beneath an object's surface, is scattered, and then comes out. It's very useful to make realistic skin, marble, colored liquids, etc.
+This effect emulates light that goes beneath an object's surface, is scattered, and then comes out. It's useful to make realistic skin, marble, colored liquids, etc.
 
 .. image:: img/spatial_material21.png
 
@@ -339,7 +339,7 @@ This effect emulates light that goes beneath an object's surface, is scattered,
 Transmission
 ~~~~~~~~~~~~
 
-Controls how much light from the lit side (visible to light) is transferred to the dark side (opposite side to light). This works very well for thin objects such as tree/plant leaves,
+Controls how much light from the lit side (visible to light) is transferred to the dark side (opposite side to light). This works well for thin objects such as tree/plant leaves,
 grass, human ears, etc.
 
 .. image:: img/spatial_material22.png
@@ -348,7 +348,7 @@ Refraction
 ~~~~~~~~~~~
 
 When refraction is enabled, it supersedes alpha blending and Godot attempts to fetch information from behind the object being rendered instead. This allows distorting the transparency
-in a way very similar to refraction.
+in a way similar to refraction.
 
 .. image:: img/spatial_material23.png
 
@@ -378,7 +378,7 @@ Proximity and Distance Fade
 ----------------------------
 
 Godot allows materials to fade by proximity to another, as well as depending on the distance to the viewer.
-Proximity fade is very useful for effects such as soft particles, or a mass of water with a smooth blending to the shores.
+Proximity fade is useful for effects such as soft particles, or a mass of water with a smooth blending to the shores.
 Distance fade is useful for light shafts or indicators that are only present after a given distance.
 
 Keep in mind enabling these enables alpha blending, so abusing them for a whole scene is not generally a good idea.

tutorials/3d/using_transforms.rst

@@ -6,10 +6,10 @@ Using 3D transforms in Godot
 Introduction
 ------------
 
-If you have never made 3D games before, working with rotations in three dimensions can be very confusing at first.
+If you have never made 3D games before, working with rotations in three dimensions can be confusing at first.
 Coming from 2D, the natural way of thinking is along the lines of *"Oh, it's just like rotating in 2D, except now rotations happen in X, Y and Z"*.
 
-At first this seems easy and for simple games, this way of thinking may even be enough. Unfortunately, it's very often incorrect.
+At first this seems easy and for simple games, this way of thinking may even be enough. Unfortunately, it's often incorrect.
 
 Angles in three dimensions are most commonly referred to as "Euler Angles".
 
@@ -27,7 +27,7 @@ The idea of this document is to explain why, as well as outlining best practices
 Problems of Euler Angles
 ------------------------
 
-While it may seem very intuitive that each axis has a rotation, the truth is that it's just not practical.
+While it may seem intuitive that each axis has a rotation, the truth is that it's just not practical.
 
 Axis Order
 ==========
@@ -36,7 +36,7 @@ The main reason for this is that there isn't a *unique* way to construct an orie
 takes all the angles together and produces an actual 3D rotation. The only way an orientation can be produced from angles is to rotate the object angle
 by angle, in an *arbitrary order*.
 
-This could be done by first rotating in *X*, then *Y* and then in *Z*. Alternatively, you could first rotate in *Y*, then in *Z* and finally in *X*. Anything really works,
+This could be done by first rotating in *X*, then *Y* and then in *Z*. Alternatively, you could first rotate in *Y*, then in *Z* and finally in *X*. Anything works,
 but depending on the order, the final orientation of the object will *not necessarily be the same*. Indeed, this means that there are several ways to construct an orientation
 from 3 different angles, depending on *the order of the rotations*.
 
@@ -80,7 +80,7 @@ There are a few reasons this may happen:
 Say no to Euler Angles
 ======================
 
-The result of all this is that you should **not use** the ``rotation`` property of :ref:`class_Spatial` nodes in Godot for games. It's there to be used mainly in the editor, for coherence with the 2D engine, and for very simple rotations (generally just one axis, or even two in limited cases). As much as you may be tempted, don't use it.
+The result of all this is that you should **not use** the ``rotation`` property of :ref:`class_Spatial` nodes in Godot for games. It's there to be used mainly in the editor, for coherence with the 2D engine, and for simple rotations (generally just one axis, or even two in limited cases). As much as you may be tempted, don't use it.
 
 Instead, there is a better way to solve your rotation problems.
 
@@ -385,7 +385,7 @@ Converting a rotation to quaternion is straightforward.
 
 The :ref:`class_Quat` type reference has more information on the datatype (it can also do transform accumulation, transform points, etc. though this is used less often). If you interpolate or apply operations to quaternions many times, keep in mind they need to be eventually normalized or they also may suffer from numerical precision errors.
 
-Quaternions are very useful when doing camera/path/etc. interpolations, as the result will be always correct and smooth.
+Quaternions are useful when doing camera/path/etc. interpolations, as the result will be always correct and smooth.
 
 Transforms are your friend
 --------------------------

tutorials/3d/working_with_3d_skeletons.rst

@@ -20,7 +20,6 @@ structures called "bones". Each "bone" is represented as a Transform, which is
 applied to a group of vertices within a mesh. You can directly control a group
 of vertices from Godot. For that please reference the :ref:`class_MeshDataTool`
 class and its method :ref:`set_vertex_bones <class_MeshDataTool_set_vertex_bones>`.
-This class is very powerful.
 
 The "bones" are organized hierarchically, every bone, except for root
 bone(s) have a parent. Every bone has an associated name you can use to

tutorials/animation/cutout_animation.rst

@@ -20,7 +20,7 @@ Land
 Pirates <http://en.wikipedia.org/wiki/Jake_and_the_Never_Land_Pirates>`__
 .
 
-In video games, this technique also become very popular. Examples of
+In video games, this technique has also become popular. Examples of
 this are `Paper
 Mario <http://en.wikipedia.org/wiki/Super_Paper_Mario>`__ or `Rayman
 Origins <http://en.wikipedia.org/wiki/Rayman_Origins>`__ .
@@ -37,7 +37,7 @@ unlike other tools meant for this, Godot has the following advantages:
    such as textures, sprite sizes, pivots, opacity, color modulation,
    etc. Everything can be animated and blended.
 -  **Mix with Traditional**: AnimatedSprite allows traditional animation
-   to be mixed, very useful for complex objects, such as shape of hands
+   to be mixed, useful for complex objects, such as shape of hands
    and foot, changing facial expression, etc.
 -  **Custom Shaped Elements**: Can be created with
    :ref:`Polygon2D <class_Polygon2D>`
@@ -82,7 +82,7 @@ create a child sprite and load the torso, later accommodate it properly:
 
 This looks good. Let's see if our hierarchy works as a skeleton by
 rotating the torso. We can do this be pressing ``E`` to enter rotate mode, 
-and dragging with the left mouse button. To exit rotate mode just hit ``ESC``.
+and dragging with the left mouse button. To exit rotate mode hit ``ESC``.
 
 .. image:: img/tutovec_torso1.gif
 
@@ -121,11 +121,7 @@ simple! Or maybe not:
 
 .. image:: img/tuto_cutout7.png
 
-Right. Remember your tutorials, Luke. In 2D, parent nodes appear below
-children nodes. Well, this sucks. It seems Godot does not support cutout
-rigs after all. Come back next year, maybe for 3.0.. no wait. Just
-Kidding! It works just fine.
-
+Right. In 2D, parent nodes appear below children nodes. Well, this sucks. 
 But how can this problem be solved? We want the left arm to appear behind
 the hip and the torso. For this, we can move the nodes behind the hip
 (note that you can bypass this by setting the Node2D Z property, but then you
@@ -346,7 +342,7 @@ This makes the task of animating extremities much simpler.
 Moving sprites above and behind others.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-RemoteTransform2D works in most cases, but sometimes it is really
+RemoteTransform2D works in most cases, but sometimes it is
 necessary to have a node above and below others during an animation. To
 aid on this the "Behind Parent" property exists on any Node2D:
 
@@ -355,7 +351,7 @@ aid on this the "Behind Parent" property exists on any Node2D:
 Batch setting transition curves
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-When creating really complex animations and inserting lots of keyframes,
+When creating complex animations and inserting many keyframes,
 editing the individual keyframe curves for each can become an endless
 task. For this, the Animation Editor has a small menu where changing
 animation curves is easy. First select the appropriate keys. Next click on the 

tutorials/animation/introduction_2d.rst

@@ -161,7 +161,7 @@ As we don't have a track already set up for the transform/location
 property, Godot asks, whether it should set it up for us. Click on
 "Create".
 
-This creates a new track and our very first keyframe at the beginning of
+This creates a new track and our first keyframe at the beginning of
 the timeline:
 
 .. figure:: img/animation_track.png

tutorials/audio/audio_buses.rst

@@ -18,7 +18,7 @@ entirely from the ground up, without relying on any existing audio libraries.
 
 Even the effect processors were written exclusively for Godot (save for
 the pitch shifting library), with games in mind. This allows
-a very efficient tradeoff between performance and sound quality.
+a efficient tradeoff between performance and sound quality.
 
 Decibel Scale
 -------------
@@ -109,19 +109,19 @@ There is a lot of bibliography written about compressors, and Godot implementati
 Delay
 ~~~~~
 
-Adds an "Echo" effect with a feedback loop. It can be used, together with Reverb, to simulate very wide rooms, canyons, etc. where sound bounces are far apart.
+Adds an "Echo" effect with a feedback loop. It can be used, together with Reverb, to simulate wide rooms, canyons, etc. where sound bounces are far apart.
 
 Distortion
 ~~~~~~~~~~
 
 Adds classical effects to modify the sound and make it dirty. Godot supports effects like overdrive, tan, or bit crushing.
-For games, it can simulate sound coming from some saturated device or speaker very efficiently.
+For games, it can simulate sound coming from some saturated device or speaker efficiently.
 
 EQ6, EQ10, EQ21
 ~~~~~~~~~~~~~~~
 
-Godot provides three model of equalizers with different band counts. Equalizers are very useful on the Master Bus to completely master a mix and give it character. They are
-also very useful when a game is run on a mobile device, to adjust the mix to that kind of speakers (it can be added but disabled when headphones are plugged).
+Godot provides three model of equalizers with different band counts. Equalizers are useful on the Master Bus to completely master a mix and give it character. They are
+also useful when a game is run on a mobile device, to adjust the mix to that kind of speakers (it can be added but disabled when headphones are plugged).
 
 HighPassFilter, HighShelfFilter
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

tutorials/audio/audio_streams.rst

@@ -21,7 +21,7 @@ inside an AudioStreamPlayer.
 
 When using these kind of files, you should choose which one is best for your specific use case:
 
-* Audio files of type *.wav* are considerably big, but use very little amount of your CPU to play. Hundreds of them can be played simultaneously with little impact to performance. This format is usually best for short sound effects, as the importer will trim them and convert them to IMA-ADPCM.
+* Audio files of type *.wav* are considerably big, but use little amount of your CPU to play. Hundreds of them can be played simultaneously with little impact to performance. This format is usually best for short sound effects, as the importer will trim them and convert them to IMA-ADPCM.
 * Audio files of type *.ogg* are much smaller, but use considerably more amount of CPU power to play back, so only a few can be played back (especially on mobile!). This format is usually best for music or long sound effect sequences. It also works well for voice at relatively low bitrates.
 
 Keep in mind both .wav and .ogg generally don't contain looping information, so this information must be set on the import options of each:
@@ -61,7 +61,7 @@ Unlike for 2D, the 3D version of AudioStreamPlayer has a few more advanced optio
 Reverb Buses
 ~~~~~~~~~~~~
 
-Godot allows 3D Audio Streams that enter a specific *Area* to send dry and wet audio to separate buses. This is really useful when you have several reverb configurations for different types of rooms.
+Godot allows 3D Audio Streams that enter a specific *Area* to send dry and wet audio to separate buses. This is useful when you have several reverb configurations for different types of rooms.
 This is done by enabling this type of reverb in the *Reverb Bus* section of *Area* properties:
 
 .. image:: img/audio_stream_reverb_bus.png

tutorials/gui/custom_gui_controls.rst

@@ -23,7 +23,7 @@ usefulness when drawing, so they will be detailed next:
 Checking control size
 ~~~~~~~~~~~~~~~~~~~~~
 
-Unlike 2D nodes, "size" is very important with controls, as it helps to
+Unlike 2D nodes, "size" is important with controls, as it helps to
 organize them in proper layouts. For this, the
 :ref:`Control.rect_size <class_Control_rect_size>`
 member variable is provided. Checking it during _draw() is vital to ensure
@@ -68,7 +68,7 @@ exists. Example
 Sizing
 ------
 
-As mentioned before, size is very important to controls. This allows
+As mentioned before, size is important to controls. This allows
 them to lay out properly, when set into grids, containers, or anchored.
 Controls most of the time provide a *minimum size* to help to properly
 lay them out. For example, if controls are placed vertically on top of

tutorials/i18n/internationalizing_games.rst

@@ -8,7 +8,7 @@ Introduction
 
 Sería excelente que el mundo hablara solo un idioma. Unfortunately for
 us developers, that is not the case. While not generally a big
-requirement when developing indie or niche games, it is also very common
+requirement when developing indie or niche games, it is also common
 that games going into a more massive market require localization.
 
 Godot offers many tools to make this process more straightforward, so
@@ -71,7 +71,7 @@ Making controls resizable
 The same text in different languages can vary greatly in length. For
 this, make sure to read the tutorial on :ref:`doc_size_and_anchors`, as having
 dynamically adjusted control sizes may help.
-:ref:`Container <class_Container>` can be very useful, as well as the multiple options in
+:ref:`Container <class_Container>` can be useful, as well as the multiple options in
 :ref:`Label <class_Label>` for text wrapping.
 
 TranslationServer

tutorials/io/background_loading.rst

@@ -132,7 +132,7 @@ error. Also note we skip one frame (via ``wait_frames``, set on the
 ``goto_scene`` function) to allow the loading screen to show up.
 
 Note how we use ``OS.get_ticks_msec`` to control how long we block the
-thread. Some stages might load really fast, which means we might be able
+thread. Some stages might load fast, which means we might be able
 to cram more than one call to ``poll`` in one frame, some might take way
 more than your value for ``time_max``, so keep in mind we won't have
 precise control over the timings.

tutorials/io/data_paths.rst

@@ -26,7 +26,7 @@ folder may be opened from the following path: ``res://sometexture.png``.
 Userdata path (persistent data)
 -------------------------------
 
-While the project is running, it is a very common scenario that the
+While the project is running, it is a common scenario that the
 resource path will be read-only, due to it being inside a package,
 self contained executable, or system wide install location.
 

tutorials/io/encrypting_save_games.rst

@@ -6,35 +6,10 @@ Encrypting save games
 Why?
 ----
 
-Because the world today is not the world of yesterday. A capitalist
-oligarchy runs the world and forces us to consume in order to keep the
-gears of this rotten society on track. As such, the biggest market for
-video game consumption today is the mobile one. It is a market of poor
-souls forced to compulsively consume digital content in order to forget
-the misery of their every day life, commute, or just any other brief
-free moment they have that they are not using to produce goods or
-services for the ruling class. These individuals need to keep focusing
-on their video games (because not doing so will produce them a
-tremendous existential angst), so they go as far as spending money on
-them to extend their experience, and their preferred way of doing so is
-through in-app purchases and virtual currency.
-
-But, imagine if someone was to find a way to edit the saved games and
-assign the items and currency without effort? This would be terrible,
-because it would help players consume the content much faster, and as
-such run out of it sooner than expected. If this happens they will have
-nothing that avoids them to think, and the tremendous agony of realizing
-their own irrelevance would again take over their life.
-
-No, we definitely do not want this to happen, so let's see how to
-encrypt savegames and protect the world order.
-
-How?
-----
-
-The class :ref:`File <class_File>` is simple to use, just open a
-location and read/write data (integers, strings and variants). To create
-an encrypted file, a passphrase must be provided, like this:
+The class :ref:`File <class_File>` can open a file at a
+location and read/write data (integers, strings and variants). 
+It also supports encryption.
+To create an encrypted file, a passphrase must be provided, like this:
 
 .. tabs::
  .. code-tab:: gdscript GDScript
@@ -51,9 +26,9 @@ an encrypted file, a passphrase must be provided, like this:
     f.StoreVar(gameState);
     f.Close();
 
-This will make the file unreadable to users, but will still not avoid
-them to share savefiles. To solve this, using the device unique id or
-some unique user identifier is needed, for example:
+This will make the file unreadable to users, but will still not prevent
+them sharing save files. To solve this, use the device unique id or
+some unique user identifier, for example:
 
 .. tabs::
  .. code-tab:: gdscript GDScript

tutorials/io/saving_games.rst

@@ -247,7 +247,7 @@ Some notes
 ----------
 
 We may have glossed over a step, but setting the game state to one fit
-to start loading data can be very complicated. This step will need to be
+to start loading data can be complicated. This step will need to be
 heavily customized based on the needs of an individual project.
 
 This implementation assumes no Persist objects are children of other

tutorials/math/matrices_and_transforms.rst

@@ -25,7 +25,7 @@ just move the ship somewhere and rotate it:
 
 Ok, so in 2D this looks simple, a position and an angle for a rotation.
 But remember, we are grown ups here and don't use angles (plus, angles
-are not really even that useful when working in 3D).
+are not even that useful when working in 3D).
 
 We should realize that at some point, someone *designed* this
 spaceship. Be it for 2D in a drawing such as Paint.net, Gimp,
@@ -240,7 +240,7 @@ Rotating Transform2D is done by using the "rotated" function:
 Translation
 -----------
 
-There are two ways to translate a Transform2D, the first one is just moving
+There are two ways to translate a Transform2D, the first one is moving
 the origin:
 
 .. tabs::

tutorials/math/rotations.rst

@@ -3,7 +3,7 @@
 Rotations
 =========
 
-In the context of 3D transforms, rotations are the nontrivial and complicated part. While it is possible to describe 3D rotations using geometrical drawings and derive the rotation matrices, which is what most people would be more familiar with, it offers a very limited picture, and fails to give any insight on related practical things such quaternions and SLERP. For this reason, this document takes a different approach, a very general (although a little abstract at first) approach which was popularized by its extensive use in local gauge theories in physics.
+In the context of 3D transforms, rotations are the nontrivial and complicated part. While it is possible to describe 3D rotations using geometrical drawings and derive the rotation matrices, which is what most people would be more familiar with, it offers a limited picture, and fails to give any insight on related practical things such quaternions and SLERP. For this reason, this document takes a different approach, a general (although a little abstract at first) approach which was popularized by its extensive use in local gauge theories in physics.
 That being said, the aim of this text is to provide a minimal background to understand 2D and 3D rotations in a general way and shed light on practical things such as gimbal lock, quaternions and SLERP using an accessible language for programmers, and not completeness or mathematical rigor.
 
 
@@ -11,13 +11,13 @@ That being said, the aim of this text is to provide a minimal background to unde
 A crash course in Lie groups and algebras for programmers
 ---------------------------------------------------------
 
-Lie groups is a branch of mathematics which deals with rotations in a systematic way. While it is a very extensive subject and most programmers haven't even heard of it, it is very relevant in game development, because it provides a coherent and unified view of 3D rotations.
+Lie groups is a branch of mathematics which deals with rotations in a systematic way. While it is a extensive subject and most programmers haven't even heard of it, it is relevant in game development, because it provides a coherent and unified view of 3D rotations.
 
 .. image:: img/small-rotation.svg
 	:width: 400px
 	:align: center
 
-So let's start with small steps. Suppose that you want to make a really tiny rotation around some axis. For, concreteness let's say around  :math:`z`-axis by an infinitesimal angle :math:`\delta\theta`. For small angles, as illustrated in the figure, the rotation operator can be written as :math:`R_z(\delta\theta) = I + \delta \theta \boldsymbol e_z \times` (neglecting higher order terms :math:`\mathcal O(\delta\theta^2)` ) where :math:`I` is identity operator and :math:`\boldsymbol e_z` is a unit vector along the :math:`z`-axis, such that a vector :math:`\boldsymbol v` becomes
+So let's start with small steps. Suppose that you want to make a tiny rotation around some axis. For, concreteness let's say around  :math:`z`-axis by an infinitesimal angle :math:`\delta\theta`. For small angles, as illustrated in the figure, the rotation operator can be written as :math:`R_z(\delta\theta) = I + \delta \theta \boldsymbol e_z \times` (neglecting higher order terms :math:`\mathcal O(\delta\theta^2)` ) where :math:`I` is identity operator and :math:`\boldsymbol e_z` is a unit vector along the :math:`z`-axis, such that a vector :math:`\boldsymbol v` becomes
 
 .. math::
 
@@ -50,7 +50,7 @@ So, how about finite rotations? We simply can apply this infinitesimal rotation
 
 	R_z(\theta) = \lim_{N \to \infty} R_z^N(\delta\theta) = \left( I + \frac{\theta}{N} J_z \right)^N = e^{\theta J_z}.
 
-(If you're confused about seeing a matrix as an exponent: the meaning of an operator :math:`A` in `exponential map <https://en.wikipedia.org/wiki/Exponential_map_(Lie_theory)>`_ is given by its series expansion as :math:`e^A = 1 + A + A^2/2! + \ldots` ). This is arguably the most important relation in this write up, and lies at the heart of Lie groups, whose significance will be clarified in a moment. But first, let's take step back and observe the significance of this result: using a very simple picture of an infinitesimal rotation, we derived a general expression for arbitrary rotations around the :math:`z`-axis. In fact, this gets even better. If we repeated the same analysis for rotations around :math:`x`- and :math:`y`-axes, we would have obtained similar results :math:`e^{\theta J_x}` and :math:`e^{\theta J_y}` respectively, where
+(If you're confused about seeing a matrix as an exponent: the meaning of an operator :math:`A` in `exponential map <https://en.wikipedia.org/wiki/Exponential_map_(Lie_theory)>`_ is given by its series expansion as :math:`e^A = 1 + A + A^2/2! + \ldots` ). This is arguably the most important relation in this write up, and lies at the heart of Lie groups, whose significance will be clarified in a moment. But first, let's take step back and observe the significance of this result: using a simple picture of an infinitesimal rotation, we derived a general expression for arbitrary rotations around the :math:`z`-axis. In fact, this gets even better. If we repeated the same analysis for rotations around :math:`x`- and :math:`y`-axes, we would have obtained similar results :math:`e^{\theta J_x}` and :math:`e^{\theta J_y}` respectively, where
 
 .. math::
 
@@ -195,7 +195,7 @@ Let's first review how 3D rotations work using familiar vectors and matrices.
 In 2D, we considered vectors lying in the :math:`xy` plane, and the only axis we could can rotate them was the :math:`z`-axis. In 3D, we can perform a rotation around any axis. And this doesn't just mean around :math:`x, y, z` axes, the rotation can also be around an axis which is a linear combination of those, where :math:`\boldsymbol n` is the unit vector (meaning :math:`\boldsymbol n \cdot \boldsymbol n = 1` ) aligned with the axis we want to perform the rotation.
 
 
-Just like the 2D rotation matrix, the 3D rotation matrix can also be derived with some effort by drawing lots of arrows and angles and some linear algebra, but this would be very opaque and won't give us much insight to what's really going on. A less straightforward, but more rewarding way of deriving this matrix is to understand the rotation group SO(3).
+Just like the 2D rotation matrix, the 3D rotation matrix can also be derived with some effort by drawing lots of arrows and angles and some linear algebra, but this would be opaque and won't give us much insight to what's going on. A less straightforward, but more rewarding way of deriving this matrix is to understand the rotation group SO(3).
 
 SO(3) is the group of rotations in Euclidean 3D space (for which the `signature <https://en.wikipedia.org/wiki/Metric_signature>`_ is :math:`(+1,+1,+1)`), which preserve the magnitude and handedness of the vectors it acts on. The most typical way to represent its elements is to use :math:`3 \times 3` real orthogonal matrices with determinant :math:`+1`. This :math:`\text{Mat}(3, \mathbb R)` representation is called the fundamental representation of SO(3).
 
@@ -241,7 +241,7 @@ If you want, you can plug-in the matrix representations for :math:`J_i` and deri
 
 (Hint: you can use the relation :math:`(\boldsymbol n \cdot \boldsymbol J)^2 = \boldsymbol n \otimes \boldsymbol n-I` to quickly evaluate the last term in the Rodrigues' formula, where :math:`\otimes` is the `Kronecker product <https://en.wikipedia.org/wiki/Kronecker_product>`_ which is also called `outer product <https://en.wikipedia.org/wiki/Outer_product>`_ for vectors. Using the `half-angle formulae <https://en.wikipedia.org/wiki/List_of_trigonometric_identities#Half-angle_formulae>`_ to rewrite :math:`\sin\varphi = 2 \cos\frac{\varphi}{2} \sin\frac{\varphi}{2}`  and :math:`1-\cos\varphi = 2 \sin^2\frac{\varphi}{2}` in Rodrigues' formula, you can use cosine and sine terms as a visual aid when comparing to the matrix form.)
 
-However, we don't really *have to* use matrices to represent SO(3) generators :math:`J_i`. Remember how we used :math:`\imath`, the imaginary unit to emulate :math:`J_z` rather than using a :math:`2 \times 2` matrix? As it turns out we can do something similar here.
+However, we don't *have to* use matrices to represent SO(3) generators :math:`J_i`. Remember how we used :math:`\imath`, the imaginary unit to emulate :math:`J_z` rather than using a :math:`2 \times 2` matrix? As it turns out we can do something similar here.
 
 `Hamilton <https://en.wikipedia.org/wiki/William_Rowan_Hamilton>`_ is mostly commonly known for the omnipresent `Hamiltonian <https://en.wikipedia.org/wiki/Hamiltonian_mechanics>`_ in physics. One of his less known contributions is essentially an alternative way of representing 3D cross product, which eventually gave in to popularity of usual vector `cross products <https://en.wikipedia.org/wiki/Cross_product#History>`_. He essentially realized that there are three different non-commuting rotations in 3D, and gave a name to the generator for each. He identified the operators :math:`\{\boldsymbol e_x \times, \boldsymbol e_y \times, \boldsymbol e_z \times\}` as the elements of an algebra, naming them as :math:`\{i,j,k\}`.
 
@@ -281,7 +281,7 @@ So, the take aways of this section are:
 
 3. Using matrices, you can practically do everything you do with quaternions, vice versa. The real differences, as highlighted, are in computation trade-offs, not mathematics.
 
-3. The relationship between quaternions and 3D rotation matrices is the roughly the same as the relation between the complex number :math:`e^{\imath\theta}` and a 2D rotation matrix. Just as the complex number :math:`\imath \cong J_z` rotates by :math:`\pi/2` (which is, as we saw, what a *generator* does), :math:`i,j,k` (which are :math:`\cong J_x, J_y, J_z`) rotate by :math:`\pi/2` around :math:`x, y, z` axes; they don't commute with each other because in 3D, the order of rotations is important. Owing to this isomorphism between their generators, an SO(3) rotation :math:`e^{\varphi \boldsymbol n \cdot \boldsymbol J}` corresponds to the SU(2) rotation :math:`e^{\varphi \boldsymbol n \cdot (i,j,k)/2}`. This is a very helpful picture to gain an intuition on quaternions. While the SO(3) is familiar to many people,  the "Rodrigues' formula" for the SU(2) one is much preferable graphics programming due to it's simplicity, and hence you see quaternions in game engines.
+3. The relationship between quaternions and 3D rotation matrices is the roughly the same as the relation between the complex number :math:`e^{\imath\theta}` and a 2D rotation matrix. Just as the complex number :math:`\imath \cong J_z` rotates by :math:`\pi/2` (which is, as we saw, what a *generator* does), :math:`i,j,k` (which are :math:`\cong J_x, J_y, J_z`) rotate by :math:`\pi/2` around :math:`x, y, z` axes; they don't commute with each other because in 3D, the order of rotations is important. Owing to this isomorphism between their generators, an SO(3) rotation :math:`e^{\varphi \boldsymbol n \cdot \boldsymbol J}` corresponds to the SU(2) rotation :math:`e^{\varphi \boldsymbol n \cdot (i,j,k)/2}`. This is a helpful picture to gain an intuition on quaternions. While the SO(3) is familiar to many people,  the "Rodrigues' formula" for the SU(2) one is much preferable graphics programming due to it's simplicity, and hence you see quaternions in game engines.
 
 4. This doesn't mean quaternions are a generalization of complex numbers in our construction when considering rotations in a strict sense; they're rather the 3D generalization of the 2D rotation generator in some loose sense (loose, because SO(3) and SU(2) are different groups). There *is* a construction which generalizes real numbers to complex numbers to quaternions, called `Cayley-Dickson construction <https://en.wikipedia.org/wiki/Cayley%E2%80%93Dickson_construction>`_, but it's next steps give off topic objects octonions and sedenions (setting exceptional Lie groups aside for octonions).
 
@@ -337,7 +337,7 @@ For (embedded) 2D rotations in the :math:`xy`-plane, the rotation axis is taken
 In 3D, the rotation axis can be pointing toward any direction (since the axis is a unit vector, you can think of it as a point on the unit sphere, if you like).
 This way of parametrizing rotations is called axis-angle parametrization, and is the easiest to picture intuitively.
 
-Another advantage of the axis angle parametrization is, it is very easy to interpolate between two different rotations (let's call their parameters :math:`\boldsymbol n_1, \varphi_1` and :math:`\boldsymbol n_2, \varphi_2`), which is useful when you're changing the orientation of an object, starting from a given initial orientation and going toward a final one. A nice way of doing this is described in a later section where we describe SLERP. It results in a smooth motion, rather than a "jerky" motion which may start fast, go slow in the middle and go fast again etc. It turns out that if a mass is transported this way, it experiences the least amount of torque (compared to other possible trajectories). This way of linearly interpolating rotations in the axis-angle parametrization is called Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in games.
+Another advantage of the axis angle parametrization is, it is easy to interpolate between two different rotations (let's call their parameters :math:`\boldsymbol n_1, \varphi_1` and :math:`\boldsymbol n_2, \varphi_2`), which is useful when you're changing the orientation of an object, starting from a given initial orientation and going toward a final one. A nice way of doing this is described in a later section where we describe SLERP. It results in a smooth motion, rather than a "jerky" motion which may start fast, go slow in the middle and go fast again etc. It turns out that if a mass is transported this way, it experiences the least amount of torque (compared to other possible trajectories). This way of linearly interpolating rotations in the axis-angle parametrization is called Spherical Linear Interpolation or SLERP, and is almost ubiquitously used in games.
 
 
 
@@ -360,7 +360,7 @@ Thus, while it's OK to use Euler angles to represent a fixed rotation, they're n
 
 All in all, despite being an ill-defined parametrization for rotations, Euler angles enjoyed a popularity due to gimbals.
 
-While Euler angles may not be too useful when calculating the rotation operator (be it a matrix or a quaternion) in body dynamics, people still find them useful to think about and describe the *orientation* of 3D objects starting from the initial default *"unrotated"* state (it's very difficult to calculate the 3 Euler angles for driving an object from a non-trivial initial orientation to a non-trivial final orientation ---it can't be calculated intuitively in general, it is a task for computers). For this reason, Godot's property editor uses Euler angles (in extrinsic YXZ convention; if the node has a parent node, the YXZ axes refer to the local axes of the parent) for the rotation property of a Transform --this is pretty much the only place Euler angles are used in Godot.
+While Euler angles may not be too useful when calculating the rotation operator (be it a matrix or a quaternion) in body dynamics, people still find them useful to think about and describe the *orientation* of 3D objects starting from the initial default *"unrotated"* state (it's difficult to calculate the 3 Euler angles for driving an object from a non-trivial initial orientation to a non-trivial final orientation ---it can't be calculated intuitively in general, it is a task for computers). For this reason, Godot's property editor uses Euler angles (in extrinsic YXZ convention; if the node has a parent node, the YXZ axes refer to the local axes of the parent) for the rotation property of a Transform --this is pretty much the only place Euler angles are used in Godot.
 
 So the answer to the question "should I use Euler angles or axis-angle parametrization in my game" is: unless you're trying to *statically* orient an object in a particular way starting from an *unrotated, default orientation* (for which you can still use axis-angle parametrization in your script, if you prefer), you shouldn't be using Euler angles. Major reasons are:
 
@@ -444,7 +444,7 @@ Formally, we'd like to interpolate between an initial rotation :math:`R_1 = e^{\
 This form makes sense because for :math:`\lambda=0`, the interpolation hasn't started and :math:`R(\lambda)` automatically becomes :math:`R_1`. But why not pick a different form for the exponent as a function of :math:`\lambda` which evaluates to 0 when :math:`\lambda=0`? That's simply because we don't want to have a jerky motion, meaning :math:`\boldsymbol \omega \cdot \boldsymbol J =  R^T(\lambda) \dot R(\lambda)`, where :math:`\boldsymbol \omega` is the angular velocity vector, has to be a constant, which can only happen if the time derivative of the exponent is linear in time (in which case we obtain :math:`\boldsymbol \omega = \varphi \boldsymbol n`). Or equivalently, you can simply observe that a rotation around a fixed axis (fixed because otherwise if you tilt the rotation axis in time, you'll again get a "jerky motion" due to `Euler force <https://en.wikipedia.org/wiki/Euler_force>`_) with constant angular speed is :math:`e^{\boldsymbol \omega t \cdot \boldsymbol J }` where the exponent is linear in time.
 
 
-But how do we choose :math:`\boldsymbol n` and :math:`\varphi`? Well, we simply enforce that :math:`R(\lambda)`  has to becomes :math:`R_2` at the end, when :math:`\lambda=1`. Although this looks like a very difficult problem, it's actually not. We first make a rearrangement:
+But how do we choose :math:`\boldsymbol n` and :math:`\varphi`? Well, we simply enforce that :math:`R(\lambda)`  has to becomes :math:`R_2` at the end, when :math:`\lambda=1`. Although this looks like a difficult problem, it's actually not. We first make a rearrangement:
 
 .. math::
 
@@ -474,7 +474,7 @@ After some tedious algebra (which involves using :math:`\text{tr}(\sigma_i \sigm
 
 	q(\lambda) = \frac{\sin([1-\lambda]\Omega)q_1 + \sin(\Omega \lambda) q_2}{\sin\Omega}
 
-when :math:`q_1 \neq \pm q_2`, where we introduced :math:`\cos\Omega \equiv \cos\frac{\varphi_1}{2}\cos\frac{\varphi_2}{2} + \sin\frac{\varphi_1}{2}\sin\frac{\varphi_2}{2} \boldsymbol n_1 \cdot \boldsymbol n_2` (or equivalently, in terms of an artificial vector which contains the coefficients of the quaternions, as we discussed above, :math:`\boldsymbol q_1 \cdot \boldsymbol q_2`). This result has a very simple geometric interpretation when a (unit) quaternion is taken to be a point on the 3-sphere and when one introduces an inner product of the 4D Euclidean space, but we'll skip that because it's a bit off topic in our treatment. We'll however note that this is where the name *Spherical* Linear intERpolation comes from, which refers to the 4D sphere.
+when :math:`q_1 \neq \pm q_2`, where we introduced :math:`\cos\Omega \equiv \cos\frac{\varphi_1}{2}\cos\frac{\varphi_2}{2} + \sin\frac{\varphi_1}{2}\sin\frac{\varphi_2}{2} \boldsymbol n_1 \cdot \boldsymbol n_2` (or equivalently, in terms of an artificial vector which contains the coefficients of the quaternions, as we discussed above, :math:`\boldsymbol q_1 \cdot \boldsymbol q_2`). This result has a simple geometric interpretation when a (unit) quaternion is taken to be a point on the 3-sphere and when one introduces an inner product of the 4D Euclidean space, but we'll skip that because it's a bit off topic in our treatment. We'll however note that this is where the name *Spherical* Linear intERpolation comes from, which refers to the 4D sphere.
 
 
 
@@ -536,7 +536,7 @@ Note how things fit nicely, for example, when you consider how a rotated vector
 The left hand side is rotation of the vector :math:`(R_0 \boldsymbol v_0)` and the right hand side is the rotation of the vector :math:`v_0` and the matrix :math:`R_0` that acts on it, which of course agree.
 
 
-The rotation operator itself rotates in a very expected way (you can use Rodrigues' formula along with the equation above, if you prefer):
+The rotation operator itself rotates in a expected way (you can use Rodrigues' formula along with the equation above, if you prefer):
 
 .. math::
 

tutorials/math/vector_math.rst

@@ -44,7 +44,7 @@ it as an angle ``θ`` and a length (or magnitude) ``m``. In this case, the
 arrow is a **position vector** - it denotes a position in space, relative
 to the origin.
 
-A very important point to consider about vectors is that they only
+A important point to consider about vectors is that they only
 represent **relative** direction and magnitude. There is no concept of
 a vector's position. The following two vectors are identical:
 

tutorials/math/vectors_advanced.rst

@@ -115,7 +115,7 @@ The same thing, using a built-in function:
 
 This will, again, return either a positive or negative distance.
 
-Flipping the polarity of the plane is also very simple, just negate both
+Flipping the polarity of the plane can be done by negating both
 N and D. This will result in a plane in the same position, but with
 inverted negative and positive half spaces:
 
@@ -267,7 +267,7 @@ similar logic will let us know when two convex polygons are overlapping
 too. This is called the Separating Axis Theorem (or SAT) and most
 physics engines use this to detect collision.
 
-The idea is really simple! With a point, just checking if a plane
+With a point, just checking if a plane
 returns a positive distance is enough to tell if the point is outside.
 With another polygon, we must find a plane where *all* *the* *other*
 *polygon* *points* return a positive distance to it. This check is
@@ -379,8 +379,7 @@ Collision detection in 3D
 This is another bonus bit, a reward for being patient and keeping up
 with this long tutorial. Here is another piece of wisdom. This might
 not be something with a direct use case (Godot already does collision
-detection pretty well) but It's a really cool algorithm to understand
-anyway, because it's used by almost all physics engines and collision
+detection pretty well) but it's used by almost all physics engines and collision
 detection libraries :)
 
 Remember that converting a convex shape in 2D to an array of 2D planes

tutorials/misc/pausing_games.rst

@@ -72,7 +72,7 @@ Example
 -------
 
 An example of this is creating a popup or panel with controls inside,
-and set its pause mode to "Process" then just hide it:
+and set its pause mode to "Process" then hide it:
 
 .. image:: img/pause_popup.png
 
@@ -98,7 +98,7 @@ enable the pause and show the pause screen.
         ((Control)GetNode("pause_popup")).Show();
     }
 
-To remove the pause, just do the opposite when the pause screen is
+To remove the pause, do the opposite when the pause screen is
 closed:
 
 .. tabs::

tutorials/networking/high_level_multiplayer.rst

@@ -305,7 +305,7 @@ Synchronizing game start
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 Setting up players might take different amount of time on every peer due to lag, different hardware, or other reasons.
-To make sure the game will actually start when everyone is ready, pausing the game until all players are ready can be very useful:
+To make sure the game will actually start when everyone is ready, pausing the game until all players are ready can be useful:
 
 ::
 

tutorials/networking/ssl_certificates.rst

@@ -31,7 +31,7 @@ There are two ways to obtain certificates:
 Approach 1: self signed cert
 ----------------------------
 
-The first approach is the simplest, just generate a private and public
+The first approach is the simplest: generate a private and public
 key pair, and put the public pair in the .crt file (again, in PEM
 format). The private key should go to your server.
 
@@ -68,5 +68,5 @@ located in:
 This file allows HTTPS connections to virtually any website (i.e.,
 Google, Microsoft, etc.).
 
-Or just pick any of the more specific certificates there if you are
+Or pick any of the more specific certificates there if you are
 connecting to a specific one.

tutorials/physics/kinematic_character_2d.rst

@@ -20,7 +20,7 @@ Some physics engines such as Havok seem to swear by dynamic character
 controllers as the best alternative, while others (PhysX) would rather
 promote the Kinematic one.
 
-So, what is really the difference?:
+So, what is the difference?:
 
 -  A **dynamic character controller** uses a rigid body with infinite
    inertial tensor. Basically, it's a rigid body that can't rotate.
@@ -111,7 +111,7 @@ Moving the Kinematic character
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Go back to the character scene, and open the script, the magic begins
-now! Kinematic body will do nothing by default, but it has a really
+now! Kinematic body will do nothing by default, but it has a
 useful function called
 :ref:`KinematicBody2D.move_and_collide() <class_KinematicBody2D_move_and_collide>`.
 This function takes a :ref:`Vector2 <class_Vector2>` as

tutorials/physics/physics_introduction.rst

@@ -90,7 +90,7 @@ Collision Layers and Masks
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 One of the most powerful but frequently misunderstood collision features
-is the collision layer system. This system allows you to build up very complex
+is the collision layer system. This system allows you to build up complex
 interactions between a variety of objects. The key concepts are **layers**
 and **masks**. Each ``CollisionObject2D`` has 20 different physics layers
 it can interact with.
@@ -373,11 +373,11 @@ Or to bounce off of the colliding object:
 :ref:`move_and_slide <class_KinematicBody2D_move_and_slide>`
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Sliding is a very common collision response; imagine a player moving along walls
+Sliding is a common collision response; imagine a player moving along walls
 in a top-down game or running up and down slopes in a platformer. While it's
 possible to code this response yourself after using ``move_and_collide()``,
 ``move_and_slide()`` provides a convenient way to implement sliding movement
-without writing very much code.
+without writing much code.
 
 .. warning:: ``move_and_slide()`` automatically includes the timestep in its
              calculation, so you should **not** multiply the velocity vector

tutorials/physics/using_kinematic_body_2d.rst

@@ -126,7 +126,7 @@ the same collision response:
     velocity = MoveAndSlide(velocity);
 
 Anything you do with ``move_and_slide()`` can also be done with ``move_and_collide()``,
-it just might take a little more code. However, as we'll see in the examples below,
+but it might take a little more code. However, as we'll see in the examples below,
 there are cases where ``move_and_slide()`` doesn't provide the response you want.
 
 Examples
@@ -219,13 +219,13 @@ Run this scene and you'll see that ``move_and_collide()`` works as expected, mov
 the body along the velocity vector. Now let's see what happens when you add
 some obstacles. Add a :ref:`StaticBody2D <class_StaticBody2D>` with a
 rectangular collision shape. For visibility, you can use a sprite, a
-Polygon2D, or just turn on "Visible Collision Shapes" from the "Debug" menu.
+Polygon2D, or turn on "Visible Collision Shapes" from the "Debug" menu.
 
 Run the scene again and try moving into the obstacle. You'll see that the ``KinematicBody2D``
 can't penetrate the obstacle. However, try moving into the obstacle at an angle and
 you'll find that the obstacle acts like glue - it feels like the body gets stuck.
 
-This happens because there is no *collision response*. ``move_and_collide()`` just stops
+This happens because there is no *collision response*. ``move_and_collide()`` stops
 the body's movement when a collision occurs. We need to code whatever response we
 want from the collision.
 

tutorials/plugins/editor/import_plugins.rst

@@ -258,7 +258,7 @@ Note that the ``get_import_options`` method receives the preset number, so you
 can configure the options for each different preset (especially the default
 value). In this example we use the ``match`` statement, but if you have lots of
 options and the presets only change the value you may want to create the array
-of options first and then just change it based on the preset.
+of options first and then change it based on the preset.
 
 .. warning:: The ``get_import_options`` method is called even if you don't
              define presets (by making ``get_preset_count`` return zero). You
@@ -396,7 +396,7 @@ in a different file:
 Trying the plugin
 -----------------
 
-This has been very theoretical, but now that the import plugin is done, let's
+This has been theoretical, but now that the import plugin is done, let's
 test it. Make sure you created the sample file (with the contents described in
 the introduction section) and save it as ``test.mtxt``. Then activate the plugin
 in the Project Settings.

tutorials/plugins/editor/making_plugins.rst

@@ -187,14 +187,14 @@ Don't forget to add a text to your button.
 
 Save this scene as ``my_dock.tscn``.
 
-Now you need to grab that scene you just created and add it as a dock in the
+Now you need to grab that scene you created and add it as a dock in the
 editor. For this you can rely on the function
 :ref:`add_control_to_dock() <class_EditorPlugin_add_control_to_dock>` from the
 :ref:`EditorPlugin <class_EditorPlugin>` class.
 
-The code is very straightforward, you just need to select a dock position to
+The code is straightforward, you need to select a dock position to
 add it and have a control to add (which is the scene you just created). It is
-also very important that you remember to **remove the dock** when the plugin is
+also important that you remember to **remove the dock** when the plugin is
 deactivated. The code can be like this::
 
     tool
@@ -230,10 +230,10 @@ corner.
 
 .. image:: img/making_plugins-project_settings.png
 
-At the *Status* column, you can see that the plugin is inactive. So you just
+At the *Status* column, you can see that the plugin is inactive. So you
 need to click on the status to select *Active*. The dock should be immediately
-visible, even before you close the settings window. And now, lo and behold, you
-have a custom dock! In just a bit of coding and a simple scene.
+visible, even before you close the settings window. You should
+have a custom dock:
 
 .. image:: img/making_plugins-custom_dock.png
 

tutorials/plugins/gdnative/gdnative-c-example.rst

@@ -36,7 +36,7 @@ Before we start you'll need a few things.
 2) A C compiler
 3) A copy of this repository: https://github.com/GodotNativeTools/godot_headers
 
-The first two pretty much speak for themselves. On Linux, you'll likely have a C compiler, on macOS, it's easiest to just install Xcode from the Mac App Store and, on Windows, we've tested this with both MSVC 2015 and 2017.
+The first two pretty much speak for themselves. On Linux, you'll likely have a C compiler, on macOS, it's easiest to install Xcode from the Mac App Store and, on Windows, we've tested this with both MSVC 2015 and 2017.
 
 For number 3, we suggest that you create a folder somewhere that you use to store your code, open up a terminal and CD into that folder. Then execute:
 
@@ -70,7 +70,7 @@ Let's start by writing our main code. Ideally, we want to end up with a file str
 
 Open up Godot and create a new project called simple. This will create the simple folder and project.godot file. Then manually create a bin and src subfolder in this folder.
 
-We're going to start by having a look at what our simple.c file contains. Now, for our example here we're making a single C source file without a header just to keep things simple. Once you start writing bigger projects it is advisable you break your project up into multiple files. That however falls outside of the scope of this tutorial.
+We're going to start by having a look at what our simple.c file contains. Now, for our example here we're making a single C source file without a header to keep things simple. Once you start writing bigger projects it is advisable you break your project up into multiple files. That however falls outside of the scope of this tutorial.
 
 We'll be looking at the source code bit by bit so all the parts below should all be put together into one big file. I'll explain each section as we add it.
 

tutorials/shading/screen-reading_shaders.rst

@@ -72,7 +72,7 @@ While this seems magical, it's not. The SCREEN_TEXTURE built-in, when
 first found in a node that is about to be drawn, does a full-screen
 copy to a back-buffer. Subsequent nodes that use it in
 shaders will not have the screen copied for them, because this ends up
-being very inefficient.
+being inefficient.
 
 As a result, if shaders that use SCREEN_TEXTURE overlap, the second one
 will not use the result of the first one, resulting in unexpected

tutorials/shading/shader_materials.rst

@@ -45,7 +45,7 @@ Converting to ShaderMaterial
 ----------------------------
 
 It is possible to convert from SpatialMaterial, CanvasItemMaterial and
-ParticlesMaterial to ShaderMaterial. Just go to the material properties
+ParticlesMaterial to ShaderMaterial. To do this go to the material properties
 and enable the convert option.
 
 .. image:: img/shader_material_convert.png

tutorials/shading/shading_language.rst

@@ -6,7 +6,7 @@ Shading language
 Introduction
 ------------
 
-Godot uses a shading language very similar to GLSL ES 3.0. Most datatypes and functions are supported,
+Godot uses a shading language similar to GLSL ES 3.0. Most datatypes and functions are supported,
 and the few remaining ones will likely be added over time.
 
 Unlike the shader language in Godot 2.x, this implementation is much closer to the original.
@@ -182,8 +182,8 @@ Using lower precision for some operations can speed up the math involved (at the
 This is rarely needed in the vertex shader (where full precision is needed most of the time), but often needed in the fragment one.
 
 Keep in mind that some architectures (mainly mobile) benefit a lot from this, but are also restricted (conversion between precisions has a cost).
-Please read the relevant documentation on the target architecture to find out more. In all honesty though, mobile drivers are really buggy
-so just stay out of trouble and make simple shaders without specifying precision unless you *really* need to.
+Please read the relevant documentation on the target architecture to find out more. In all honesty though, mobile drivers are buggy
+so to stay out of trouble make simple shaders without specifying precision unless you *really* need to.
 
 Operators:
 ----------

tutorials/viewports/multiple_resolutions.rst

@@ -60,8 +60,8 @@ Stretch mode
    is set as a render target, and still renders precisely to the
    resolution specified in the ``display/`` section of the project
    settings. Finally, this viewport is copied and scaled to fit the
-   screen. This mode is useful when working with pixel-precise games, or
-   just for the sake of rendering to a lower resolution for improving
+   screen. This mode is useful when working with pixel-precise games,
+   or for the sake of rendering to a lower resolution for improving
    performance.
 
 .. image:: img/stretch.png

tutorials/viewports/viewports.rst

@@ -6,7 +6,7 @@ Viewports
 Introduction
 ------------
 
-Godot has a small but very useful feature called viewports. Viewports
+Godot has a small but useful feature called viewports. Viewports
 are, as the name implies, rectangles where the world is drawn. They
 have three main uses, but can flexibly adapted to a lot more. All this
 is done via the :ref:`Viewport <class_Viewport>` node.
@@ -74,7 +74,7 @@ Scale & stretching
 ------------------
 
 Viewports have a "rect" property. X and Y are often not used (only the
-root viewport really uses them), while WIDTH AND HEIGHT represent the
+root viewport uses them), while WIDTH AND HEIGHT represent the
 size of the viewport in pixels. For Sub-Viewports, these values are
 overridden by the ones from the parent control, but for render targets
 this sets their resolution.
@@ -108,7 +108,7 @@ the game (like in Starcraft).
 
 As a helper for situations where you want to create viewports that
 display single objects and don't want to create a world, viewport has
-the option to use its own World. This is very useful when you want to
+the option to use its own World. This is useful when you want to
 instance 3D characters or objects in the 2D world.
 
 For 2D, each Viewport always contains its own :ref:`World2D <class_World2D>`.
@@ -134,7 +134,7 @@ following API:
    # Set Sprite Texture
    $sprite.texture = tex
 
-But if you use this in _ready() or from the very first frame of the viewport's initialization
+But if you use this in _ready() or from the first frame of the viewport's initialization
 you will get an empty texture cause there is nothing to get as texture. You can deal with
 it using (for example):
 
@@ -167,7 +167,7 @@ And Viewport Container can not be smaller than the size of the Viewport.
 Render target
 -------------
 
-To set as a render target, just toggle the "render target" property of
+To set as a render target, toggle the "render target" property of
 the viewport to enabled. Note that whatever is inside will not be
 visible in the scene editor. To display the contents, the method remains the same.
 This can be requested via code using (for example):

tutorials/vr/vr_primer.rst

@@ -13,7 +13,7 @@ AR/VR Server
 
 When Godot starts each available interface will make itself known to the AR/VR server. GDNative interfaces are setup as singletons, as long as they are added to the list of GDNative singletons in your project they will make themselves known to the server.
 
-You can use the function :ref:`get_interfaces <class_ARVRServer_get_interfaces>` to return a list of available interfaces but for this tutorial we're going to use the :ref:`native mobile VR interface <class_MobileVRInterface>` in our examples. This interface is a very simple and straight forward implementation that uses the 3DOF sensors on your phone for orientation and outputs a stereo scopic image to screen. It is also available in the Godot core and outputs to screen on desktop which makes it ideal for prototyping or a tutorial such as this one.
+You can use the function :ref:`get_interfaces <class_ARVRServer_get_interfaces>` to return a list of available interfaces but for this tutorial we're going to use the :ref:`native mobile VR interface <class_MobileVRInterface>` in our examples. This interface is a straightforward implementation that uses the 3DOF sensors on your phone for orientation and outputs a stereo scopic image to screen. It is also available in the Godot core and outputs to screen on desktop which makes it ideal for prototyping or a tutorial such as this one.
 
 To enable an interface you execute the following code:
 
@@ -36,7 +36,7 @@ This code finds the interface we wish to use, initializes it and if that is succ
 
 For our mobile vr interface, and any interface where the main input is directly displayed on screen, the main viewport needs to be the viewport where arvr is set to true. But for interfaces that render on an externally attached device you can use a secondary viewport. In this later case a viewport that shows its output on screen will show an undistorted version of the left eye while showing the fully processed stereo scopic output on the device.
 
-Finally you should only initialize an interface once, switching scenes and reinitializing interfaces will just introduce a lot of overhead. If you want to turn the headset off temporarily just disable the viewport or set arvr to false on the viewport. In most scenarios though you wouldn't disable the headset once you're in VR, this can be very disconcerting to the gamer.
+Finally you should only initialize an interface once, switching scenes and reinitializing interfaces will just introduce a lot of overhead. If you want to turn the headset off temporarily just disable the viewport or set arvr to false on the viewport. In most scenarios though you wouldn't disable the headset once you're in VR, this can be disconcerting to the gamer.
 
 New AR/VR Nodes
 ---------------
@@ -77,7 +77,7 @@ Most VR platforms including our AR/VR Server assumes that 1 unit = 1 meter. The
 Performance is another thing that needs to be carefully considered. Especially VR taxes your game a lot more then most people realise. For mobile VR you have to be extra careful here but even for desktop games there are three factors that make life extra difficult:
 
 * You are rendering stereoscopic, two for the price of one. While not exactly doubling the work load and with things in the pipeline such as supporting the new MultiView OpenGL extension in mind, there still is an extra workload in rendering images for both eyes
-* A normal game will run acceptable on 30fps and ideally manages 60fps. That gives you a big range to play with between lower end and higher end hardware. For any HMD application of AR or VR however 60fps is the absolute minimum and you really should target your games to running 90fps stabily to ensure your users don't get motion sickness right off the bat.
+* A normal game will run acceptable on 30fps and ideally manages 60fps. That gives you a big range to play with between lower end and higher end hardware. For any HMD application of AR or VR however 60fps is the absolute minimum and you should target your games to run at a stable 90fps to ensure your users don't get motion sickness right off the bat.
 * The high FOV and related lens distortion effect require many VR experiences to render at double the resolution. Yes a VIVE may only have a resolution of 1080x1200 per eye, we're rendering each eye at 2160x2400 as a result. This is less of an issue for most AR applications.
 
 All in all, the workload your GPU has in comparison with a normal 3D game is a fair amount higher. While things are in the pipeline to improve this such as MultiView and foviated rendering these aren't supported on all devices. This is why you see many VR games using a more art style and if you pay close attention to those VR games that go for realism, you'll probably notice they're a bit more conservative on the effects or use some good old optical trickery.