Fix all paragraphs parsed as lineblocks by pandoc

contributing/doc_and_l10n_guidelines.rst

@@ -36,17 +36,19 @@ following rules must be respected :
 -  Respect the grammar and orthography
 -  Make use of the :ref:`doc_wiki_syntax`
 
-| Try to structure your page in order to enable users to include a page
-  directly in another page or even forum posts using the include wiki
-  syntax. For example, the syntax to include the page you are reading is
-  :
-| !{{include(Documentation writing and translating guidelines)}}.
+Try to structure your page in order to enable users to include a page
+directly in another page or even forum posts using the include wiki
+syntax. For example, the syntax to include the page you are reading is
+:
+
+!{{include(Documentation writing and translating guidelines)}}.
 
 Titles
 ~~~~~~
 
-| Please always begin pages with their name:
-| ``h1. <Insert your title here>``
+Please always begin pages with their name:
+
+``h1. <Insert your title here>``
 
 Also, avoid American CamelCase titles: titles' first word should begin
 with a capitalized letter, and every following word should not. Thus,
@@ -66,14 +68,15 @@ letter. This is good:
 Note for non-English authors
 ----------------------------
 
-| If you intend to create a new page in your language, you are asked to
-  firstly create the corresponding English page if it doesn't already
-  exist. **Do it even if you will not write it yourself, just leave it
-  blank.** Only then, create the corresponding page in your own
-  language. Maybe later, another contributor will translate your new
-  page to English.
-| **Remember** : even if Godot aims at being accessible to everyone,
-  English is the most frequent language for documentation.
+If you intend to create a new page in your language, you are asked to
+firstly create the corresponding English page if it doesn't already
+exist. **Do it even if you will not write it yourself, just leave it
+blank.** Only then, create the corresponding page in your own
+language. Maybe later, another contributor will translate your new
+page to English.
+
+**Remember** : even if Godot aims at being accessible to everyone,
+English is the most frequent language for documentation.
 
 Translating existing pages
 --------------------------

contributing/reference_filling_work.rst

@@ -87,9 +87,10 @@ Edit doc/base/classes.xml file
 First of all, check the :ref:`doc_list_of_classes_and_documenters`. Try to work
 on classes not already assigned nor filled.
 
-| This file is produced by Godot Engine. It is used by the editor, for
-  example in the Help window (F1, Shift+F1).
-| You can edit this file using your favourite text editor.
+This file is produced by Godot Engine. It is used by the editor, for
+example in the Help window (F1, Shift+F1).
+
+You can edit this file using your favourite text editor.
 
 Here is an example with the Node2D class:
 
@@ -217,8 +218,9 @@ method:
         Rotates the node of "degrees" degrees.
         
 
-| That's all!
-| You simply have to write any missing text between these marks:
+That's all!
+
+You simply have to write any missing text between these marks:
 
 -  
 -  
@@ -230,11 +232,12 @@ use if needed. Avoid grammar faults.
 I don't know what this method does!
 -----------------------------------
 
