Fix some warnings and errors

tutorials/2d/gui_skinning.rst

@@ -2,7 +2,7 @@ Skinning a GUI
 ==============
 
 Oh Beautiful GUI!
-~~~~~~~~~~~~~~~~~
+-----------------
 
 This tutorial is about advanced skinning of an user interface. Most
 games generally don't need this, as they end up just relying on
@@ -22,7 +22,7 @@ but they can be skinned to resemble pretty much any kind of user
 interface.
 
 Theme
-~~~~~
+-----
 
 The GUI is skinned through the
 `Theme <https://github.com/okamstudio/godot/wiki/class_theme>`__
@@ -31,8 +31,8 @@ entire visual styling of all controls. Theme options are named, so it's
 not obvious which name changes what (specialy from code), but several
 tools are provided. The ultimate place to look at what each theme option
 is for each control, which will always be more up to date than any
-documentation is the file
-https://github.com/okamstudio/godot/blob/master/scene/resources/default\_theme/default\_theme.cpp.
+documentation is the file `scene/resources/default_theme/default_theme.cpp
+<https://github.com/godotengine/godot/blob/master/scene/resources/default_theme/default_theme.cpp>`__.
 The rest of this document will explain the different tools used to
 customize the theme.
 
@@ -45,7 +45,7 @@ used. This system allows for flexible overriding of themes in complex
 user interfaces.
 
 Theme Options
-~~~~~~~~~~~~~
+-------------
 
 Each kind of option in a theme can be:
 
@@ -94,7 +94,7 @@ are overrideable. This is not yet available in the wiki class reference,
 but will be soon.
 
 Customizing a Control
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 If only a few controls need to be skinned. It is often not neccesary to
 create a new theme. Controls offer their theme options as special kind
@@ -107,11 +107,11 @@ If checked, they can be used to override the value of the theme just for
 that control.
 
 Creating a Theme
-~~~~~~~~~~~~~~~~
+----------------
 
 The simplest way to create a theme is to edit a theme resource. Create a
 Theme from the resource menu, the editor will appear immediately.
-Following to this, save it (to, as example, myheme.thm):
+Following to this, save it (to, as example, mytheme.thm):
 
 .. image:: /img/themecheck.png
 
@@ -119,15 +119,15 @@ This will create an empty theme that can later be loaded and assigned to
 controls.
 
 Example: Themeing a Button
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 Take some assets attachment:skin\_assets.zip, go to the "theme" menu and
-select `Add Class Item <>`__
+select "Add Class Item":
 
 .. image:: /img/themeci.png
 
 A menu will appear promting the type of control to create. Select
-`Button <>`__
+"Button":
 
 .. image:: /img/themeci2.png
 

tutorials/3d/importing_3d_scenes.rst

@@ -73,20 +73,22 @@ Import process begins with the 3D scene import menu:
 
 That opens what is probably the biggest of all the import dialogs:
 
-| p=. |image1|
-| Many options exist in there, so each section will be explained as
-  follows:
+p=. |image1|
+
+Many options exist in there, so each section will be explained as
+follows:
 
 Source & target paths
----------------------
+~~~~~~~~~~~~~~~~~~~~~
+
+To import, two options are needed. The first is a source .dae file
+(.dae stands for Collada. More import formats will eventually added,
+but Collada is the most complete open format as of this writing).
 
-| To import, two options are needed. The first is a source .dae file
-  (.dae stands for Collada. More import formats will eventually added,
-  but Collada is the most complete open format as of this writing).
-| A target folder needs to be provided, so the importer can import the
-  scene there. The imported scene will have the same filename as the
-  source one, except for the .scn extension, so make sure you pick good
-  names when you export!
+A target folder needs to be provided, so the importer can import the
+scene there. The imported scene will have the same filename as the
+source one, except for the .scn extension, so make sure you pick good
+names when you export!
 
 The textures will be copied and converted. Textures in 3D applications
 are usually just PNG or JPG files. Godot will convert them to video
@@ -104,7 +106,7 @@ in the project settings). If you choose this, make sure no two textures
 are names the same.
 
 3D rigging tips
----------------
+~~~~~~~~~~~~~~~
 
 Before going into the options, here are some tips for making sure your
 rigs import properly
@@ -125,7 +127,7 @@ rigs import properly
    both objects (the little orange dot) should be at the same place.
 
 3D import options
------------------
+~~~~~~~~~~~~~~~~~
 
 This section contains many options to change the way import workflow
 works. Some (like HDR) will be better explained in other sections, but
@@ -156,7 +158,7 @@ Notice that:
 -  The Light was not imported (-noimp).
 
 Options in detail
------------------
+~~~~~~~~~~~~~~~~~
 
 Following is a list of most import options and what they do in more
 detail.
