Merge pull request #9582 from russellsanborn/comma-before-but

Add commas before "but" throughout documentation

Author: skyace65

contributing/development/best_practices_for_engine_contributors.rst

@@ -167,7 +167,7 @@ who design software) to actually understand all future user needs. Trying to
 write very flexible structures that cater to many use cases at once is often a
 mistake.
 
-We may come up with something we believe is brilliant but later find out that
+We may come up with something we believe is brilliant, but later find out that
 users will never even use half of it or that they require features that don't
 quite fit into our original design, forcing us to either throw it away
 or make it even more complex.

contributing/development/code_style_guidelines.rst

@@ -35,7 +35,7 @@ fine. If you plan to contribute regularly, however, we strongly advise that you
 set up clang-format locally to check and automatically fix all your commits.
 
 .. warning:: Godot's code style should *not* be applied to third-party code,
-             i.e. that is included in Godot's source tree but was not written
+             i.e. code that is included in Godot's source tree, but was not written
              specifically for our project. Such code usually comes from
              different upstream projects with their own style guides (or lack
              thereof), and don't want to introduce differences that would make
@@ -65,7 +65,7 @@ Pre-commit hook
 ^^^^^^^^^^^^^^^
 
 For ease of use, we provide hooks for Git with the `pre-commit <https://pre-commit.com/>`__
-Python framework that will run clang-format automatically on all your commits with the 
+Python framework that will run clang-format automatically on all your commits with the
 correct version of clang-format.
 To set up:
 
@@ -77,7 +77,7 @@ To set up:
 
 You can also run the hook manually with ``pre-commit run``.
 
-.. note:: 
+.. note::
 
     Previously, we supplied a hook in the folder ``misc/hooks``. If you copied the
     script manually, these hooks should still work, but symlinks will be broken.
@@ -382,7 +382,7 @@ instead.
         // ...
     }
 
-For member variables, don't use Javadoc-style comments but use single-line comments instead:
+For member variables, don't use Javadoc-style comments, but use single-line comments instead:
 
 .. code-block:: cpp
 

contributing/development/compiling/introduction_to_the_buildsystem.rst

@@ -403,7 +403,7 @@ To perform an SCU build, use the ``scu_build=yes`` SCons option.
           regular build prior to submitting the PR. This is because SCU builds
           by nature include headers from earlier ``.cpp`` files in the
           translation unit, therefore won't catch all the includes you will
-          need in a regular build. The CI will catch these errors but it will
+          need in a regular build. The CI will catch these errors, but it will
           usually be faster to catch them on a local build on your machine.
 
 Export templates

contributing/documentation/building_the_manual.rst

@@ -120,7 +120,7 @@ If you run into errors, you may try the following command:
 
 If you get a ``MemoryError`` or ``EOFError``, you can remove the ``classes/`` folder and
 run ``make`` again.
-This will drop the class references from the final HTML documentation but will keep the
+This will drop the class references from the final HTML documentation, but will keep the
 rest intact.
 
 .. important::

contributing/documentation/contributing_to_the_documentation.rst

@@ -89,7 +89,7 @@ and to log in to use it. Once logged in, you can propose change like so:
 
 4. At the bottom of the web page, summarize the changes you made and click the
    button **Propose file change**. Make sure to replace the placeholder "Update file.rst"
-   by a short but clear one-line description, as this is the commit title.
+   by a short, but clear one-line description, as this is the commit title.
 
 5. On the following screens, click the **Create pull request** button until you
    see a message like *Username wants to merge 1 commit into godotengine:master

contributing/workflow/pr_review_guidelines.rst

@@ -12,7 +12,7 @@ Pull request review process
     wanting to know how to ensure that their PR is merged.
 
 From a high level, the ideal life cycle of a pull request looks like the