-| Not a problem. Leave it behind for now, and don't forget to notify the
-  missing methods when you request a pull of your changes. Another
-  editor will take care of it.
-| If you wonder what a method does, you can still have a look at its
-  implementation in Godot Engine's source code on GitHub. Also, if you
-  have a doubt, feel free to ask on the
-  `Forums <http://www.godotengine.org/projects/godot-engine/boards>`__
-  and on IRC (freenode, #godotengine).
+Not a problem. Leave it behind for now, and don't forget to notify the
+missing methods when you request a pull of your changes. Another
+editor will take care of it.
+
+If you wonder what a method does, you can still have a look at its
+implementation in Godot Engine's source code on GitHub. Also, if you
+have a doubt, feel free to ask on the
+`Forums <http://www.godotengine.org/projects/godot-engine/boards>`__
+and on IRC (freenode, #godotengine).

reference/command_line_tutorial.rst

@@ -119,10 +119,11 @@ instead of ``-export``. Their parameters and usage are the same.
 Running a script
 ----------------
 
-| It is possible to run a simple .gd script from the command line. This
-  feature is specially useful in very large projects, for batch
-  conversion of assets or custom import/export.
-| The script must inherit from SceneTree or MainLoop.
+It is possible to run a simple .gd script from the command line. This
+feature is specially useful in very large projects, for batch
+conversion of assets or custom import/export.
+
+The script must inherit from SceneTree or MainLoop.
 
 Here is a simple example of how it works:
 

reference/compiling_for_android.rst

@@ -28,10 +28,11 @@ For compiling under Windows, the following is required:
 Setting Up SCons
 ----------------
 
-| Set the environment variable ANDROID\_HOME to point to the Android
-  SDK.
-| Set the environment variable ANDROID\_NDK\_ROOT to point to the
-  Android NDK.
+Set the environment variable ANDROID\_HOME to point to the Android
+SDK.
+
+Set the environment variable ANDROID\_NDK\_ROOT to point to the
+Android NDK.
 
 To set those environment variables on Windows, press Windows+R, type
 "control system", then click on **Advanced system settings** in the left
@@ -209,9 +210,10 @@ If it still fails, open a command line and run logcat:
 
     C:\\android-sdk\\platform-tools> adb logcat
 
-| And check the output while the application is installed. Reason for
-  failure should be presented there.
-| Seek assistance if you can't figure it out.
+And check the output while the application is installed. Reason for
+failure should be presented there.
+
+Seek assistance if you can't figure it out.
 
 Application exits immediately
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

reference/compiling_for_ios.rst

@@ -41,8 +41,9 @@ for a Simulator executable.
 Run
 ---
 
-| To run on a device or simulator, follow these instructions:
-  :ref:`doc_exporting_for_ios`.
-| Replace or add your executable to the Xcode project, and change the
-  "executable name" property on Info.plist accordingly if you use an
-  alternative build.
+To run on a device or simulator, follow these instructions:
+:ref:`doc_exporting_for_ios`.
+
+Replace or add your executable to the Xcode project, and change the
+"executable name" property on Info.plist accordingly if you use an
+alternative build.

reference/core_types.rst

@@ -3,10 +3,11 @@
 Core types
 ==========
 
-| Godot has a rich set of classes and template that make for its core,
-  and everything is built upon them.
-| This reference will try to list them in order for their better
-  understanding.
+Godot has a rich set of classes and template that make for its core,
+and everything is built upon them.
+
+This reference will try to list them in order for their better
+understanding.
 
 Definitions
 -----------
@@ -43,15 +44,16 @@ terabytes of storage and gigahertz of CPU, and when an application needs
 more resources the OS will just 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,
-  but over time and with abuse, this can lead to segmentation.
-| Segmentation slowly creates holes that are too small for most common
-  allocations, so that memory is wasted. There is a lot of literature
-  about heap and segmentation, so this topic will not be developed
-  further here. Modern Operating Systems use paged memory, which helps
-  mitigate the problem of segmentation but doesn't solve it.
+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,
+but over time and with abuse, this can lead to segmentation.
+
+Segmentation slowly creates holes that are too small for most common
+allocations, so that memory is wasted. There is a lot of literature
+about heap and segmentation, so this topic will not be developed
+further here. Modern Operating Systems use paged memory, which helps
+mitigate the problem of segmentation but doesn't solve it.
 
 However, in many studies and tests, it is shown that given enough
 memory, if the maximum allocation size is below a given threshold in
@@ -185,12 +187,13 @@ References:
 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
-  identifier, as comparing them is basically comparing a pointer.
-| Creation of a StringName (specially a new one) is slow, but comparison
-  is fast.
+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
+identifier, as comparing them is basically comparing a pointer.
+
+Creation of a StringName (specially a new one) is slow, but comparison
+is fast.
 
 References:
 ~~~~~~~~~~~

reference/creating_android_modules.rst

@@ -6,10 +6,11 @@ Creating Android modules
 Introduction
 ------------
 
-| Making videogames portable is all fine and dandy, until mobile gaming
-  monetization shows up.
-| This area is complex, usually a mobile game that monetizes needs
-  special connections to a server for stuff such as:
+Making videogames portable is all fine and dandy, until mobile gaming
+monetization shows up.
+
+This area is complex, usually a mobile game that monetizes needs
+special connections to a server for stuff such as:
 
 -  Analytics
 -  In-app purchases
@@ -312,9 +313,10 @@ Check ``adb logcat`` for possible problems, then:
 Future
 ------
 
-| Godot has an experimental Java API Wrapper that allows to use the
-  entire Java API fro GDScript.
-| It's simple to use and it's used like this:
+Godot has an experimental Java API Wrapper that allows to use the
+entire Java API fro GDScript.
+
+It's simple to use and it's used like this:
 
 ::
 

reference/gdscript.rst

@@ -817,10 +817,11 @@ useful to make libraries of helper functions:
 Setters/Getters
 ~~~~~~~~~~~~~~~
 
-| It is often useful to know when an member variable changed. It may
-  also be desired to encapsulate its access. For this, GDScript provides
-  a *setter\_/\_getter* helper using the ``setget`` keyword.
-| Just add it at the end of the variable definition line like this:
+It is often useful to know when an member variable changed. It may
+also be desired to encapsulate its access. For this, GDScript provides
+a *setter\_/\_getter* helper using the ``setget`` keyword.
+
+Just add it at the end of the variable definition line like this:
 
 ::
 

tutorials/2d/canvas_layers.rst

@@ -15,16 +15,17 @@ which is the base for all 2D nodes. CanvasItems can be arranged in trees
 and they will inherit their transform. This means that, moving the
 parent, the children will be moved too.
 
-| These nodes are placed as direct or indirect children to a
-  :ref:`Viewport <class_Viewport>`,
-  and will be displayed through it.
-| Viewport has a property "canvas\_transform"
-  :ref:`Viewport.set_canvas_transform() <class_Viewport_set_canvas_transform>`,
-  which allows to transform all the CanvasItem hierarchy by a custom
-  :ref:`Matrix32 <class_Matrix32>`
-  transform. Nodes such as
-  :ref:`Camera2D <class_Camera2D>`,
-  work by changing that transform.
+These nodes are placed as direct or indirect children to a
+:ref:`Viewport <class_Viewport>`,
+and will be displayed through it.
+
+Viewport has a property "canvas\_transform"
+:ref:`Viewport.set_canvas_transform() <class_Viewport_set_canvas_transform>`,
+which allows to transform all the CanvasItem hierarchy by a custom
+:ref:`Matrix32 <class_Matrix32>`
+transform. Nodes such as
+:ref:`Camera2D <class_Camera2D>`,
+work by changing that transform.
 
 Changing the canvas transform is useful because it is a lot more
 efficient than moving the root canvas item (and hence the whole scene).

tutorials/2d/custom_drawing_in_2d.rst

@@ -107,9 +107,10 @@ OK! This is basically it! Enjoy drawing your own nodes!
 Tools
 -----
 
-| 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
-  (check the :ref:`doc_gdscript` reference if you forgot what this does).
+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
+(check the :ref:`doc_gdscript` reference if you forgot what this does).
 

tutorials/2d/cutout_animation.rst

@@ -85,11 +85,12 @@ rotating the torso:
 
 .. image:: /img/tutovec_torso1.gif
 
-| Ouch, that doesn't look good! The rotation pivot is wrong, this means
-  it needs to be adjusted.
-| This small little cross in the middle of the
-  :ref:`Sprite <class_Sprite>` is
-  the rotation pivot:
+Ouch, that doesn't look good! The rotation pivot is wrong, this means
+it needs to be adjusted.
+
+This small little cross in the middle of the
+:ref:`Sprite <class_Sprite>` is
+the rotation pivot:
 
 .. image:: /img/tuto_cutout4.png
 
@@ -137,12 +138,13 @@ skeleton like.. a skeleton. Is there any hope?.. Of Course!
 RemoteTransform2D Node
 ~~~~~~~~~~~~~~~~~~~~~~
 
-| Godot provides a special node,
-  :ref:`RemoteTransform2D <class_RemoteTransform2D>`.
-  This node will transform nodes that are sitting somewhere else in the
-  hierarchy, by copying it's transform to the remote node.
-| This enables to have a visibility order independent from the
-  hierarchy.
+Godot provides a special node,
+:ref:`RemoteTransform2D <class_RemoteTransform2D>`.
+This node will transform nodes that are sitting somewhere else in the
+hierarchy, by copying it's transform to the remote node.
+
+This enables to have a visibility order independent from the
+hierarchy.
 
 Simply create two more nodes as children from torso, remote\_arm\_l and
 remote\_hand\_l and link them to the actual sprites:
@@ -249,9 +251,10 @@ involves also moving the rest of the leg bones. Each motion of the foot
 involves rotating several other bones. This is quite complex and leads
 to imprecise results.
 
-| So, what if we could just move the foot and let the rest of the leg
-  accommodate to the new foot position?
-| This type of posing is called IK (Inverse Kinematic).
+So, what if we could just move the foot and let the rest of the leg
+accommodate to the new foot position?
+
+This type of posing is called IK (Inverse Kinematic).
 
 To create an IK chain, simply select a chain of bones from endpoint to
 the base for the chain. For example, to create an IK chain for the right
@@ -302,12 +305,16 @@ create a reference rest pose in one of the animations.
 
 Simply do the following steps:
 
-| 1. Make sure the rig is in "rest" (not doing any specific pose).
-| 2. Create a new animation, rename it to "rest".
-| 3. Select all nodes (box selection should work fine).
-| 4. Select "loc" and "rot" on the top menu.
-| 5. Push the key button. Keys will be inserted for everything, creating
-  a default pose.
+1. Make sure the rig is in "rest" (not doing any specific pose).
+
+2. Create a new animation, rename it to "rest".
+
+3. Select all nodes (box selection should work fine).
+
+4. Select "loc" and "rot" on the top menu.
+
+5. Push the key button. Keys will be inserted for everything, creating
+a default pose.
 
 .. image:: /img/tuto_cutout21.png
 

tutorials/2d/kinematic_character_2d.rst

@@ -6,18 +6,19 @@ Kinematic Character (2D)
 Introduction
 ~~~~~~~~~~~~
 
-| Yes, the name sounds strange. "Kinematic Character" WTF is that? The
-  reason is that when physics engines came out, they were called
-  "Dynamics" engines (because they dealt mainly with collision
-  responses). Many attempts were made to create a character controller
-  using the dynamics engines but it wasn't as easy as it seems. Godot
-  has one of the best implementations of dynamic character controller
-  you can find (as it can be seen in the 2d/platformer demo), but using
-  it requieres a considerable level of skill and understanding of
-  physics engines (or a lot of patience with trial and error).
-| 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.
+Yes, the name sounds strange. "Kinematic Character" WTF is that? The
+reason is that when physics engines came out, they were called
+"Dynamics" engines (because they dealt mainly with collision
+responses). Many attempts were made to create a character controller
+using the dynamics engines but it wasn't as easy as it seems. Godot
+has one of the best implementations of dynamic character controller
+you can find (as it can be seen in the 2d/platformer demo), but using
+it requieres a considerable level of skill and understanding of
+physics engines (or a lot of patience with trial and error).
+
+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?:
 
@@ -84,10 +85,11 @@ radius) of the shape instead of scaling it. The same is also true for
 the kinematic/rigid/static bodies themselves, as their scale affect the
 shape scale.**
 
-| Now create a script for the character, the one used as an example
-  above should work as a base.
-| Finally, instance that character scene in the tilemap, and make the
-  map scene the main one, so it runs when pressing play.
+Now create a script for the character, the one used as an example
+above should work as a base.
+
+Finally, instance that character scene in the tilemap, and make the
+map scene the main one, so it runs when pressing play.
 
 .. image:: /img/kbinstance.png
 
@@ -115,10 +117,11 @@ So, let's move our sprite downwards until it hits the floor:
     func _ready():
         set_fixed_process(true)
 
-| The result is that the character will move, but stop right when
-  hitting the floor. Pretty cool, huh?
-| The next step will be adding gravity to the mix, this way it behaves a
-  little more like an actual game character:
+The result is that the character will move, but stop right when
+hitting the floor. Pretty cool, huh?
+
+The next step will be adding gravity to the mix, this way it behaves a
+little more like an actual game character:
 
 ::
 
@@ -203,12 +206,13 @@ So what we want to do is this:
 
 .. image:: /img/motion_reflect.png
 
-| When colliding, the function move() returns the "remainder" of the
-  motion vector. That means, if the motion vector is 40 pixels, but
-  collision happened at 10 pixels, the same vector but 30 pixels long is
-  returned.
-| The correct way to solve the motion is, then, to slide by the normal
-  this way:
+When colliding, the function move() returns the "remainder" of the
+motion vector. That means, if the motion vector is 40 pixels, but
+collision happened at 10 pixels, the same vector but 30 pixels long is
+returned.
+
+The correct way to solve the motion is, then, to slide by the normal
+this way:
 
 ::
 
@@ -236,9 +240,10 @@ So what we want to do is this:
     func _ready():
         set_fixed_process(true)
 
-| Note that not only the motion has been modified but also the velocity.
-  This makes sense as it helps keep
-| the new direction too.
+Note that not only the motion has been modified but also the velocity.
+This makes sense as it helps keep
+
+the new direction too.
 
 The normal can also be used to detect that the character is on floor, by
 checking the angle. If the normal points up (or at least, within a

tutorials/2d/particle_systems_2d.rst

@@ -142,12 +142,13 @@ Determines the intial and final scales of the particle.
 Color Phases
 ------------
 
-| Particles can use up to 4 color phases. Each color phase can include
-  transparency.
-| Phases must provide an offset value from 0 to 1, and alays in
-  ascending order. For example, a color will begin at offset 0 and end
-  in offset 1, but 4 colors might use diferent offsets, such as 0, 0.2,
-  0.8 and 1.0 for the different phases:
+Particles can use up to 4 color phases. Each color phase can include
+transparency.
+
+Phases must provide an offset value from 0 to 1, and alays in
+ascending order. For example, a color will begin at offset 0 and end
+in offset 1, but 4 colors might use diferent offsets, such as 0, 0.2,
+0.8 and 1.0 for the different phases:
 
 .. image:: /img/particlecolorphases.png
 

tutorials/2d/physics_introduction.rst

@@ -313,10 +313,12 @@ Area2D
 
 Areas in Godot physics have three main roles:
 
-| 1. Override the space parameters for objects entering them (ie.
-  gravity, gravity direction, gravity type, density, etc).
-| 2. Monitor when rigid or kinematic bodies enter or exit the area.
-| 3. Monitor other areas (this is the simplest way to get overlap test)
+1. Override the space parameters for objects entering them (ie.
+gravity, gravity direction, gravity type, density, etc).
+
+2. Monitor when rigid or kinematic bodies enter or exit the area.
+
+3. Monitor other areas (this is the simplest way to get overlap test)
 
 The second function is the most common. For it to work, the "monitoring"
 property must be enabled (it is by default). There are two types of
@@ -398,9 +400,10 @@ server must be used directly. For this, the
 :ref:`Physics2DDirectspaceState <class_Physics2DDirectspaceState>`
 class must be used. To obtain it, the following steps must be taken:
 
-| 1. It must be used inside the \_fixed\_process() callback, or at
-  \_integrate\_forces()
-| 2. The 2D RIDs for the space and physics server must be obtained.
+1. It must be used inside the \_fixed\_process() callback, or at
+\_integrate\_forces()
+
+2. The 2D RIDs for the space and physics server must be obtained.
 
 The following code should work:
 
@@ -424,15 +427,20 @@ and with other areas. The following table should make it more visual:
 In case of overlap, who receives collision information?
 -------------------------------------------------------
 
-| \|\ *. Type \|*. RigidBody \|\ *. CharacterBody \|*. KinematicBody
-  \|\ *. StaticBody \|*. Area \|
-| \| **RigidBody** \| Both \| Both \| Both \| Rigidbody \| Area \|
-| \| **CharacterBody** \| Both \| Both \| Both \| CharacterBody \| Area
-  \|
-| \| **KinematicBody** \| Both \| Both \| None \| None \| Area \|
-| \| **StaticBody** \| RigidBody \| CharacterBody \| None \| None \|
-  None \|
-| \| **Area** \| Area \| Area \| Area \| None \| Both \|
+\|\ *. Type \|*. RigidBody \|\ *. CharacterBody \|*. KinematicBody
+\|\ *. StaticBody \|*. Area \|
+
+\| **RigidBody** \| Both \| Both \| Both \| Rigidbody \| Area \|
+
+\| **CharacterBody** \| Both \| Both \| Both \| CharacterBody \| Area
+\|
+
+\| **KinematicBody** \| Both \| Both \| None \| None \| Area \|
+
+\| **StaticBody** \| RigidBody \| CharacterBody \| None \| None \|
+None \|
+
+\| **Area** \| Area \| Area \| Area \| None \| Both \|
 
 
 

tutorials/2d/screen-reading_shaders.rst

@@ -59,14 +59,15 @@ and saturation:
 Behind The Scenes
 ~~~~~~~~~~~~~~~~~
 
-| While this seems magical, it's not. The Texscreen instruction, 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 texscreen() in
-  shaders will not have the screen copied for them, because this ends up
-  being very inefficient.
-| As a result, if shaders that use texscreen() overlap, the second one
-  will not use the result of the first one, resulting in unexpected
-  visuals:
+While this seems magical, it's not. The Texscreen instruction, 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 texscreen() in
+shaders will not have the screen copied for them, because this ends up
+being very inefficient.
+
+As a result, if shaders that use texscreen() overlap, the second one
+will not use the result of the first one, resulting in unexpected
+visuals:
 
 .. image:: /img/texscreen_demo1.png
 

tutorials/2d/viewport_and_canvas_transforms.rst

@@ -63,16 +63,19 @@ Transform Functions
 
 Obtaining each transform can be achieved with the following functions:
 
-| \|Type: \| Transform\|
-| \|CanvasItem \|
-  :ref:`CanvasItem.get_global_transform() <class_CanvasItem_get_global_transform>`
-  \|
-| \|CanvasLayer\|
-  :ref:`CanvasItem.get_canvas_transform() <class_CanvasItem_get_canvas_transform>`
-  \|
-| \|CanvasLayer+GlobalCanvas+Stretch \|
-  :ref:`CanvasItem.get_viewport_transform() <class_CanvasItem_get_viewport_transform>`
-  \|
+\|Type: \| Transform\|
+
+\|CanvasItem \|
+:ref:`CanvasItem.get_global_transform() <class_CanvasItem_get_global_transform>`
+\|
+
+\|CanvasLayer\|
+:ref:`CanvasItem.get_canvas_transform() <class_CanvasItem_get_canvas_transform>`
+\|
+
+\|CanvasLayer+GlobalCanvas+Stretch \|
+:ref:`CanvasItem.get_viewport_transform() <class_CanvasItem_get_viewport_transform>`
+\|
 
 Finally then, to convert a CanvasItem local coordinates to screen
 coordinates, just multiply in the following order:

tutorials/3d/3d_performance_and_limitations.rst

@@ -77,8 +77,9 @@ many factors.
 On a modern PC and consoles, vertex cost is low. Very low. GPUs
 originally only rendered triangles, so all the vertices:
 
-| 1. Had to be transformed by the CPU (including clipping).
-| 1. Had to be sent to the GPU memory from the main RAM.
+1. Had to be transformed by the CPU (including clipping).
+
+1. Had to be sent to the GPU memory from the main RAM.
 
 Nowadays, all this is handled inside the GPU, so the performance is
 extremely high. 3D artists usually have the wrong feeling about
@@ -132,11 +133,12 @@ have extra processing per vertex, such as:
 Texture Compression
 -------------------
 
-| Godot offers to compress textures of 3D models when imported (VRAM
-  compression). Video Ram compression is not as efficient in size as PNG
-  or JPG when stored, but increase performance enormously when drawing.
-| This is because the main goal of texture compression is bandwidth
-  reduction between memory and the GPU.
+Godot offers to compress textures of 3D models when imported (VRAM
+compression). Video Ram compression is not as efficient in size as PNG
+or JPG when stored, but increase performance enormously when drawing.
+
+This is because the main goal of texture compression is bandwidth
+reduction between memory and the GPU.
 
 In 3D, the shapes of objects depend more on the geometry than the
 texture, so compression is generally not noticeable. In 2D, compression

tutorials/3d/fixed_materials.rst

@@ -62,13 +62,14 @@ points. This feature is mostly used in tools and HUDs
 Discard Alpha
 ~~~~~~~~~~~~~
 
-| When alpha is enabled (see above) the invisible pixels are blended
-  with what is behind them. In some combinations (of using alpha to
-  render depth) it may be possible that invisible pixels cover other
-  objects.
-| If this is the case, enable this option for the material. This option
-  is often used in combination with "opaque pre-pass" hint (see the
-  :ref:`doc_materials` tutorial for more information).
+When alpha is enabled (see above) the invisible pixels are blended
+with what is behind them. In some combinations (of using alpha to
+render depth) it may be possible that invisible pixels cover other
+objects.
+
+If this is the case, enable this option for the material. This option
+is often used in combination with "opaque pre-pass" hint (see the
+:ref:`doc_materials` tutorial for more information).
 
 Parameters
 ----------

tutorials/3d/high_dynamic_range.rst

@@ -15,14 +15,15 @@ So where does all this HDR stuff thing come from? The idea is that
 instead of dealing with colors that go from black to white (0 to 1), we
 use colors whiter than white (for example, 0 to 8 times white).
 
-| To be more practical, imagine that in a regular scene, the intensity
-  of a light (generally 1.0) is set to 5.0. The whole scene will turn
-  very bright (towards white) and look horrible.
-| After this the luminance of the scene is computed by averaging the
-  luminance of every pixel of it, and this value is used to bring the
-  scene back to normal ranges. This last operation is called
-  tone-mapping. Finally, we are at a similar place from where we
-  started:
+To be more practical, imagine that in a regular scene, the intensity
+of a light (generally 1.0) is set to 5.0. The whole scene will turn
+very bright (towards white) and look horrible.
+
+After this the luminance of the scene is computed by averaging the
+luminance of every pixel of it, and this value is used to bring the
+scene back to normal ranges. This last operation is called
+tone-mapping. Finally, we are at a similar place from where we
+started:
 
 .. image:: /img/hdr_tonemap.png
 
@@ -40,14 +41,15 @@ realistic light bleeding effects in the scene.
 Linear Color Space
 ------------------
 
-| The problem with this technique is that computer monitors apply a
-  gamma curve to adapt better to the way the human eye sees. Artists
-  create their art on the screen too, so their art has an implicit gamma
-  curve applied to it.
-| The color space where images created in computer monitors exist is
-  called "sRGB". Every visual content that people has on their computers
-  or downloads from the internet (such as pictures, movies, porn, etc)
-  is in this colorspace.
+The problem with this technique is that computer monitors apply a
+gamma curve to adapt better to the way the human eye sees. Artists
+create their art on the screen too, so their art has an implicit gamma
+curve applied to it.
+
+The color space where images created in computer monitors exist is
+called "sRGB". Every visual content that people has on their computers
+or downloads from the internet (such as pictures, movies, porn, etc)
+is in this colorspace.
 
 .. image:: /img/hdr_gamma.png
 

tutorials/3d/importing_3d_scenes.rst

@@ -60,11 +60,12 @@ with the latest version of the software.
 Exporting DAE files from Blender
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-| Blender also has built-in collada support, but It's really broken and
-  should not be used either.
-| Godot provides a `Python
-  Plugin <https://github.com/okamstudio/godot/tree/master/tools/export/blender25>`__
-  that will do a much better job at exporting the scenes.
+Blender also has built-in collada support, but It's really broken and
+should not be used either.
+
+Godot provides a `Python
+Plugin <https://github.com/okamstudio/godot/tree/master/tools/export/blender25>`__
+that will do a much better job at exporting the scenes.
 
 The import process
 ------------------

tutorials/3d/inverse_kinematics.rst

@@ -1,8 +1,9 @@
 .. _doc_inverse_kinematics:
 
-| Before continuing on, I'd recommend reading some theory, the simplest
-  article I find is this:
-| http://freespace.virgin.net/hugo.elias/models/m\_ik2.htm
+Before continuing on, I'd recommend reading some theory, the simplest
+article I find is this:
+
+http://freespace.virgin.net/hugo.elias/models/m\_ik2.htm
 
 Initial problem
 ~~~~~~~~~~~~~~~

tutorials/3d/lighting.rst

@@ -73,12 +73,13 @@ lamps or any other light source that comes from a point.
 
 .. image:: /img/light_omni.png
 
-| The attenuation curve for these kind of lights in nature is computed
-  with an inverse-quadratic function that never reaches zero and has
-  almost infinitely large values near the emissor.
-| This makes them considerably inconvenient to tweak for artists, so
-  Godot simulates them with an artist-controlled exponential curve
-  instead.
+The attenuation curve for these kind of lights in nature is computed
+with an inverse-quadratic function that never reaches zero and has
+almost infinitely large values near the emissor.
+
+This makes them considerably inconvenient to tweak for artists, so
+Godot simulates them with an artist-controlled exponential curve
+instead.
 
 .. image:: /img/light_attenuation.png
 

tutorials/3d/materials.rst

@@ -6,14 +6,15 @@ Materials
 Introduction
 ------------
 
-| Materials can be applied to most visible 3D objects, they basically
-  are a description to how light reacts to that object. There are many
-  types of materials, but the main ones are the
-  :ref:`FixedMaterial <class_FixedMaterial>`
-  and
-  :ref:`ShaderMaterial <class_ShaderMaterial>`.
-  Tutorials for each of them exist :ref:`doc_fixed_materials` and :ref:`doc_shader_materials`.
-| This tutorial is about the basic properties shared between them.
+Materials can be applied to most visible 3D objects, they basically
+are a description to how light reacts to that object. There are many
+types of materials, but the main ones are the
+:ref:`FixedMaterial <class_FixedMaterial>`
+and
+:ref:`ShaderMaterial <class_ShaderMaterial>`.
+Tutorials for each of them exist :ref:`doc_fixed_materials` and :ref:`doc_shader_materials`.
+
+This tutorial is about the basic properties shared between them.
 
 .. image:: /img/material_flags.png
 
@@ -32,15 +33,16 @@ not be shown.
 Double Sided & Invert Faces
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-| Godot by default only shows geometry faces (triangles) when facing the
-  camera. To do this it needs them to be in view in clockwise order.
-  This saves a lot of GPU power by ensuring that not visible triangles
-  are not drawn.
-| Some flat objects might need to be drawn all the times though, for
-  this the "double sided" flag will make sure that no matter the facing,
-  the triangle will always be drawn. It is also possible to invert this
-  check and draw counter-clockwise looking faces too, though it's not
-  very useful except for a few cases (like drawing outlines).
+Godot by default only shows geometry faces (triangles) when facing the
+camera. To do this it needs them to be in view in clockwise order.
+This saves a lot of GPU power by ensuring that not visible triangles
+are not drawn.
+
+Some flat objects might need to be drawn all the times though, for
+this the "double sided" flag will make sure that no matter the facing,
+the triangle will always be drawn. It is also possible to invert this
+check and draw counter-clockwise looking faces too, though it's not
+very useful except for a few cases (like drawing outlines).
 
 Unshaded
 ~~~~~~~~

tutorials/3d/shadow_mapping.rst

@@ -6,13 +6,14 @@ Shadow Mapping
 Introduction
 ------------
 
-| Simply throwing a light is not enough to realistically illuminate a
-  scene. It should be, in theory, but given the way video hardware
-  works, parts of objects that should not be reached by light are lit
-  anyway.
-| Most people (including artists), see shadows as something projected by
-  light, as if they were created by the light itself by darkening places
-  that are hidden from the light source.
+Simply throwing a light is not enough to realistically illuminate a
+scene. It should be, in theory, but given the way video hardware
+works, parts of objects that should not be reached by light are lit
+anyway.
+
+Most people (including artists), see shadows as something projected by
+light, as if they were created by the light itself by darkening places
+that are hidden from the light source.
 
 This is actually not correct and it's important to understand that
 shadows are places where light simply does not reach. As a rule (and
@@ -131,12 +132,13 @@ increase the Z-Offset even more!
 
 .. image:: /img/shadow_offset_3.png
 
-| And it gets rid of those self-shadowings! hooray! except something is
-  wrong.. oh, right. Being pushed back too much, the shadows start
-  disconnecting from their casters, which looks pretty awful. Ok, you go
-  back to the previous Z-offset.
-| This is when Z-Slope-Scale comes to save the day. This setting makes
-  shadow caster objects thinner, so the borders don't self-shadow:
+And it gets rid of those self-shadowings! hooray! except something is
+wrong.. oh, right. Being pushed back too much, the shadows start
+disconnecting from their casters, which looks pretty awful. Ok, you go
+back to the previous Z-offset.
+
+This is when Z-Slope-Scale comes to save the day. This setting makes
+shadow caster objects thinner, so the borders don't self-shadow:
 
 .. image:: /img/shadow_offset_4.png
 
@@ -157,21 +159,23 @@ else.
 Important!
 ~~~~~~~~~~
 
-| If you are using shadow maps with directional lights, make sure that
-  the *view distance* of the *camera* is set to an *optimal range*. This
-  means, if the distance between your camera and the visible end of the
-  scene is 100, then set the view distance to that value. If a greater
-  than necessary value is used, the shadow maps will lose detail as they
-  will try to cover a bigger area.
-| So, always make sure to use the optimal range!
+If you are using shadow maps with directional lights, make sure that
+the *view distance* of the *camera* is set to an *optimal range*. This
+means, if the distance between your camera and the visible end of the
+scene is 100, then set the view distance to that value. If a greater
+than necessary value is used, the shadow maps will lose detail as they
+will try to cover a bigger area.
+
+So, always make sure to use the optimal range!
 
 Shadow Filtering
 ~~~~~~~~~~~~~~~~
 
-| Raw shadows are blocky. Increasing their resolution just makes smaller
-  blocks, but they are still blocks.
-| Godot offers a few ways to filter them (shadow in the example is
-  low-resolution on purpose!):
+Raw shadows are blocky. Increasing their resolution just makes smaller
+blocks, but they are still blocks.
+
+Godot offers a few ways to filter them (shadow in the example is
+low-resolution on purpose!):
 
 .. image:: /img/shadow_filter_options.png
 

tutorials/3d/working_with_3d_skeletons.rst

@@ -220,9 +220,10 @@ Create the following node tree:
     + DirectionLight (DirectionLight)
     + Camera
 
-| Set up Camera so that arm is properly visible. Rotate DirectionLight
-  so that arm is properly lit
-| while in scene play mode.
+Set up Camera so that arm is properly visible. Rotate DirectionLight
+so that arm is properly lit
+
+while in scene play mode.
 
 Now we need to create new script under main:
 
@@ -233,8 +234,9 @@ First we setup parameters:
     var lowerarm_angle = Vector3()
     var upperarm_angle = Vector3()
 
-| Now we need to setup way to change them. Just lets use keys for that.
-| Please create 7 actions under project settings:
+Now we need to setup way to change them. Just lets use keys for that.
+
+Please create 7 actions under project settings:
 
 -  **selext\_x** - bind to X key
 -  **selext\_y** - bind to Y key
@@ -323,19 +325,21 @@ The full code for arm control is this:
 Pressing keys 1/2 select upperarm/lowerarm, select axis by pressing x,
 y, z, rotate using numpad "+"/"-"
 
-| This way you fully control your arm in FK mode using 2 bones. You can
-  add additional bones and/or improve "feel" of the interface by using
-  coefficients for the change. I recommend you play with this example a
-  lot before going to next part.
-| You can clone the demo code for this chapter using
+This way you fully control your arm in FK mode using 2 bones. You can
+add additional bones and/or improve "feel" of the interface by using
+coefficients for the change. I recommend you play with this example a
+lot before going to next part.
+
+You can clone the demo code for this chapter using
 
 ::
 
     git clone [email protected]:slapin/godot-skel3d.git
     cd demo1
 
-| Or you can browse it using web-interface:
-| https://github.com/slapin/godot-skel3d
+Or you can browse it using web-interface:
+
+https://github.com/slapin/godot-skel3d
 
 Using 3D "bones" to implement Inverse Kinematics
 ------------------------------------------------

tutorials/asset_pipeline/import_process.rst

@@ -139,13 +139,14 @@ the screen.
 
 .. image:: /img/changes.png
 
-| From that moment onward, the user can choose to re-import at any given
-  time by clicking on the red-icon. When this action is done, a dialog
-  will pop-up showing which resources can be re-imported (all selected
-  by default).
-| Accepting that dialog will immediately re-import the resources and
-  will update any of them currently in use in the editor (like a
-  texture, model or audio file).
+From that moment onward, the user can choose to re-import at any given
+time by clicking on the red-icon. When this action is done, a dialog
+will pop-up showing which resources can be re-imported (all selected
+by default).
+
+Accepting that dialog will immediately re-import the resources and
+will update any of them currently in use in the editor (like a
+texture, model or audio file).
 
 .. image:: /img/changed.png
 

tutorials/engine/background_loading.rst

@@ -70,8 +70,9 @@ get\_stage\_count
 
    </pre>
 
-| returns the total number of stages to load
-| 
+returns the total number of stages to load
+
+
 
 .. raw:: html
 

tutorials/engine/internationalizing_a_game.rst

@@ -97,8 +97,9 @@ supplied:
 
    </pre>
 
-| c:\\\\MyGame> godot -lang fr
-| 
+c:\\\\MyGame> godot -lang fr
+
+
 
 .. raw:: html
 

tutorials/engine/paths.rst

@@ -6,29 +6,32 @@ Paths
 Path Separators
 ---------------
 
-| For the sake of supporting as many platforms as possible, Godot only
-  accepts unix style path separators (/). These work everywhere,
-  including Windows.
-| A path like: "C:\\\\Projects" will become "c:/Projects".
+For the sake of supporting as many platforms as possible, Godot only
+accepts unix style path separators (/). These work everywhere,
+including Windows.
+
+A path like: "C:\\\\Projects" will become "c:/Projects".
 
 Resource Path
 -------------
 
-| As mentioned before. Godot considers that a project exists at any
-  given folder that contains an "engine.cfg" text file, even if such
-  file is empty.
-| Accessing project files can be done by opening any path with "res://"
-  as a base. For example, a texture located in the root of the project
-  folder may be opened from the following path: "res://sometexture.png".
+As mentioned before. Godot considers that a project exists at any
+given folder that contains an "engine.cfg" text file, even if such
+file is empty.
+
+Accessing project files can be done by opening any path with "res://"
+as a base. For example, a texture located in the root of the project
+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
-  resource path will be read-only, due to it being inside a package,
-  self contained executable, or system wide install location.
-| Storing persistent files in such scenarios should be done by using the
-  "user://" prefix, for example: "user://gamesave.txt".
+While the project is running, it is a very 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.
+
+Storing persistent files in such scenarios should be done by using the
+"user://" prefix, for example: "user://gamesave.txt".
 
 In some devices (for example, mobile ad consoles) this path is unique
 for the app. Under desktop operating systems, the engine uses the

tutorials/http_client_class.rst

@@ -11,9 +11,11 @@ class. It's just a script, so it can be run by executing:
 
    </pre>
 
-| c
-| c:\\\\godot> godot -s http\_test.gd
-| 
+c
+
+c:\\\\godot> godot -s http\_test.gd
+
+
 
 .. raw:: html
 

tutorials/matrices_and_transforms.rst

@@ -9,10 +9,11 @@ Introduction
 Before reading this tutorial, it is advised to read the previous one
 about :ref:`doc_vector_math` as this one is a direct continuation.
 
-| This tutorial will be about *transformations* and will cover a little
-  about matrices (but not in-depth).
-| Transformations are most of the time applied as translation, rotation
-  and scale so they will be considered as priority here.
+This tutorial will be about *transformations* and will cover a little
+about matrices (but not in-depth).
+
+Transformations are most of the time applied as translation, rotation
+and scale so they will be considered as priority here.
 
 Oriented Coordinate System (OCS)
 --------------------------------
@@ -26,18 +27,20 @@ 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).
 
-| We should realize that at some point, someone *designed* this
-  spaceship. Be it for 2D in a drawing such as Paint.net, Gimp,
-  Photoshop, etc. or in 3D through a 3D DCC tool such as Blender, Max,
-  Maya, etc.
-| When it was designed, it was not rotated. It was designed in it's own
-  *coordinate system*.
+We should realize that at some point, someone *designed* this
+spaceship. Be it for 2D in a drawing such as Paint.net, Gimp,
+Photoshop, etc. or in 3D through a 3D DCC tool such as Blender, Max,
+Maya, etc.
+
+When it was designed, it was not rotated. It was designed in it's own
+*coordinate system*.
 
 .. image:: /img/tutomat2.png
 
-| This means that the tip of the ship has a coordinate, the fin has
-  another, etc. Be it in pixels (2D) or vertices (3D).
-| So, let's recall again that the ship was somewhere in space:
+This means that the tip of the ship has a coordinate, the fin has
+another, etc. Be it in pixels (2D) or vertices (3D).
+
+So, let's recall again that the ship was somewhere in space:
 
 .. image:: /img/tutomat3.png
 
@@ -95,14 +98,15 @@ position!
 
 .. image:: /img/tutomat9.png
 
-| How did this black magic happen? The ship was lost in space, and now
-  it's back home!
-| It might seem strange, but it does have plenty of logic. Remember, as
-  we have seen in the :ref:`doc_vector_math`, what
-  happened is that the distance to X axis, and the distance to Y axis
-  were computed. Calculating distance in a direction or plane was one of
-  the uses for the dot product. This was enough to obtain back the
-  design coordinates for every point in the ship.
+How did this black magic happen? The ship was lost in space, and now
+it's back home!
+
+It might seem strange, but it does have plenty of logic. Remember, as
+we have seen in the :ref:`doc_vector_math`, what
+happened is that the distance to X axis, and the distance to Y axis
+were computed. Calculating distance in a direction or plane was one of
+the uses for the dot product. This was enough to obtain back the
+design coordinates for every point in the ship.
 
 So, what he have been working with so far (with X, Y and Origin) is an
 *Oriented Coordinate System\*. X an Y are the **Basis**, and \*Origin*
@@ -203,11 +207,12 @@ the origin:
 
 .. image:: /img/tutomat13.png
 
-| This will always work in global coordinates.
-| If instead, translation is desired in *local* coordinates of the
-  matrix (towards where the *basis* is oriented), there is the
-  :ref:`Matrix32.translated() <class_Matrix32_translated>`
-  method:
+This will always work in global coordinates.
+
+If instead, translation is desired in *local* coordinates of the
+matrix (towards where the *basis* is oriented), there is the
+:ref:`Matrix32.translated() <class_Matrix32_translated>`
+method:
 
 ::
 
@@ -292,11 +297,12 @@ Or pre-multiplication:
 Orthonormal Matrices
 --------------------
 
-| However, if the Matrix has been scaled (vectors are not unit length),
-  or the basis vectors are not orthogonal (90°), the inverse transform
-  will not work.
-| In other words, inverse transform is only valid in *orthonormal*
-  matrices. For this, these cases an affine inverse must be computed.
+However, if the Matrix has been scaled (vectors are not unit length),
+or the basis vectors are not orthogonal (90°), the inverse transform
+will not work.
+
+In other words, inverse transform is only valid in *orthonormal*
+matrices. For this, these cases an affine inverse must be computed.
 
 The transform, or inverse transform of an identity matrix will return
 the position unchanged:
@@ -333,10 +339,11 @@ If the matrix is orthonormal, then:
 Matrix Multiplication
 ---------------------
 
-| Matrices can be multiplied. Multiplication of two matrices "chains"
-  (concatenates) their transforms.
-| However, as per convention, multiplication takes place in reverse
-  order.
+Matrices can be multiplied. Multiplication of two matrices "chains"
+(concatenates) their transforms.
+
+However, as per convention, multiplication takes place in reverse
+order.
 
 Example:
 

tutorials/mesh_generation_with_heightmap_and_shaders.rst

@@ -6,10 +6,11 @@ Mesh generation with heightmap and shaders
 Introduction
 ------------
 
-| This tutorial will help you to use Godot shaders to deform a plane
-  mesh so it appears like a basic terrain. Remember that this solution
-  has pros and cons.
-| Pros:
+This tutorial will help you to use Godot shaders to deform a plane
+mesh so it appears like a basic terrain. Remember that this solution
+has pros and cons.
+
+Pros:
 
 -  Pretty easy to do.
 -  This approach allows computation of LOD terrains.
@@ -34,101 +35,138 @@ editor you like.
 The heightmap
 -------------
 
-| We will use a few functions of GIMP image editor to produce a simple
-  heightmap. Start GIMP and create a square image of 512x512 pixels.
-| |image0|
-| You are now in front of a new, blank, square image.
-| |image1|
-| Then, use a filter to render some clouds on this new image.
-| |image2|
-| Parameter this filter to whatever you want. A white pixel corresponds
-  to the highest point of the heightmap, a black pixel corresponds to
-  the lowest one. So, darker regions are valleys and brighter are
-  mountains. If you want, you can check "tileable" to render a heightmap
-  that can be cloned and tiled close together with another one. X and Y
-  size don't matter a lot as long as they are big enough to provide a
-  decent ground. A value of 4.0 or 5.0 for both is nice. Click on the
-  "New Seed" button to roll a dice and GIMP will create a new random
-  heightmap. Once you are happy with the result, click "OK".
-| |image3|
-| You can continue to edit your image if you wish. For our example,
-  let's keep the heightmap as is, and let's export it to a PNG file, say
-  "heightmap.png". Save it in your Godot project folder.
+We will use a few functions of GIMP image editor to produce a simple
+heightmap. Start GIMP and create a square image of 512x512 pixels.
+
+|image0|
+
+You are now in front of a new, blank, square image.
+
+|image1|
+
+Then, use a filter to render some clouds on this new image.
+
+|image2|
+
+Parameter this filter to whatever you want. A white pixel corresponds
+to the highest point of the heightmap, a black pixel corresponds to
+the lowest one. So, darker regions are valleys and brighter are
+mountains. If you want, you can check "tileable" to render a heightmap
+that can be cloned and tiled close together with another one. X and Y
+size don't matter a lot as long as they are big enough to provide a
+decent ground. A value of 4.0 or 5.0 for both is nice. Click on the
+"New Seed" button to roll a dice and GIMP will create a new random
+heightmap. Once you are happy with the result, click "OK".
+
+|image3|
+
+You can continue to edit your image if you wish. For our example,
+let's keep the heightmap as is, and let's export it to a PNG file, say
+"heightmap.png". Save it in your Godot project folder.
 
 The plane mesh
 --------------
 
-| Now, we will need a plane mesh to import in Godot. Let's run Blender.
-| |image4|
-| Remove the start cube mesh, then add a new plane to the scene.
-| |image5|
-| Zoom a bit, then switch to Edit mode (Tab key) and in the Tools
-  buttongroup at the left, hit "Subdivide" 5 or 6 times.
-| |image6|
-| Your mesh is now subdivided, which means we added vertices to the
-  plane mesh that we will later be able to move. Job's not finished yet:
-  in order to texture this mesh a proper UV map is necessary. Currently,
-  the default UV map contains only the 4 corner vertices we had at the
-  beginning. However, we now have more, and we want to be able to
-  texture over the whole mesh correctly.
-
-| If all the vertices of your mesh are not selected, select them all
-  (hit "A"). They must appear orange, not black. Then, in the
-  Shading/UVs button group a the left, click the "Unwrap" button (or
-  simply hit "U") and select "Smart UV Project". Keep the default
-  options and hit "Ok".
-| |image7|
-| Now, we need to switch our view to "UV/Image editor".
-| |image8|
-| Select all the vertices again ("A") then in the UV button, select
-  "Export UV Layout".
-| |image9|
-| Export the layout as a PNG file. Name it "plane.png" and save it in
-  your Godot project folder. Now, let's export our mesh as an OBJ file.
-  Top of the screen, click "File/Export/Wavefront (obj)". Save your
-  object as "plane.obj" in your Godot project folder.
+Now, we will need a plane mesh to import in Godot. Let's run Blender.
+
+|image4|
+
+Remove the start cube mesh, then add a new plane to the scene.
+
+|image5|
+
+Zoom a bit, then switch to Edit mode (Tab key) and in the Tools
+buttongroup at the left, hit "Subdivide" 5 or 6 times.
+
+|image6|
+
+Your mesh is now subdivided, which means we added vertices to the
+plane mesh that we will later be able to move. Job's not finished yet:
+in order to texture this mesh a proper UV map is necessary. Currently,
+the default UV map contains only the 4 corner vertices we had at the
+beginning. However, we now have more, and we want to be able to
+texture over the whole mesh correctly.
+
+If all the vertices of your mesh are not selected, select them all
+(hit "A"). They must appear orange, not black. Then, in the
+Shading/UVs button group a the left, click the "Unwrap" button (or
+simply hit "U") and select "Smart UV Project". Keep the default
+options and hit "Ok".
+
+|image7|
+
+Now, we need to switch our view to "UV/Image editor".
+
+|image8|
+
+Select all the vertices again ("A") then in the UV button, select
+"Export UV Layout".
+
+|image9|
+
+Export the layout as a PNG file. Name it "plane.png" and save it in
+your Godot project folder. Now, let's export our mesh as an OBJ file.
+Top of the screen, click "File/Export/Wavefront (obj)". Save your
+object as "plane.obj" in your Godot project folder.
 
 Shader magic
 ------------
 
-| Let's now open Godot Editor.
-| Create a new project in the folder you previously created and name it
-  what you want.
-| |image10|
-| In our default scene (3D), create a root node "Spatial". Next, import
-  the mesh OBJ file. Click "Import", choose "3D Mesh" and select your
-  plane.obj file, set the target path as "/" (or wherever you want in
-  your project folder).
-| |image11|
-| I like to check "Normals" in the import popup so the import will also
-  consider faces normals, which can be useful (even if we don't use them
-  in this tutorial). Your mesh is now displayed in the FileSystem in
-  "res://".
-| |image12|
-| Create a MeshInstance node. In the Inspector, load the mesh we just
-  imported. Select "plane.msh" and hit ok.
-| |image13|
-| Great! Our plane is now rendered in the 3D view.
-| |image14|
-| It is time to add some shader stuff. In the Inspector, in the
-  "Material Override" line, add a "New ShaderMaterial". Edit it by
-  clicking the ">" button just right to it.
-| |image15|
-| You have two ways to create a shader: by code (MaterialShader), or
-  using a shader graph (MaterialShaderGraph). The second one is a bit
-  more visual, but we will not cover it for now. Create a "New
-  MaterialShader".
-| |image16|
-| Edit it by clicking the ">" button just right to it. The Shaders
-  editor opens.
-| |image17|
-| The Vertex tab is for the Vertex shader, and the Fragment tab is for
-  the Fragment shader. No need to explain what both of them do, right?
-  If so, head to the :ref:`doc_shading_language` page. Else, let's start with the
-  Fragment shader. This one is used to texture the plane using an image.
-  For this example, we will texture it with the heightmap image itself,
-  so we'll actually see mountains as brighter regions and canyons as
-  darker regions. Use this code:
+Let's now open Godot Editor.
+
+Create a new project in the folder you previously created and name it
+what you want.
+
+|image10|
+
+In our default scene (3D), create a root node "Spatial". Next, import
+the mesh OBJ file. Click "Import", choose "3D Mesh" and select your
+plane.obj file, set the target path as "/" (or wherever you want in
+your project folder).
+
+|image11|
+
+I like to check "Normals" in the import popup so the import will also
+consider faces normals, which can be useful (even if we don't use them
+in this tutorial). Your mesh is now displayed in the FileSystem in
+"res://".
+
+|image12|
+
+Create a MeshInstance node. In the Inspector, load the mesh we just
+imported. Select "plane.msh" and hit ok.
+
+|image13|
+
+Great! Our plane is now rendered in the 3D view.
+
+|image14|
+
+It is time to add some shader stuff. In the Inspector, in the
+"Material Override" line, add a "New ShaderMaterial". Edit it by
+clicking the ">" button just right to it.
+
+|image15|
+
+You have two ways to create a shader: by code (MaterialShader), or
+using a shader graph (MaterialShaderGraph). The second one is a bit
+more visual, but we will not cover it for now. Create a "New
+MaterialShader".
+
+|image16|
+
+Edit it by clicking the ">" button just right to it. The Shaders
+editor opens.
+
+|image17|
+
+The Vertex tab is for the Vertex shader, and the Fragment tab is for
+the Fragment shader. No need to explain what both of them do, right?
+If so, head to the :ref:`doc_shading_language` page. Else, let's start with the
+Fragment shader. This one is used to texture the plane using an image.
+For this example, we will texture it with the heightmap image itself,
+so we'll actually see mountains as brighter regions and canyons as
+darker regions. Use this code:
 
 ::
 
@@ -151,19 +189,23 @@ outside the shader ("uniform"):
    before. The color ``col`` is actually not necessary to display the
    texture, but it is interesting to play and see how it does, right?
 
-| However, the plane is displayed black! This is because we didn't set
-  the texture file and the color to use.
-| |image18|
-| In the Inspector, click the "Previous" button to get back to the
-  ShaderMaterial. This is where you want to set the texture and the
-  color. In "Source", click "Load" and select the texture file
-  "heightmap.png". But the mesh is still black! This is because our
-  Fragment shader multiplies each pixel value of the texture by the
-  ``col`` parameter. However, this color is currently set to black
-  (0,0,0), and as you know, 0\*x = 0 ;) . Just change the ``col``
-  parameter to another color to see your texture appear:
-| |image19|
-| Good. Now, the Vertex Shader.
+However, the plane is displayed black! This is because we didn't set
+the texture file and the color to use.
+
+|image18|
+
+In the Inspector, click the "Previous" button to get back to the
+ShaderMaterial. This is where you want to set the texture and the
+color. In "Source", click "Load" and select the texture file
+"heightmap.png". But the mesh is still black! This is because our
+Fragment shader multiplies each pixel value of the texture by the
+``col`` parameter. However, this color is currently set to black
+(0,0,0), and as you know, 0\*x = 0 ;) . Just change the ``col``
+parameter to another color to see your texture appear:
+
+|image19|
+
+Good. Now, the Vertex Shader.
 
 The Vertex Shader is the first shader to be executed by the pipeline. It
 deals with vertices.
