Edit the scripting section

Misc grammar fixes, improvements to phrasing, and more.

Co-authored-by: balloonpopper <5151242+balloonpopper@users.noreply.github.com>

tutorials/io/saving_games.rst

@@ -25,7 +25,7 @@ sessions and what information we want to keep from those objects. For
 this tutorial, we will use groups to mark and handle objects to be saved,
 but other methods are certainly possible.
 
-We will start by adding objects we wish to save to the "Persist" group. we can
+We will start by adding objects we wish to save to the "Persist" group. We can
 do this through either the GUI or script. Let's add the relevant nodes using the
 GUI:
 

tutorials/scripting/gdscript/gdscript_basics.rst

@@ -1211,7 +1211,7 @@ path. For example, if you name a script file ``character.gd``::
 Registering named classes
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Instead, you can give your class a name to register it as a new type in Godot's
+You can give your class a name to register it as a new type in Godot's
 editor. For that, you use the ``class_name`` keyword. You can optionally use
 the ``@icon`` annotation with a path to an image, to use it as an icon. Your
 class will then appear with its new icon in the editor::

tutorials/scripting/gdscript/static_typing.rst

@@ -107,7 +107,7 @@ Currently you can use three types of… types:
 1. :ref:`Built-in <doc_gdscript_builtin_types>`
 2. Core classes and nodes (``Object``, ``Node``, ``Area2D``,
    ``Camera2D``, etc.)
-3. Your own, custom classes. Look at the new :ref:`class_name <doc_gdscript_basics_class_name>`
+3. Your own custom classes. Look at the new :ref:`class_name <doc_gdscript_basics_class_name>`
    feature to register types in the editor.
 
 .. note::

tutorials/scripting/groups.rst

@@ -83,7 +83,7 @@ scene tree.
         AddToGroup("guards");
     }
 
-Imagine you're creating a strategy game inspired by Metal Gear Solid. When an
+Imagine you're creating an infiltration game. When an
 enemy spots the player, you want all guards and robots to be on alert.
 
 In the fictional example below, we use ``SceneTree.call_group()`` to alert all

tutorials/scripting/idle_and_physics_processing.rst

@@ -4,7 +4,7 @@ Idle and Physics Processing
 ===========================
 
 Games run in a loop. Each frame, you need to update the state of your game world
-before drawing it on screen. Godot provides two virtual methods on the Node
+before drawing it on screen. Godot provides two virtual methods in the Node
 class to do so: :ref:`Node._process() <class_Node_method__process>` and
 :ref:`Node._physics_process() <class_Node_method__physics_process>`. If you
 define either or both in a script, the engine will call them automatically.
@@ -14,7 +14,7 @@ There are two types of processing available to you:
 1. **Idle processing** allows you to run code that updates a node every frame,
    as often as possible.
 2. **Physics processing** happens at a fixed rate, 60 times per second by
-   default, independently of your game's actual framerate, and keeps physics
+   default. This is independent of your game's actual framerate, and keeps physics
    running smoothly. You should use it for anything that involves the physics
    engine, like moving a body that collides with the environment.
 
@@ -70,12 +70,12 @@ The engine calls this method every time it draws a frame:
         // Do something...
     }
 
-The function ``_process()`` is not synced with physics. Its rate depends on
-hardware and game optimization. It also runs after the physics step on
+The function ``_process()`` is not synchronized with physics. Its rate depends on
+hardware and game optimization. It also runs after the physics step in
 single-threaded games.
 
 You can see the ``_process()`` function at work by creating a scene with a
-single Label node, with the following script:
+single Label node, with the following script attached to it:
 
 .. tabs::
  .. code-tab:: gdscript GDScript

tutorials/scripting/index.rst

@@ -26,7 +26,7 @@ case, an interface that works with multiple languages.
 Core features
 -------------
 
-Some features are specific to the engine and available in all supported
+Some features are specific to the engine and are available in all supported
 languages. Whether you code in GDScript, C#, or another language, the pages
 below will help you make the most of Godot.
 

tutorials/scripting/nodes_and_scene_instances.rst