@@ -313,35 +315,37 @@ The rest of the tags in this section should be rather obvious, or will
 be documented/changed in the future.
 
 Double-sidedness
-----------------
+~~~~~~~~~~~~~~~~
 
-| Collada and other formats support specifying the double-sidedness of
-  the geometry (in other words, when not double-sided, back-faces are
-  not drawn). Godot supports this option per Material, not per Geometry.
-| When exporting from 3D DCCs that work with per-object double-sidedness
-  (such as Blender of Maya), make sure that the double sided objects do
-  not share a material with the single sided ones or the importer will
-  not be able to discern.
+Collada and other formats support specifying the double-sidedness of
+the geometry (in other words, when not double-sided, back-faces are
+not drawn). Godot supports this option per Material, not per Geometry.
+
+When exporting from 3D DCCs that work with per-object double-sidedness
+(such as Blender of Maya), make sure that the double sided objects do
+not share a material with the single sided ones or the importer will
+not be able to discern.
 
 Animation options
------------------
-
-| Some things to keep in mind when importing animations. 3D DCCs allow
-  animating with curves for every x,y,z component, doing IK constraints
-  and other stuff. When imported for real-time, animations are sampled
-  (at small intervals) so all this information is lost. Sampled
-  animations are fast to process, but can use considerable amounts of
-  memory.
-| Because of this, the "Optimize" option exists but, in some cases, this
-  option might get to break an animation, so make it sure to disable if
-  you see this.
+~~~~~~~~~~~~~~~~~
+
+Some things to keep in mind when importing animations. 3D DCCs allow
+animating with curves for every x,y,z component, doing IK constraints
+and other stuff. When imported for real-time, animations are sampled
+(at small intervals) so all this information is lost. Sampled
+animations are fast to process, but can use considerable amounts of
+memory.
+
+Because of this, the "Optimize" option exists but, in some cases, this
+option might get to break an animation, so make it sure to disable if
+you see this.
 
 Some animations are meant to be cycled (like walk animations) if this is
 the case, animation names that end in "-cycle" or "-loop" are
 automatically set to loop.
 
 Import script
--------------
+~~~~~~~~~~~~~
 
 Creating a script to parse the imported scene is actually really simple.
 This is great for post processing, changing materials, doing funny stuff
@@ -362,7 +366,7 @@ The post-import function takes the imported scene as parameter (the
 parameter is actually the root node of the scene).
 
 Update logic
-------------
+~~~~~~~~~~~~
 
 Other types of resources (like samples, meshes, fonts, images, etc.) are
 re-imported entirely when changed and user changes are not kept.

tutorials/3d/shader_materials.rst

@@ -27,7 +27,7 @@ Creating a ShaderMaterial
 -------------------------
 
 Create a new ShaderMaterial in some object of your choice. Go to the
-"Shader" property, then create a new `Shader <>`__
+"Shader" property, then create a new "Shader":
 
 .. image:: /img/shader_material_create.png
 

tutorials/engine/inputevent.rst

@@ -28,43 +28,44 @@ received input, in order:
 
 .. image:: /img/input_event_flow.png
 
-| 1. First, it will try to feed the input to the GUI, and see if any
-  control can receive it. If so, the [[API:Control]] will be called the
-  virtual function [[API:Control.\_input\_event()]] and the signal
-  "input\_event" will be emitted (this function is re-implementable by
-  script by inheriting from it). If the control wants to "consume" the
-  event, it will call [[API:Control.accept\_event()]] and the event will
-  not spread any more.
-| 2. If the GUI does not want the event, the standard \_input function
-  will be called in any node with input processing enabled (enable with
-  [[API:Node.set\_process\_input()]]) and override
-  [[API:Node.\_input()]]). If any function consumes the event, it can
-  call [[API:SceneTree.set\_input\_as\_handled()]], and the event will
-  not spread any more.
-| 3. If so far no one consumed the event, the unhandled input callback
-  will be called (enable with
-  [[API:Node.set\_process\_unhandled\_input()]]) and override
-  [[API:Node.\_unhandled\_input()]]). If any function consumes the
-  event, it can call [[SceneTree.set\_input\_as\_handled()]], and the
-  event will not spread any more.
-| 4. If no one wanted the event so far, and a [[API:Camera]] is assigned
-  to the Viewport, a ray to the physics world (in the ray direction from
-  he click) will be casted. If this ray hits an object, it will call the
-  [[API:CollisionObject.\_input\_event()]] function in the relevant
-  physics object (bodies receive this callback by default, but areas do
-  not. This can be configured through [[API:Area]] properties).
-| 5. Finally, if the event was unhandled, it will be passed to the next
-  Viewport in the tree, or it will be ignored.
+1. First, it will try to feed the input to the GUI, and see if any
+control can receive it. If so, the [[API:Control]] will be called the
+virtual function [[API:Control.\_input\_event()]] and the signal
+"input\_event" will be emitted (this function is re-implementable by
+script by inheriting from it). If the control wants to "consume" the
+event, it will call [[API:Control.accept\_event()]] and the event will
+not spread any more.
+2. If the GUI does not want the event, the standard \_input function
+will be called in any node with input processing enabled (enable with
+[[API:Node.set\_process\_input()]]) and override
+[[API:Node.\_input()]]). If any function consumes the event, it can
+call [[API:SceneTree.set\_input\_as\_handled()]], and the event will
+not spread any more.
+3. If so far no one consumed the event, the unhandled input callback
+will be called (enable with
+[[API:Node.set\_process\_unhandled\_input()]]) and override
+[[API:Node.\_unhandled\_input()]]). If any function consumes the
+event, it can call [[SceneTree.set\_input\_as\_handled()]], and the
+event will not spread any more.
+4. If no one wanted the event so far, and a [[API:Camera]] is assigned
+to the Viewport, a ray to the physics world (in the ray direction from
+the click) will be casted. If this ray hits an object, it will call the
+[[API:CollisionObject.\_input\_event()]] function in the relevant
+physics object (bodies receive this callback by default, but areas do
+not. This can be configured through [[API:Area]] properties).
+5. Finally, if the event was unhandled, it will be passed to the next
+Viewport in the tree, or it will be ignored.
 
 Anatomy of an InputEvent
 ------------------------
 