-following: 
+following:
 
   1. A contributor opens a PR that fixes a specific problem (optimally closing
      a GitHub `issue <https://github.com/godotengine/godot>`_ or implementing
@@ -33,9 +33,9 @@ following:
 
 This document will explain steps 2, 3, 4, and 5 in more detail. For a more
 detailed explanation of the pull request workflow please see the :ref:`pull
-request workflow document <doc_pr_workflow>`. 
+request workflow document <doc_pr_workflow>`.
 
-.. note:: 
+.. note::
   In practice these steps may blend together. Oftentimes maintainers will
   provide comments on code style and code quality at the same time and will
   approve a pull request for both.
@@ -160,7 +160,7 @@ As you review pull requests, keep the Godot `Code of Conduct
 
 * Always assume positive intent from others.
 
-* Feedback is always welcome but keep your criticism constructive.
+* Feedback is always welcome, but keep your criticism constructive.
 
 Here are some things to avoid as you iterate on a pull request with a
 contributor:
@@ -178,7 +178,7 @@ contributor:
   areas and in performance-sensitive areas than it is in editor code for
   example.
 
-* **Expanding the scope of a pull request.** 
+* **Expanding the scope of a pull request.**
 
   Providing context or related/similar issues or proposals that may be fixed
   similarly can be helpful, but adding a "may as well fix that thing over there
@@ -253,7 +253,7 @@ Merging pull requests
 In general, pull requests should only be merged by members of the production
 team or team leaders for pull requests in their area of the engine. For example,
 the networking team leader could merge a networking pull request that doesn't
-substantially change non-networking sections of code. 
+substantially change non-networking sections of code.
 
 In practice it is best to wait for a member of the production team to merge the
 pull request as they keep a close eye on the entire codebase and will likely
@@ -275,7 +275,7 @@ steps yourself.
 Production team members should ensure that the right people look at a pull
 request before it is merged. In some cases this may require multiple people to
 weigh in. In other cases, only one substantive approval is needed before the
-code can be merged. 
+code can be merged.
 
 In general, try not to merge things based on one review alone, especially if it
 is your own. Get a second opinion from another maintainer, and make sure all the

tutorials/2d/2d_sprite_animation.rst

@@ -271,7 +271,7 @@ released.
           it's important to keep in mind that ``play()`` isn't applied instantly.
           Instead, it's applied the next time the :ref:`AnimationPlayer <class_AnimationPlayer>` is processed.
           This may end up being on the next frame, causing a 'glitch' frame,
-          where the property change was applied but the animation was not.
+          where the property change was applied, but the animation was not.
           If this turns out to be a problem, after calling ``play()``, you can call ``advance(0)``
           to update the animation immediately.
 

tutorials/2d/2d_transforms.rst

@@ -45,7 +45,7 @@ resizing or stretching the screen. This transform is used internally (as
 described in :ref:`doc_multiple_resolutions`), but can also be manually set
 on each viewport.
 
-Input events are multiplied by this transform but lack the ones above. To
+Input events are multiplied by this transform, but lack the ones above. To
 convert InputEvent coordinates to local CanvasItem coordinates, the
 :ref:`CanvasItem.make_input_local() <class_CanvasItem_method_make_input_local>`
 function was added for convenience.

tutorials/3d/environment_and_post_processing.rst

@@ -499,7 +499,7 @@ own, the effect may not be that noticeable, which is intended.
 Instead, :abbr:`SSIL (Screen-Space Indirect Lighting)` is meant to be used as a
 *complement* to other global illumination techniques such as VoxelGI, SDFGI and
 LightmapGI. :abbr:`SSIL (Screen-Space Indirect Lighting)` also provides
-a subtle ambient occlusion effect, similar to SSAO but with less detail.
+a subtle ambient occlusion effect, similar to SSAO, but with less detail.
 
 This feature only provides indirect lighting. It is not a full global illumination
 solution. This makes it different from screen-space global illumination (SSGI)

tutorials/3d/lights_and_shadows.rst

@@ -160,12 +160,12 @@ at the cost of decreased performance.
     all" settings. To achieve the best visuals, you may need to use different
     shadow bias values on a per-light basis.
 
-**Note on Appearance Changes**: When enabling shadows on a light, be aware that the light's 
-appearance might change compared to when it's rendered without shadows in the compatibility 
-renderer. Due to limitations with older mobile devices, shadows are implemented using a multi-pass 
-rendering approach so lights with shadows are rendered in sRGB space instead of linear space. 
-This change in rendering space can sometimes drastically alter the light's appearance. To achieve a similar 
-appearance to an unshadowed light, you may need to adjust the light's energy setting. 
+**Note on Appearance Changes**: When enabling shadows on a light, be aware that the light's
+appearance might change compared to when it's rendered without shadows in the compatibility
+renderer. Due to limitations with older mobile devices, shadows are implemented using a multi-pass
+rendering approach so lights with shadows are rendered in sRGB space instead of linear space.
+This change in rendering space can sometimes drastically alter the light's appearance. To achieve a similar
+appearance to an unshadowed light, you may need to adjust the light's energy setting.
 
 Directional light
 -----------------
@@ -208,10 +208,10 @@ receive low-resolution shadows that may appear blocky.
 To fix this, a technique named *Parallel Split Shadow Maps* (PSSM) is used.
 This splits the view frustum in 2 or 4 areas. Each area gets its own shadow map.
 This allows small areas close to the viewer to have the same shadow resolution
-as a huge, far-away area. When shadows are enabled for DirectionalLight3D, the 
-default shadow mode is PSSM with 4 splits. In scenarios where an object is large 
-enough to appear in all four splits, it results in increased draw calls. Specifically, 
-such an object will be rendered five times in total: once for each of the four shadow 
+as a huge, far-away area. When shadows are enabled for DirectionalLight3D, the
+default shadow mode is PSSM with 4 splits. In scenarios where an object is large
+enough to appear in all four splits, it results in increased draw calls. Specifically,
+such an object will be rendered five times in total: once for each of the four shadow
 splits and once for the final scene rendering. This can impact performance, understanding
 this behavior is important for optimizing your scene and managing performance expectations.
 
@@ -535,7 +535,7 @@ not use mipmaps, which makes them faster to render. However, projectors will
 look grainy at distance. **Nearest/Linear Mipmaps** will look smoother at a
 distance, but projectors will look blurry when viewed from oblique angles. This
 can be resolved by using **Nearest/Linear Mipmaps Anisotropic**, which is the
-highest-quality mode but also the most expensive.
+highest-quality mode, but also the most expensive.
 
 If your project has a pixel art style, consider setting the filter to one of the
 **Nearest** values so that projectors use nearest-neighbor filtering. Otherwise,