@@ -179,30 +221,35 @@ Click the "Vertex" tab to switch, and paste this code:
     VERTEX = vec3(xz.x, h, xz.y);
     VERTEX = MODELVIEW_MATRIX *  VERTEX;
 
-| This shader uses two "uniform" parameters. The ``source`` parameter is
-  already set for the fragment shader. Thus, the same image will be used
-  in this shader as the heightmap. The ``height_range`` parameter is a
-  parameter that we will use to increase the height effect.
-| At line 3, we save the x and z position of the SRC\_VERTEX, because we
-  do not want them to change : the plane must remain square. Remember
-  that Y axis corresponds to the "altitude", which is the only one we
-  want to change with the heightmap.
-| At line 4, we compute an ``h`` variable by multiplying the pixel value
-  at the UV position and the ``height_range``. As the heightmap is a
-  greyscale image, all r, g and b channels contain the same value. I
-  used ``g``, but any of r, g and b have the same effect.
-| At line 5, we set the current vertex' position at (xz.x, h, xz.y)
-  position. Concerning xz.y remember that its type is "vec2". Thus, its
-  components are x and y. The y component simply contains the z position
-  we set at line 3.
-| Finally, at line 6, we multiply the vertex by the model/view matrix in
-  order to set its position according to camera position. If you try to
-  comment this line, you'll see that the mesh behaves weird as you move
-  and rotate the camera.
-
-| That's all good, but our plane remains flat. This is because the
-  ``height_range`` value is 0. Increase this value to observe the mesh
-  distort and take to form of the terrain we set before:
-| |image20|
+This shader uses two "uniform" parameters. The ``source`` parameter is
+already set for the fragment shader. Thus, the same image will be used
+in this shader as the heightmap. The ``height_range`` parameter is a
+parameter that we will use to increase the height effect.
+
+At line 3, we save the x and z position of the SRC\_VERTEX, because we
+do not want them to change : the plane must remain square. Remember
+that Y axis corresponds to the "altitude", which is the only one we
+want to change with the heightmap.
+
+At line 4, we compute an ``h`` variable by multiplying the pixel value
+at the UV position and the ``height_range``. As the heightmap is a
+greyscale image, all r, g and b channels contain the same value. I
+used ``g``, but any of r, g and b have the same effect.
+
+At line 5, we set the current vertex' position at (xz.x, h, xz.y)
+position. Concerning xz.y remember that its type is "vec2". Thus, its
+components are x and y. The y component simply contains the z position
+we set at line 3.
+
+Finally, at line 6, we multiply the vertex by the model/view matrix in
+order to set its position according to camera position. If you try to
+comment this line, you'll see that the mesh behaves weird as you move
+and rotate the camera.
+
+That's all good, but our plane remains flat. This is because the
+``height_range`` value is 0. Increase this value to observe the mesh
+distort and take to form of the terrain we set before:
+
+|image20|
 
 

