From be6ef615b18405b3f108a9d4bacbed9ad33b6193 Mon Sep 17 00:00:00 2001 From: Yuri Chornoivan Date: Sun, 1 Jul 2018 10:30:51 +0300 Subject: [PATCH] Fix minor typos --- community/contributing/pr_workflow.rst | 2 +- development/file_formats/tscn.rst | 14 +++++++------- .../scripting/c_sharp/c_sharp_style_guide.rst | 2 +- .../scripting/visual_script/nodes_purposes.rst | 2 +- .../step_by_step/godot_design_philosophy.rst | 2 +- .../workflow/assets/importing_images.rst | 2 +- tutorials/3d/environment_and_post_processing.rst | 4 ++-- tutorials/3d/fps_tutorial/part_four.rst | 2 +- tutorials/3d/fps_tutorial/part_three.rst | 2 +- tutorials/3d/fps_tutorial/part_two.rst | 2 +- tutorials/3d/lights_and_shadows.rst | 2 +- tutorials/3d/spatial_material.rst | 2 +- tutorials/i18n/internationalizing_games.rst | 2 +- tutorials/io/data_paths.rst | 2 +- tutorials/viewports/viewports.rst | 6 +++--- 15 files changed, 24 insertions(+), 24 deletions(-) diff --git a/community/contributing/pr_workflow.rst b/community/contributing/pr_workflow.rst index 7f4949699..2bcbea2f8 100644 --- a/community/contributing/pr_workflow.rst +++ b/community/contributing/pr_workflow.rst @@ -30,7 +30,7 @@ The `repository on GitHub `_ is a `Git `_ code repository together with an embedded issue tracker and PR system. -.. note:: If you are contributing to the documention, its repository can +.. note:: If you are contributing to the documentation, its repository can be found `here `_. The Git version control system is the tool used to keep track of successive diff --git a/development/file_formats/tscn.rst b/development/file_formats/tscn.rst index 66e8f13cd..95f5a2809 100644 --- a/development/file_formats/tscn.rst +++ b/development/file_formats/tscn.rst @@ -154,7 +154,7 @@ Skeleton ~~~~~~~~~ Skeleton node inherits Spatial node, besides that it may have a list of bones described in key, value pair in the format :code:`bones/Id/Attribute=Value`, -attributes of bone consisits of +attributes of bone consists of - name - parent @@ -272,7 +272,7 @@ itself. An external resource consists of: - A type - An ID -Godot alway generates absolute paths relative to the resource directory and +Godot always generates absolute paths relative to the resource directory and thus prefixed with :code:`res://`, but paths relative to the TSCN file's location are also valid. @@ -325,10 +325,10 @@ TSCN support two format of surface, i) :code:`primitive` is an enumerate variable, :code:`primitive=4` which is PRIMITIVE_TRIANGLES is frequently used. - ii) :code:`arrays` as name suggestes is an array of array, it contains: + ii) :code:`arrays` as name suggests is an array of array, it contains: 1) a array of vertex position - 2) tagents array + 2) tangents array 3) vertex color array 4) UV array 1 5) UV array 2 @@ -372,8 +372,8 @@ An animation resource consists of tracks. Besides, it has 'length', 'loop' and 1) :code:`length` and :code:`step` are both time in seconds -Each track is described by a list of key, value pairt in the format :code:`tracks/Id/Attribute`, -it includs: +Each track is described by a list of key, value pair in the format :code:`tracks/Id/Attribute`, +it includes: - type - path @@ -406,7 +406,7 @@ it includs: but have different structure for track with different type - A transform track use every 12 real number in the :code:`keys` to describte a keyframe. - The first number is the timestamp, the second number is the transision (default 1.0 + The first number is the timestamp, the second number is the transition (default 1.0 in transform track), followed by a three number translation vector, followed by four number rotation quaternion (x,y,z,w) and finally a three number scale vector. diff --git a/getting_started/scripting/c_sharp/c_sharp_style_guide.rst b/getting_started/scripting/c_sharp/c_sharp_style_guide.rst index dcb297444..6a772377a 100644 --- a/getting_started/scripting/c_sharp/c_sharp_style_guide.rst +++ b/getting_started/scripting/c_sharp/c_sharp_style_guide.rst @@ -155,7 +155,7 @@ Do not use a space, * After a type cast parentheses. * Within single line initializer braces. -The following example shows a proper use of spaces, according to some of the the above mentioned conventions: +The following example shows a proper use of spaces, according to some of the above mentioned conventions: .. code-block:: csharp diff --git a/getting_started/scripting/visual_script/nodes_purposes.rst b/getting_started/scripting/visual_script/nodes_purposes.rst index 77edb0331..0f2b26638 100644 --- a/getting_started/scripting/visual_script/nodes_purposes.rst +++ b/getting_started/scripting/visual_script/nodes_purposes.rst @@ -473,7 +473,7 @@ Operators These are mostly generic operators such as addition, multiplication, comparison, etc. By default, these mostly accept any datatype (and will error in run-time if the types -feeded do not match for the operator). It is always recommended to set the right +fed do not match for the operator). It is always recommended to set the right type for operators to catch errors faster and make the graph easier to read. .. image:: img/visual_script46.png diff --git a/getting_started/step_by_step/godot_design_philosophy.rst b/getting_started/step_by_step/godot_design_philosophy.rst index 469b6425e..e80e9d7a5 100644 --- a/getting_started/step_by_step/godot_design_philosophy.rst +++ b/getting_started/step_by_step/godot_design_philosophy.rst @@ -109,7 +109,7 @@ means all the technologies that ship with it have to be Free (as in freedom) as For the most part, they’re coded from the ground-up by contributors. Anyone can plug in proprietary tools for the needs of their projects - -they just won’t ship with the engine. This may include NViDia PhysX, +they just won’t ship with the engine. This may include Nvidia PhysX, Google Admob, or an FBX file importer. Any of these can come as third-party plugins instead. diff --git a/getting_started/workflow/assets/importing_images.rst b/getting_started/workflow/assets/importing_images.rst index d64bb525c..af97583f8 100644 --- a/getting_started/workflow/assets/importing_images.rst +++ b/getting_started/workflow/assets/importing_images.rst @@ -126,7 +126,7 @@ When set to "Detect" mode, the texture will be marked as SRGB when used in albed Process ------- -Some special processes can be applied to images when importe as texture. +Some special processes can be applied to images when imported as texture. Fix Alpha Border ~~~~~~~~~~~~~~~~ diff --git a/tutorials/3d/environment_and_post_processing.rst b/tutorials/3d/environment_and_post_processing.rst index a8fee3ef8..ec4200f91 100644 --- a/tutorials/3d/environment_and_post_processing.rst +++ b/tutorials/3d/environment_and_post_processing.rst @@ -154,7 +154,7 @@ Auto Exposure (HDR) ^^^^^^^^^^^^^^^^^^^ Even though, in most cases, lighting and texturing are heavily artist controlled, -Godot suports a simple high dynamic range implementation with the auto exposure +Godot supports a simple high dynamic range implementation with the auto exposure mechanism. This is generally used for the sake of realism when combining interior areas with low light and outdoors. Auto exposure simulates the camera (or eye) in an effort to adapt between light and dark locations and their @@ -209,7 +209,7 @@ A few user-controlled parameters are available to better tweak the technique: - **Max Steps** determines the length of the reflection. The bigger this number, the more costly it is to compute. - **Fade In** allows adjusting the fade-in curve, which is useful to make the contact area softer. - **Fade Out** allows adjusting the fade-out curve, so the step limit fades out softly. -- **Depth Tolerance** can be used for scren-space-ray hit tolerance to gaps. The bigger the value, the more gaps will be ignored. +- **Depth Tolerance** can be used for screen-space-ray hit tolerance to gaps. The bigger the value, the more gaps will be ignored. - **Roughness** will apply a screen-space blur to approximate roughness in objects with this material characteristic. Keep in mind that screen-space-reflections only work for reflecting opaque geometry. Transparent objects can't be reflected. diff --git a/tutorials/3d/fps_tutorial/part_four.rst b/tutorials/3d/fps_tutorial/part_four.rst index bcba6630b..0de2dd206 100644 --- a/tutorials/3d/fps_tutorial/part_four.rst +++ b/tutorials/3d/fps_tutorial/part_four.rst @@ -363,7 +363,7 @@ first ``setget`` call, we would get several errors in the debugger. Also, notice how we are using a exported variable. This is so we can change the size of the health pick ups in the editor. This makes it where we do not have to make two scenes for the two sizes, since we can easily change sizes in the editor using the exported variable. -.. tip:: See :ref:`doc_GDScript` and scroll down to the Exports section for a list of of export hints you can use. +.. tip:: See :ref:`doc_GDScript` and scroll down to the Exports section for a list of export hints you can use. ______ diff --git a/tutorials/3d/fps_tutorial/part_three.rst b/tutorials/3d/fps_tutorial/part_three.rst index 2d4049c18..be68910a9 100644 --- a/tutorials/3d/fps_tutorial/part_three.rst +++ b/tutorials/3d/fps_tutorial/part_three.rst @@ -675,7 +675,7 @@ There's still a few things that would be nice to add, and we're going to add the 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 ` 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! +In :ref:`doc_fps_tutorial_part_four` we'll add some targets to shoot at, along with some health and ammo pick ups! We're also going to add joypad support, so we can play with wired Xbox 360 controllers! .. warning:: If you ever get lost, be sure to read over the code again! diff --git a/tutorials/3d/fps_tutorial/part_two.rst b/tutorials/3d/fps_tutorial/part_two.rst index 9be33b6c4..88d264093 100644 --- a/tutorials/3d/fps_tutorial/part_two.rst +++ b/tutorials/3d/fps_tutorial/part_two.rst @@ -206,7 +206,7 @@ _________ Lets look at ``set_animation`` next. -``set_animation`` changes the animation to the the animation named ``animation_name`` +``set_animation`` changes the animation to the animation named ``animation_name`` *if* we can transition to it. In other words, if the animation state we are currently in has the passed in animation state name in ``states``, then we will change to that animation. diff --git a/tutorials/3d/lights_and_shadows.rst b/tutorials/3d/lights_and_shadows.rst index f9c660f77..843a55310 100644 --- a/tutorials/3d/lights_and_shadows.rst +++ b/tutorials/3d/lights_and_shadows.rst @@ -61,7 +61,7 @@ Finally, if gaps can't be solved, the **Contact** option can help: .. image:: img/shadow_contact.png Any sort of bias issues can always be fixed by increasing the shadow map resolution, -although that may lead to decreased peformance on low-end hardware. +although that may lead to decreased performance on low-end hardware. Directional light ~~~~~~~~~~~~~~~~~ diff --git a/tutorials/3d/spatial_material.rst b/tutorials/3d/spatial_material.rst index 43cf93162..bf6841a66 100644 --- a/tutorials/3d/spatial_material.rst +++ b/tutorials/3d/spatial_material.rst @@ -350,7 +350,7 @@ Depth Setting a depth map to a material produces a ray-marched search to emulate the proper displacement of cavities along the view direction. This is not real added geometry, but an illusion of depth. -It may not work for complex objets, but it produces a realistic depth effect for textues. +It may not work for complex objects, but it produces a realistic depth effect for textures. For best results, *Depth* should be used together with normal mapping. .. image:: img/spatial_material20.png diff --git a/tutorials/i18n/internationalizing_games.rst b/tutorials/i18n/internationalizing_games.rst index 6772df695..be1f76669 100644 --- a/tutorials/i18n/internationalizing_games.rst +++ b/tutorials/i18n/internationalizing_games.rst @@ -22,7 +22,7 @@ them is already covered in the :ref:`doc_importing_translations` tutorial, so th one could be seen more like a follow up to that one. -.. note:: We would be using the offical demo as an example, you can download it in the AssetLib: https://godotengine.org/asset-library/asset/134 or find it in the demo_projects/gui/translation +.. note:: We would be using the official demo as an example, you can download it in the AssetLib: https://godotengine.org/asset-library/asset/134 or find it in the demo_projects/gui/translation Configuring the imported translation ------------------------------------ diff --git a/tutorials/io/data_paths.rst b/tutorials/io/data_paths.rst index 22776497d..eacf37856 100644 --- a/tutorials/io/data_paths.rst +++ b/tutorials/io/data_paths.rst @@ -38,5 +38,5 @@ to the project. On desktop operating systems, the engine uses the typical ``~/.local/share/godot/app_userdata/Name`` on macOS and Linux, and ``%APPDATA%/Name`` on Windows. ``Name`` is taken from the application name defined in the Project Settings, but it can be -overriden on a per-platform basis using +overridden on a per-platform basis using :ref:`feature tags `. diff --git a/tutorials/viewports/viewports.rst b/tutorials/viewports/viewports.rst index ec5eb5b13..9543eab39 100644 --- a/tutorials/viewports/viewports.rst +++ b/tutorials/viewports/viewports.rst @@ -39,7 +39,7 @@ Input :ref:`Viewports ` are also responsible for delivering properly adjusted and scaled input events to all their children nodes. Typically input is received by the -nearest :ref:`Viewport ` in the tree, but you can set :ref:`Viewports ` to not recieve input by checking +nearest :ref:`Viewport ` in the tree, but you can set :ref:`Viewports ` to not receive input by checking 'Disable Input' to 'on', this will allow the next nearest :ref:`Viewport ` in the tree to capture the input. @@ -69,7 +69,7 @@ following hierarchy: CameraA will display on the Root :ref:`Viewport ` and it will draw MeshA. CameraB will be captured by the :ref:`Viewport ` Node along with MeshB. Even though MeshB is in the scene heirarchy, it will still not be drawn to the Root :ref:`Viewport `. Similarly MeshA will not -be visible from the :ref:`Viewport ` node becuase :ref:`Viewport ` nodes only capture nodes below them +be visible from the :ref:`Viewport ` node because :ref:`Viewport ` nodes only capture nodes below them in the heirarchy. There can only be one active camera per :ref:`Viewport `, so if there is more @@ -206,7 +206,7 @@ Overdraw draws the meshes semi-transparent with an additive blend so you can see *The same scene with Debug Draw set to Overdraw* Lastly, Wireframe draws the scene using only the edges of triangles in the meshes. NOTE: as of the -writting of this (v3.0.2) wireframe is broken and currently just renders the scene normally. +writing of this (v3.0.2) wireframe is broken and currently just renders the scene normally. Render target -------------