Relintai
/
godot-docs
mirror of https://github.com/Relintai/godot-docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix some warnings and errors

This commit is contained in:
Rémi Verschelde 2016-02-07 23:47:10 +01:00
parent cc3f706c1f
commit e0cb33da2d
6 changed files with 99 additions and 96 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
tutorials/2d/gui_skinning.rst
View File

@ -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

72
tutorials/3d/importing_3d_scenes.rst
View File

@ -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).
| 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!
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!
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.

2
tutorials/3d/shader_materials.rst
View File

@ -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

69
tutorials/engine/inputevent.rst
View File

@ -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 |

2
tutorials/step_by_step/scenes_and_nodes.rst
View File

@ -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

28
tutorials/step_by_step/scripting.rst
View File

@ -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