tutorials/ray-casting.rst

@@ -6,10 +6,11 @@ Physics Ray Casting and Queries (2D and 3D)
 Introduction
 ~~~~~~~~~~~~
 
-| One of the most common tasks in game development is casting a ray (or
-  custom shaped object) and see what it hits. This enables complex
-  behaviors, AI, etc. to take place.
-| This tutorial will explain how to do this in 2D and 3D.
+One of the most common tasks in game development is casting a ray (or
+custom shaped object) and see what it hits. This enables complex
+behaviors, AI, etc. to take place.
+
+This tutorial will explain how to do this in 2D and 3D.
 
 Godot stores all the low level game information in servers, while the
 scene is just a frontend. As such, ray casting is generally a

tutorials/ssl_certificates.rst

@@ -44,13 +44,14 @@ certificates from a CA.
 Approach 2, CA Cert
 -------------------
 
-| The second approach consists of using a certificate authority (CA)
-  such as Verisign, Geotrust, etc. This is a more cumbersome process,
-  but it's more "official" and ensures your identity is clearly
-  represented.
-| Unless you are working with large companies or corporations, or need
-  to connect to someone else's servers (ie, connecting to Google or some
-  other REST API provider via HTTPS) this method is not as useful.
+The second approach consists of using a certificate authority (CA)
+such as Verisign, Geotrust, etc. This is a more cumbersome process,
+but it's more "official" and ensures your identity is clearly
+represented.
+
+Unless you are working with large companies or corporations, or need
+to connect to someone else's servers (ie, connecting to Google or some
+other REST API provider via HTTPS) this method is not as useful.
 
 Also, when using a CA issued cert, **you must enable domain
 validation**, to ensure the domain you are connecting to is the one