@@ -14,7 +14,7 @@ You can get a reference to a node by calling the :ref:`Node.get_node()
 present in the scene tree. Getting it in the parent node's ``_ready()`` function
 guarantees that.
 
-Say you have a scene tree like this, and you want to get a reference to the
+If, for example,  you have a scene tree like this, and you want to get a reference to the
 Sprite and Camera2D nodes to access them in your script.
 
 .. image:: img/nodes_and_scene_instances_player_scene_example.png
@@ -50,7 +50,7 @@ node into Skin, the call to get it would have to be ``get_node("Skin")``.
 Node paths
 ----------
 
-You're not limited to getting a direct child. The ``get_node()`` function
+When getting a reference to a node, you're not limited to getting a direct child. The ``get_node()`` function
 supports paths, a bit like when working with a file browser. Add a slash to
 separate nodes.
 
@@ -81,15 +81,15 @@ To get the Tween node, you would use the following code.
     }
 
 .. note:: As with file paths, you can use ".." to get a parent node. The best
-          practice is to avoid doing that though not to break encapsulation and
-          keep your code organized. You can also start the path with a forward
+          practice is to avoid doing that though not to break encapsulation.
+          You can also start the path with a forward
           slash to make it absolute, in which case your topmost node would be
           "/root", the application's predefined root viewport.
 
 Syntactic sugar
 ~~~~~~~~~~~~~~~
 
-You can use two shorthands to shorten your code in GDScript: putting the
+You can use two shorthands to shorten your code in GDScript. Firstly, putting the
 ``onready`` keyword before a member variable makes it initialize right before
 the ``_ready()`` callback.
 
@@ -138,7 +138,7 @@ script.
 
 To delete a node and free it from memory, you can call its ``queue_free()``
 method. Doing so queues the node for deletion at the end of the current frame
-after it finished processing. At that point, the engine removes the node from
+after it has finished processing. At that point, the engine removes the node from
 the scene and frees the object in memory.
 
 .. tabs::
@@ -176,8 +176,9 @@ Instancing a scene from code happens in two steps:
 
     var scene = GD.Load<PackedScene>("res://MyScene.tscn");
 
-Preloading it can improve the user's experience as it happens when parsing the
-script. This feature is only available with GDScript.
+Preloading the scene can improve the user's experience as the load operation
+happens when the compiler reads the script and not at runtime. This feature is
+only available with GDScript.
 
 .. tabs::
  .. code-tab:: gdscript GDScript
@@ -187,7 +188,7 @@ script. This feature is only available with GDScript.
 At that point, ``scene`` is a packed scene resource, not a node. To create the
 actual node, you need to call :ref:`PackedScene.instance()
 <class_PackedScene_method_instance>`. It returns a tree of nodes that you can
-add as a child.
+as a child of your current node.
 
 .. tabs::
  .. code-tab:: gdscript GDScript

tutorials/scripting/overridable_functions.rst

@@ -8,7 +8,7 @@ every frame or on specific events, like when they enter the scene tree.
 
 This document presents the ones you'll use most often.
 
-.. seealso:: Under the hood, these functions rely on Godot's uses a low-level
+.. seealso:: Under the hood, these functions rely on Godot's low-level
              notifications system. To learn more about it, see
              :ref:`doc_godot_notifications`.
 
@@ -16,13 +16,13 @@ Two functions allow you to initialize and get nodes, besides the class's
 constructor: ``_enter_tree()`` and ``_ready()``.
 
 When the node enters the Scene Tree, it becomes active and the engine calls its
-``_enter_tree()`` method. Children may not be part of the active scene yet. As
+``_enter_tree()`` method. That node's children may not be part of the active scene yet. As
 you can remove and re-add nodes to the scene tree, this function may be called
 multiple times throughout a node's lifetime.
 
 Most of the time, you'll use ``_ready()`` instead. This function is called only
-once in a node's lifetime, after ``_enter_tree()``. It ensures that all children
-have entered the scene tree first, so you can safely call ``get_node()`` in it.
+once in a node's lifetime, after ``_enter_tree()``. ``_ready()`` ensures that all children
+have entered the scene tree first, so you can safely call ``get_node()`` on it.
 
 .. seealso:: To learn more about getting node references, read
              :ref:`doc_nodes_and_scene_instances`.
@@ -43,7 +43,7 @@ a node exits the scene tree. This can be when you call :ref:`Node.remove_child()
         pass
 
     # Called when the node is about to leave the scene tree, after all its
-    children.
+    children received the _exit_tree() callback.
     func _exit_tree():
         pass
 
@@ -69,7 +69,7 @@ a node exits the scene tree. This can be when you call :ref:`Node.remove_child()
     }
 
 The two virtual methods ``_process()`` and ``_physics_process()`` allow you to
-update the node, respectively, every frame and every physics frame. For more
+update the node, every frame and every physics frame respectively. For more
 information, read the dedicated documentation:
 :ref:`doc_idle_and_physics_processing`.
 
@@ -100,15 +100,14 @@ information, read the dedicated documentation:
 
 Two more essential built-in node callback functions are
 :ref:`Node._unhandled_input() <class_Node_method__unhandled_input>` and
-:ref:`Node._input() <class_Node_method__input>`, which you both use to receive
+:ref:`Node._input() <class_Node_method__input>`, which you use to both receive
 and process individual input events. The ``_unhandled_input()`` method receives
-every key press, mouse click, etc. that had not been handled already in an
-``_input()`` callback or in a piece of user interface. You want to use it for
+every key press, mouse click, etc. that have not been handled already in an
+``_input()`` callback or in a user interface component. You want to use it for
 gameplay input in general. The ``_input()`` callback allows you to intercept and
 process input events before ``_unhandled_input()`` gets them.
 
-There's a lot to say about input handling in Godot. You'll find a lot more
-information in the :ref:`Input section <toc-learn-features-inputs>`.
+To learn more about inputs in Godot, see the :ref:`Input section <toc-learn-features-inputs>`.
 
 .. tabs::
  .. code-tab:: gdscript GDScript