4.0 spelling fixes

tutorials/3d/global_illumination/using_lightmap_gi.rst

@@ -115,7 +115,7 @@ their UV2 maps properly generated.
 .. 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
+    for the first instance found. If the mesh is reused with different scales
     (and the scales are wildly different, more than half or twice), this will
     result in inefficient lightmaps. To avoid this, adjust the **Lightmap
     Scale** property in the GeometryInstance3D section of a MeshInstance3D node.

tutorials/3d/using_transforms.rst

@@ -310,7 +310,7 @@ Setting information
 
 There are, of course, cases where you want to set information to a transform. Imagine a first person controller or orbiting camera. Those are definitely done using angles, because you *do want* the transforms to happen in a specific order.
 
-For such cases, keep the angles and rotations *outside* the transform and set them every frame. Don't try to retrieve and re-use them because the transform is not meant to be used this way.
+For such cases, keep the angles and rotations *outside* the transform and set them every frame. Don't try to retrieve and reuse them because the transform is not meant to be used this way.
 
 Example of looking around, FPS style:
 

tutorials/best_practices/scene_organization.rst

@@ -148,7 +148,7 @@ initialize it:
        GetNode(TargetPath); // Use parent-defined NodePath.
 
 These options hide the points of access from the child node. This in turn
-keeps the child **loosely coupled** to its environment. One can re-use it
+keeps the child **loosely coupled** to its environment. One can reuse it
 in another context without any extra changes to its API.
 
 .. note::

tutorials/best_practices/scenes_versus_scripts.rst

@@ -190,7 +190,7 @@ Conclusion
 
 In the end, the best approach is to consider the following:
 
-- If one wishes to create a basic tool that is going to be re-used in several
+- If one wishes to create a basic tool that is going to be reused in several
   different projects and which people of all skill levels will likely use
   (including those who don't label themselves as "programmers"), then chances
   are that it should probably be a script, likely one with a custom name/icon.

tutorials/networking/high_level_multiplayer.rst

@@ -249,7 +249,7 @@ Channels are also useful when used with the unreliable ordered transfer mode. Se
 cause packet loss, since packets which are slower to arrive are ignored. Separating them into multiple streams of homogeneous packets
 by using channels allows ordered transfer with little packet loss, and without the latency penalty caused by reliable mode.
 
-The default channel with index 0 is actually three different channels - one for each tansfer mode.
+The default channel with index 0 is actually three different channels - one for each transfer mode.
 
 Example lobby implementation
 ----------------------------

tutorials/performance/gpu_optimization.rst

@@ -90,7 +90,7 @@ possible. Godot's priorities are:
    scene, the faster the rendering will be. If a scene has a huge amount
    of objects (in the hundreds or thousands), try reusing the materials.
    In the worst case, use atlases to decrease the amount of texture changes.
--  **Reusing Shaders:** If materials can't be reused, at least try to re-use
+-  **Reusing Shaders:** If materials can't be reused, at least try to reuse
    shaders. Note: shaders are automatically reused between
    StandardMaterial3Ds that share the same configuration (features
    that are enabled or disabled with a check box) even if they have different