tutorials/step_by_step/animations.rst

@@ -56,12 +56,13 @@ property of any object* can be animated:
 Making the Logo Appear
 ----------------------
 
-| Next, the logo will appear from the top of the screen. After selecting
-  the animation player, the editor panel will stay visible until
-  manually hidden (or the animation node is erased). Taking advantage of
-  this, select the "logo" node and go to the "pos" property, move it up,
-  to position: 114,-400.
-| Once in this position, press the key button next to the property:
+Next, the logo will appear from the top of the screen. After selecting
+the animation player, the editor panel will stay visible until
+manually hidden (or the animation node is erased). Taking advantage of
+this, select the "logo" node and go to the "pos" property, move it up,
+to position: 114,-400.
+
+Once in this position, press the key button next to the property:
 
 .. image:: /img/keypress.png
 

tutorials/step_by_step/file_system.rst

@@ -35,11 +35,12 @@ the best to play along with SVN, Git, Mercurial, Perforce, etc.
 engine.cfg
 ----------
 
-| The mere existence of this file marks that there is a Godot project in
-  that directory and all sub-directories.
-| This file contains the project configuration in plain text, win.ini
-  style, though it will work to mark the existence of a project even if
-  the file is empty.
+The mere existence of this file marks that there is a Godot project in
+that directory and all sub-directories.
+
+This file contains the project configuration in plain text, win.ini
+style, though it will work to mark the existence of a project even if
+the file is empty.
 
 Example of a filesystem:
 