-| [[API:InputEvent]] is just a base built-in type, it does not represent
-  anything and only contains some basic information, such as event ID
-  (which is increased for each event), device index, etc.
-| InputEvent has a "type" member. By assigning it, it can become
-  different types of input event. Every type of InputEvent has different
-  properties, according to it's role.
+[[API:InputEvent]] is just a base built-in type, it does not represent
+anything and only contains some basic information, such as event ID
+(which is increased for each event), device index, etc.
+
+InputEvent has a "type" member. By assigning it, it can become
+different types of input event. Every type of InputEvent has different
+properties, according to it's role.
 
 Example of changing event type.
 
@@ -82,8 +83,6 @@ There are several types of InputEvent, described in the table below:
 +------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
 | Event                              | Type Index         | Description                                                                                                       |
 +------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
-| -------                            | ------------       | -------------                                                                                                     |
-+------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
 | [[API:InputEvent]]                 | NONE               | Empty Input Event                                                                                                 |
 +------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
 | [[API:InputEventKey]]              | KEY                | Contains a scancode and unicode value, as well as modifiers                                                       |

tutorials/step_by_step/scenes_and_nodes.rst

@@ -124,7 +124,7 @@ And finally, create the Label! A lot happens when Create is pressed:
   bottom right corner).
 
 The next step, will be to change the "Text" Property of the label, let
-change it to `Hello, World! <>`__
+change it to "Hello, World!":
 
 .. image:: /img/hw.png
 

tutorials/step_by_step/scripting.rst

@@ -96,15 +96,14 @@ Select the Panel node, then press the "Add Script" Icon as follows:
 
 .. image:: /img/addscript.png
 
-| The script creation diallog will popup. This dialog allows to select
-  the language, class name, etc.
-| GDScript does not use class names in script files, so that field is
-  not editable.
-| The script should inherit from "Panel" (as it is meant to extend the
-  node, which is of Panel type, this is automatically filled anyway).
-| Select the filename for the script (if you saved the scene previously,
-  one will be automatically generated as sayhello.gd) and push
-  `Create <>`__
+The script creation dialog will popup. This dialog allows to select
+the language, class name, etc. GDScript does not use class names in
+script files, so that field is not editable. The script should inherit
+from "Panel" (as it is meant to extend the node, which is of Panel type,
+this is automatically filled anyway).
+
+Select the filename for the script (if you saved the scene previously,
+one will be automatically generated as sayhello.gd) and push "Create":
 
 .. image:: /img/scriptcreate.png
 
@@ -153,11 +152,12 @@ Which will show the list of signals a Button can emit.
 
 .. image:: /img/button_connections.png
 
-| But this example will not use it. We don't want to make things *too*
-  easy. So please close that screen!
-| In any case, at this point it is clear that that we are interested in
-  the "pressed" signal, so instead of doing it with the visual
-  interface, the connection will be done using code.
+But this example will not use it. We don't want to make things *too*
+easy. So please close that screen!
+
+In any case, at this point it is clear that that we are interested in
+the "pressed" signal, so instead of doing it with the visual
+interface, the connection will be done using code.
 
 For this, there is a function that is probably the one that Godot
 programmers will use the most, this is