tutorials/step_by_step/gui_tutorial.rst

@@ -85,12 +85,13 @@ emit a "value\_changed" when dragged, etc.
 Custom Control Mini Tutorial
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-| Before going into more depth, creating a custom control will be a good
-  way to get the picture on how controls works, as they are not as
-  complex as it might seem.
-| Additionally, even though Godot comes with dozens of controls for
-  different purposes, it happens often that it's just easier to attain a
-  specific functionality by creating a new one.
+Before going into more depth, creating a custom control will be a good
+way to get the picture on how controls works, as they are not as
+complex as it might seem.
+
+Additionally, even though Godot comes with dozens of controls for
+different purposes, it happens often that it's just easier to attain a
+specific functionality by creating a new one.
 
 To begin, create a single-node scene. The node is of type "Control" and
 has a certain area of the screen in the 2D editor, like this:

tutorials/step_by_step/instancing.rst

@@ -51,8 +51,9 @@ This project contains two scenes "ball.scn" and "container.scn". The
 ball scene is just a ball with physics, while container scene has a
 nicely shaped collision, so balls can be thrown in there.
 
-| p=. |image4|
-| |image5|
+p=. |image4|
+
+|image5|
 
 Open the container scene, then select the root node:
 
@@ -62,9 +63,10 @@ Afterwards, push the '+' shaped button, this is the instancing button!
 
 .. image:: /img/continst.png
 
-| Select the ball scene (ball.scn), the ball should appear in the origin
-  (0,0), move it to around the center
-| of the scene, like this:
+Select the ball scene (ball.scn), the ball should appear in the origin
+(0,0), move it to around the center
+
+of the scene, like this:
 
 .. image:: /img/continstanced.png
 

tutorials/step_by_step/instancing_continued.rst

@@ -54,11 +54,12 @@ lots of assets and parts that interact:
 
 .. image:: /img/openworld_instancing.png
 
-| Make some rooms with furniture, then connect them. Make a house later,
-  and use those rooms are the interior.
-| The house can be part of a citadel, which has many houses. Finally the
-  citadel can be put on the world map terrain. Add also guards and other
-  NPCs to the citadel by previously creating their scenes.
+Make some rooms with furniture, then connect them. Make a house later,
+and use those rooms are the interior.
+
+The house can be part of a citadel, which has many houses. Finally the
+citadel can be put on the world map terrain. Add also guards and other
+NPCs to the citadel by previously creating their scenes.
 
 With Godot, games can grow as quickly as desired, as only more scenes
 have to be made and instanced. The editor UI is also designed to be

tutorials/step_by_step/resources.rst

@@ -12,11 +12,12 @@ and features of the engine are implemented through them. There is,
 though, another datatype that is equally as important. That is
 :ref:`Resource <class_Resource>`.
 
-| Where *Nodes* focus on behaviors, such as drawing a sprite, drawing a
-  3D model, physics, GUI controls, etc,
-| **Resources** are mere **data containers**. This means that they don't
-  do any action nor process any information. Resources just contain
-  data.
+Where *Nodes* focus on behaviors, such as drawing a sprite, drawing a
+3D model, physics, GUI controls, etc,
+
+**Resources** are mere **data containers**. This means that they don't
+do any action nor process any information. Resources just contain
+data.
 
 Examples of resources are
 :ref:`Texture <class_Texture>`,
@@ -50,13 +51,14 @@ To make it a litle more visual:
 External vs Built-In
 --------------------
 
-| The resource properties can reference resources in two ways,
-  *external* (on disk) or **built-in**.
-| To be more specific, here's a
-  :ref:`Texture <class_Texture>`
-  in a
-  :ref:`Sprite <class_Sprite>`
-  node:
+The resource properties can reference resources in two ways,
+*external* (on disk) or **built-in**.
+
+To be more specific, here's a
+:ref:`Texture <class_Texture>`
+in a
+:ref:`Sprite <class_Sprite>`
+node:
 
 .. image:: /img/spriteprop.png
 
@@ -117,16 +119,17 @@ must be used.
             var bullet = preload("res://bullet.scn").instance()
             add_child(bullet)                  
 
-| This method creates the nodes in hierarchy, configures them (sets all
-  the properties) and returns the root node of the scene, which can be
-  added to any other node.
-| The approach has several advantages. As the
-  :ref:`PackedScene.instance() <class_PackedScene_instance>`
-  function is pretty fast, adding extra content to the scene can be done
-  efficiently. New enemies, bullets, effects, etc can be added or
-  removed quickly, without having to load them again from disk each
-  time. It is important to remember that, as always, images, meshes, etc
-  are all shared between the scene instances.
+This method creates the nodes in hierarchy, configures them (sets all
+the properties) and returns the root node of the scene, which can be
+added to any other node.
+
+The approach has several advantages. As the
+:ref:`PackedScene.instance() <class_PackedScene_instance>`
+function is pretty fast, adding extra content to the scene can be done
+efficiently. New enemies, bullets, effects, etc can be added or
+removed quickly, without having to load them again from disk each
+time. It is important to remember that, as always, images, meshes, etc
+are all shared between the scene instances.
 
 Freeing Resources
 -----------------

tutorials/step_by_step/scene_tree.rst

@@ -6,11 +6,12 @@ SceneTree
 Introduction
 ------------
 
-| This is where things start getting abstract, but don't panic, as
-  there's not really more depth than this.
-| In previous tutorials, everything revolves around the concept of
-  Nodes, scenes are made of them, and they become active once they enter
-  the *Scene Tree*.
+This is where things start getting abstract, but don't panic, as
+there's not really more depth than this.
+
+In previous tutorials, everything revolves around the concept of
+Nodes, scenes are made of them, and they become active once they enter
+the *Scene Tree*.
 
 This deserves going a little more into depth. In fact, the scene system
 is not even a core component of Godot, as it is possible to skip it and
@@ -21,17 +22,18 @@ uses.
 MainLoop
 --------
 
-| The way Godot works internally is as follows. There is the the
-  :ref:`OS <class_OS>` class,
-  which is the only instance that runs at the beginning. Afterwards, all
-  drivers, servers, scripting languages, scene system, etc are loaded.
-| When initialization is complete,
-  :ref:`OS <class_OS>` needs to be
-  supplied a
-  :ref:`MainLoop <class_MainLoop>`
-  to run. Up to this point, all this is internals working (you can check
-  main/main.cpp file in the source code if you are ever interested to
-  see how this works internally).
+The way Godot works internally is as follows. There is the the
+:ref:`OS <class_OS>` class,
+which is the only instance that runs at the beginning. Afterwards, all
+drivers, servers, scripting languages, scene system, etc are loaded.
+
+When initialization is complete,
+:ref:`OS <class_OS>` needs to be
+supplied a
+:ref:`MainLoop <class_MainLoop>`
+to run. Up to this point, all this is internals working (you can check
+main/main.cpp file in the source code if you are ever interested to
+see how this works internally).
 
 The user program, or game, starts in the MainLoop. This class has a few
 methods, for initialization, idle (frame-syncronized callback), fixed
@@ -42,16 +44,18 @@ even make sense.
 SceneTree
 ---------
 
-| One of the ways to explain how Godot works, is that it's a high level
-  game engine over a low level middleware.
-| The scene system is the game engine, while the
-  :ref:`OS <class_OS>` and servers
-  are the low level API.
+One of the ways to explain how Godot works, is that it's a high level
+game engine over a low level middleware.
+
+The scene system is the game engine, while the
+:ref:`OS <class_OS>` and servers
+are the low level API.
 
-| In any case, the scene system provides it's own main loop to OS,
-  :ref:`SceneTree <class_SceneTree>`.
-| This is automatically instanced and set when running a scene, no need
-  to do any extra work.
+In any case, the scene system provides it's own main loop to OS,
+:ref:`SceneTree <class_SceneTree>`.
+
+This is automatically instanced and set when running a scene, no need
+to do any extra work.
 
 It's important to know that this class exists because it has a few
 important uses:
@@ -95,10 +99,11 @@ user. It's created automatically inside SceneTree.
 Scene Tree
 ----------
 
-| When a node is connected, directly or indirectly, to the root
-  viewport, it becomes part of the *Scene Tree*.
-| This means that, as explained in previous tutorials, will get the
-  \_enter\_tree() and \_ready() callbacks (as well as \_exit\_tree()).
+When a node is connected, directly or indirectly, to the root
+viewport, it becomes part of the *Scene Tree*.
+
+This means that, as explained in previous tutorials, will get the
+\_enter\_tree() and \_ready() callbacks (as well as \_exit\_tree()).
 
 .. image:: /img/activescene.png
 

tutorials/step_by_step/scenes_and_nodes.rst

@@ -37,9 +37,10 @@ game, it has the following characteristics:
 -  Can be extended (to have more functions).
 -  Can be added to other nodes as children.
 
-| p=. |image1|
-| The last one is very important. Nodes can have other nodes as
-  children. When arranged in this way, the nodes become a **tree**.
+p=. |image1|
+
+The last one is very 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
 tool for organizing the projects. Since different nodes have different
@@ -54,10 +55,11 @@ Scenes
 
 .. image:: /img/scene.png
 
-| Now that the existence of nodes has been defined, the next logical
-  step is to explain what a Scene is.
-| A scene is composed of a group of nodes organized hierarchically (in
-  tree fashion). It has the following properties:
+Now that the existence of nodes has been defined, the next logical
+step is to explain what a Scene is.
+
+A scene is composed of a group of nodes organized hierarchically (in
+tree fashion). It has the following properties:
 
 -  A scene always has only one root node.
 -  Scenes can be saved to disk and loaded back.
@@ -118,12 +120,13 @@ And finally, create the Label! A lot happens when Create is pressed:
 
 .. image:: /img/addedlabel.png
 
-| First of all, the scene is changed to the 2D editor (because Label is
-  a 2D Node type), and the Label appears, selected, at the top left
-  corner of the viewport.
-| The node appears in the scene tree editor (box in the top right
-  corner), and the label properties apear in the Inspector (box in the
-  bottom right corner).
+First of all, the scene is changed to the 2D editor (because Label is
+a 2D Node type), and the Label appears, selected, at the top left
+corner of the viewport.
+
+The node appears in the scene tree editor (box in the top right
+corner), and the label properties apear in the Inspector (box in the
+bottom right corner).
 
 The next step, will be to change the "Text" Property of the label, let
 change it to "Hello, World!":
@@ -185,13 +188,14 @@ selecting 'hello.scn'.
 With this change, pressing the regular Play button (or F5) will run the
 project, no matter which scene is being edited.
 
-| Going back to the project settings dialog. This dialog provides a lot
-  of options that can be added to engine.cfg and show their default
-  values. If the default value is ok, then there isn't any need to
-  change it.
-| When a value is changed, a tick is marked to the left of the name.
-  This means that the property will be saved to the engine.cfg file and
-  remembered.
+Going back to the project settings dialog. This dialog provides a lot
+of options that can be added to engine.cfg and show their default
+values. If the default value is ok, then there isn't any need to
+change it.
+
+When a value is changed, a tick is marked to the left of the name.
+This means that the property will be saved to the engine.cfg file and
+remembered.
 
 As a side note, for future reference and a little out of context (this
 is the first tutorial after all!), it is also possible to add custom

tutorials/step_by_step/simple_2d_game.rst

@@ -51,12 +51,13 @@ lot of code. The fact that most games allow controller customization
 makes this worse. For this, Godot created the "Input Actions". An action
 is defined, then input methods that trigger it are added.
 
-| Open the project properties dialog again, but this time move to the
-  "Input Map" tab.
-| On it, add 4 actions:
-  "left\_move\_up","left\_move\_down","right\_move\_up","right\_move\_down".
-  Assign the keys that you desire. A/Z for left and Up/Down as keys
-  should work in most cases.
+Open the project properties dialog again, but this time move to the
+"Input Map" tab.
+
+On it, add 4 actions:
+"left\_move\_up","left\_move\_down","right\_move\_up","right\_move\_down".
+Assign the keys that you desire. A/Z for left and Up/Down as keys
+should work in most cases.
 
 .. image:: /img/inputmap.png
 

tutorials/step_by_step/singletons_autoload.rst

@@ -90,11 +90,12 @@ points to this file:
 
 .. image:: /img/addglobal.png
 
-| Now, when any scene is run, the script will be always loaded.
-| So, going back to it, In the \_ready() function, the current scene
-  will be fetched. Both the current scene and global.gd are children of
-  root, but the autoloaded nodes are always first. This means that the
-  last child of root is always the loaded scene.
+Now, when any scene is run, the script will be always loaded.
+
+So, going back to it, In the \_ready() function, the current scene
+will be fetched. Both the current scene and global.gd are children of
+root, but the autoloaded nodes are always first. This means that the
+last child of root is always the loaded scene.
 
 Also, make sure that global.gd extends from Node, otherwise it won't be
 loaded.

tutorials/vector_math.rst

@@ -132,10 +132,11 @@ It is the same as doing:
 
 Except the former is way more efficient and readable.
 
-| Regular arithmetic operations such as addition, subtraction,
-  multiplication and division are supported.
-| Vector multiplication and division can also be mixed with single-digit
-  numbers, also named **scalars**.
+Regular arithmetic operations such as addition, subtraction,
+multiplication and division are supported.
+
+Vector multiplication and division can also be mixed with single-digit
+numbers, also named **scalars**.
 
 ::
 
@@ -156,10 +157,11 @@ Except, again, the former is way more efficient and readable.
 Perpendicular Vectors
 ~~~~~~~~~~~~~~~~~~~~~
 
-| Rotating a 2D vector 90° degrees to either side, left or right, is
-  really easy, just swap x and y, then
-| negate either x or y (direction of rotation depends on which is
-  negated).
+Rotating a 2D vector 90° degrees to either side, left or right, is
+really easy, just swap x and y, then
+
+negate either x or y (direction of rotation depends on which is
+negated).
 
 .. image:: /img/tutovec15.png
 
@@ -386,14 +388,15 @@ two vectors, we must do:
 
     var angle_in_radians = acos( a.dot(b) )
 
-| What is this useful for? Well obtaining the angle directly is probably
-  not as useful, but just being able to tell the angle is useful for
-  reference. One example is in the `Kinematic
-  Character <https://github.com/okamstudio/godot/blob/master/demos/2d/kinematic_char/player.gd#L83>`__
-  demo, when the character moves in a certain direction then we hit an
-  object. How to tell if what we hit is the floor?
-| By comparing the normal of the collision point with a previously
-  computed angle.
+What is this useful for? Well obtaining the angle directly is probably
+not as useful, but just being able to tell the angle is useful for
+reference. One example is in the `Kinematic
+Character <https://github.com/okamstudio/godot/blob/master/demos/2d/kinematic_char/player.gd#L83>`__
+demo, when the character moves in a certain direction then we hit an
+object. How to tell if what we hit is the floor?
+
+By comparing the normal of the collision point with a previously
+computed angle.
 
 The beauty of this is that the same code works exactly the same and
 without modification in
@@ -476,8 +479,9 @@ to reach a point in the plane, you will just do:
 
    </pre>
 
-| var point\_in\_plane = N\*D
-| 
+var point\_in\_plane = N\*D
+
+
 
 .. raw:: html
 
@@ -687,8 +691,9 @@ This can be simplified, in Godot, to:
 
    </pre>
 
-| var c = a.cross(b)
-| 
+var c = a.cross(b)
+
+
 
 .. raw:: html
 
@@ -718,9 +723,11 @@ other two points. As example, we will use B as a pivot:
 
    </pre>
 
-| var BA = A-B
-| var BC = C-B
-| 
+var BA = A-B
+
+var BC = C-B
+
+
 
 .. raw:: html
 
@@ -755,8 +762,9 @@ normal of the plane.
 
    </pre>
 
-| var N = P.normalized()
-| 
+var N = P.normalized()
+
+
 
 .. raw:: html