mirror of
https://github.com/godotengine/godot-docs.git
synced 2025-12-31 17:49:03 +03:00
Update some pages for Godot 3
This commit is contained in:
@@ -54,7 +54,7 @@ open source `Sphinx <http://www.sphinx-doc.org>`_ and `ReadTheDocs
|
||||
|
||||
.. note:: You can contribute to Godot's documentation by opening issue tickets
|
||||
or sending patches via pull requests on its GitHub
|
||||
`source repository <http://github.com/godotengine/godot-docs>`_.
|
||||
`source repository <https://github.com/godotengine/godot-docs>`_.
|
||||
|
||||
All the contents are under the permissive Creative Commons Attribution 3.0
|
||||
(`CC-BY 3.0 <https://creativecommons.org/licenses/by/3.0/>`_) license, with
|
||||
|
||||
@@ -23,14 +23,14 @@ Creating a project
|
||||
------------------
|
||||
|
||||
Creating a project from the command line is simple, just navigate the
|
||||
shell to the desired place and just make an engine.cfg file exist, even
|
||||
shell to the desired place and just make project.godot file exist, even
|
||||
if empty.
|
||||
|
||||
::
|
||||
|
||||
user@host:~$ mkdir newgame
|
||||
user@host:~$ cd newgame
|
||||
user@host:~/newgame$ touch engine.cfg
|
||||
user@host:~/newgame$ touch project.godot
|
||||
|
||||
That alone makes for an empty Godot project.
|
||||
|
||||
@@ -50,7 +50,7 @@ the same code with that scene as argument.
|
||||
|
||||
::
|
||||
|
||||
user@host:~/newgame$ godot -e scene.xml
|
||||
user@host:~/newgame$ godot -e scene.tscn
|
||||
|
||||
Erasing a scene
|
||||
---------------
|
||||
@@ -61,7 +61,7 @@ references that scene, or else an error will be thrown upon opening.
|
||||
|
||||
::
|
||||
|
||||
user@host:~/newgame$ rm scene.xml
|
||||
user@host:~/newgame$ rm scene.tscn
|
||||
|
||||
Running the game
|
||||
----------------
|
||||
@@ -78,7 +78,7 @@ line.
|
||||
|
||||
::
|
||||
|
||||
user@host:~/newgame$ godot scene.xml
|
||||
user@host:~/newgame$ godot scene.tscn
|
||||
|
||||
Debugging
|
||||
---------
|
||||
@@ -93,7 +93,7 @@ just fly by. For this, a command line debugger is provided by adding
|
||||
|
||||
::
|
||||
|
||||
user@host:~/newgame$ godot -d scene.xml
|
||||
user@host:~/newgame$ godot -d scene.tscn
|
||||
|
||||
Exporting
|
||||
---------
|
||||
|
||||
@@ -18,7 +18,7 @@ As mentioned in the previous tutorial, :ref:`doc_canvas_layers`, every
|
||||
CanvasItem node (remember that Node2D and Control based nodes use
|
||||
CanvasItem as their common root) will reside in a *Canvas Layer*. Every
|
||||
canvas layer has a transform (translation, rotation, scale, etc.) that
|
||||
can be accessed as a :ref:`Matrix32 <class_Matrix32>`.
|
||||
can be accessed as a :ref:`Transform2D <class_Transform2D>`.
|
||||
|
||||
Also covered in the previous tutorial, nodes are drawn by default in Layer 0,
|
||||
in the built-in canvas. To put nodes in a different layer, a :ref:`CanvasLayer
|
||||
@@ -28,7 +28,7 @@ Global canvas transform
|
||||
-----------------------
|
||||
|
||||
Viewports also have a Global Canvas transform (also a
|
||||
:ref:`Matrix32 <class_Matrix32>`). This is the master transform and
|
||||
:ref:`Transform2D <class_Transform2D>`). This is the master transform and
|
||||
affects all individual *Canvas Layer* transforms. Generally this
|
||||
transform is not of much use, but is used in the CanvasItem Editor
|
||||
in Godot's editor.
|
||||
@@ -92,8 +92,7 @@ way:
|
||||
::
|
||||
|
||||
var local_pos = Vector2(10,20) # local to Control/Node2D
|
||||
var ie = InputEvent()
|
||||
ie.type = InputEvent.MOUSE_BUTTON
|
||||
var ie = InputEventMouseButton.new()
|
||||
ie.button_index = BUTTON_LEFT
|
||||
ie.pos = get_viewport_transform() * (get_global_transform() * local_pos)
|
||||
ie.position = get_viewport_transform() * (get_global_transform() * local_pos)
|
||||
get_tree().input_event(ie)
|
||||
|
||||
@@ -19,7 +19,7 @@ These nodes are placed as direct or indirect children to a
|
||||
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:`Transform2D <class_Transform2D>` 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
|
||||
|
||||
@@ -227,7 +227,7 @@ Also, don't forget to modify the _draw() function to make use of these variables
|
||||
Let's run!
|
||||
It works, but the arc is rotating insanely fast! What's wrong?
|
||||
|
||||
The reason is that your GPU is actually displaying the frames as fast as he can. We need to "normalize" the drawing by this speed. To achieve, we have to make use of the 'delta' parameter of the _process() function. 'delta' contains the time elapsed between the two last rendered frames. It is generally small (about 0.0003 seconds, but this depends on your hardware). So, using 'delta' to control your drawing ensures your program to run at the same speed on every hardware.
|
||||
The reason is that your GPU is actually displaying the frames as fast as it can. We need to "normalize" the drawing by this speed. To achieve, we have to make use of the 'delta' parameter of the _process() function. 'delta' contains the time elapsed between the two last rendered frames. It is generally small (about 0.0003 seconds, but this depends on your hardware). So, using 'delta' to control your drawing ensures your program to run at the same speed on every hardware.
|
||||
|
||||
In our case, we simply need to multiply our 'rotation_ang' variable by 'delta' in the _process() function. This way, our 2 angles will be increased by a much smaller value, which directly depends on the rendering speed.
|
||||
|
||||
|
||||
@@ -198,7 +198,7 @@ Emit timeout
|
||||
------------
|
||||
|
||||
This variable will switch emission off after given amount of seconds
|
||||
being on. When zero, itś disabled.
|
||||
being on. When zero, it is disabled.
|
||||
|
||||
Offset
|
||||
------
|
||||
@@ -253,7 +253,7 @@ Randomness
|
||||
----------
|
||||
|
||||
All physics parameters can be randomized. Random variables go from 0 to
|
||||
1. the formula to randomize a parameter is:
|
||||
1. The formula to randomize a parameter is:
|
||||
|
||||
::
|
||||
|
||||
|
||||
@@ -89,7 +89,7 @@ a background, so it should not have a collision.
|
||||
.. image:: /img/tile_example5.png
|
||||
|
||||
OK! We're done! Remember to save this scene for future edit, call it
|
||||
"tileset_edit.scn" or something like that.
|
||||
"tileset_edit.tscn" or something like that.
|
||||
|
||||
Exporting a TileSet
|
||||
-------------------
|
||||
@@ -99,7 +99,7 @@ create a tileset. Use Scene > Convert To > Tile Set from the Scene Menu:
|
||||
|
||||
.. image:: /img/tileset_export.png
|
||||
|
||||
Then choose a filename, like "mytiles.res". Make sure the "Merge With
|
||||
Then choose a filename, like "mytiles.tres". Make sure the "Merge With
|
||||
Existing" option is toggled on. This way, every time the tileset
|
||||
resource file is overwritten, existing tiles are merged and updated
|
||||
(they are referenced by their unique name, so again, **name your tiles
|
||||
@@ -110,13 +110,13 @@ properly**).
|
||||
Using the TileSet in a TileMap
|
||||
------------------------------
|
||||
|
||||
Create a new scene, use any node or node2d as root, then create a
|
||||
Create a new scene, use any Node or Node2D as root, then create a
|
||||
:ref:`TileMap <class_TileMap>` as
|
||||
a child.
|
||||
|
||||
.. image:: /img/tilemap_scene.png
|
||||
|
||||
Go to the tileset property of this node and assign the one created in
|
||||
Go to the TileSet property of this node and assign the one created in
|
||||
previous steps:
|
||||
|
||||
.. image:: /img/tileset_property.png
|
||||
|
||||
@@ -97,15 +97,15 @@ when:
|
||||
:ref:`Control.set_focus_mode() <class_Control_set_focus_mode>`.
|
||||
|
||||
This function is
|
||||
:ref:`Control._input_event() <class_Control__input_event>`.
|
||||
:ref:`Control._gui_input() <class_Control__gui_input>`.
|
||||
Simply override it in your control. No processing needs to be set.
|
||||
|
||||
::
|
||||
|
||||
extends Control
|
||||
|
||||
func _input_event(ev):
|
||||
if (ev.type==InputEvent.MOUSE_BUTTON and ev.button_index==BUTTON_LEFT and ev.pressed):
|
||||
func _gui_input(ev):
|
||||
if (ev is InputEventMouseButton and ev.button_index==BUTTON_LEFT and ev.pressed):
|
||||
print("Left mouse button was pressed!")
|
||||
|
||||
For more information about events themselves, check the :ref:`doc_inputevent`
|
||||
|
||||
@@ -8,7 +8,7 @@ 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
|
||||
:ref:`Label <class_Label>`, :ref:`TextureFrame <class_TextureFrame>`,
|
||||
:ref:`Label <class_Label>`, :ref:`TextureRect <class_TextureRect>`,
|
||||
:ref:`TextureButton <class_TextureButton>` and
|
||||
:ref:`TextureProgress <class_TextureProgress>`.
|
||||
|
||||
|
||||
@@ -38,5 +38,3 @@ it, leaving a 20 pixel margin:
|
||||
|
||||
.. image:: /img/marginaround.png
|
||||
|
||||
Finally, there is also a ratio option, where 0 means left, 1 means right
|
||||
and anything in between is interpolated.
|
||||
|
||||
@@ -39,7 +39,7 @@ received input, in order:
|
||||
For gameplay input, the _unhandled_input() is generally a better fit, because it allows the GUI to intercept the events.
|
||||
2. Second, it will try to feed the input to the GUI, and see if any
|
||||
control can receive it. If so, the :ref:`Control <class_Control>` will be called via the
|
||||
virtual function :ref:`Control._input_event() <class_Control__input_event>` and the signal
|
||||
virtual function :ref:`Control._gui_input() <class_Control__gui_input>` 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 :ref:`Control.accept_event() <class_Control_accept_event>` and the event will
|
||||
@@ -75,9 +75,7 @@ Example of changing event type.
|
||||
::
|
||||
|
||||
# create event
|
||||
var ev = InputEvent()
|
||||
# set type index
|
||||
ev.type = InputEvent.MOUSE_BUTTON
|
||||
var ev = InputEventMouseButton.new()
|
||||
# button_index is only available for the above type
|
||||
ev.button_index = BUTTON_LEFT
|
||||
|
||||
@@ -140,8 +138,7 @@ The Input singleton has a method for this:
|
||||
|
||||
::
|
||||
|
||||
var ev = InputEvent()
|
||||
ev.type = InputEvent.ACTION
|
||||
var ev = InputEventAction.new()
|
||||
# set as move_left, pressed
|
||||
ev.set_as_action("move_left", true)
|
||||
# feedback
|
||||
@@ -154,5 +151,5 @@ Customizing and re-mapping input from code is often desired. If your
|
||||
whole workflow depends on actions, the :ref:`InputMap <class_InputMap>` singleton is
|
||||
ideal for reassigning or creating different actions at run-time. This
|
||||
singleton is not saved (must be modified manually) and its state is run
|
||||
from the project settings (engine.cfg). So any dynamic system of this
|
||||
from the project settings (project.godot). So any dynamic system of this
|
||||
type needs to store settings in the way the programmer best sees fit.
|
||||
|
||||
@@ -30,10 +30,10 @@ for example:
|
||||
func _input(ev):
|
||||
# Mouse in viewport coordinates
|
||||
|
||||
if (ev.type==InputEvent.MOUSE_BUTTON):
|
||||
print("Mouse Click/Unclick at: ",ev.pos)
|
||||
elif (ev.type==InputEvent.MOUSE_MOTION):
|
||||
print("Mouse Motion at: ",ev.pos)
|
||||
if (ev is InputEventMouseButton):
|
||||
print("Mouse Click/Unclick at: ",ev.position)
|
||||
elif (ev is InputEventMouseMotion):
|
||||
print("Mouse Motion at: ",ev.position)
|
||||
|
||||
# Print the size of the viewport
|
||||
|
||||
@@ -46,4 +46,4 @@ Alternatively it's possible to ask the viewport for the mouse position:
|
||||
|
||||
::
|
||||
|
||||
get_viewport().get_mouse_pos()
|
||||
get_viewport().get_mouse_position()
|
||||
|
||||
@@ -3,11 +3,11 @@
|
||||
Background loading
|
||||
==================
|
||||
|
||||
When switching the main scene of your game (for example going to a new
|
||||
When switching the main scene of your game (e.g. going to a new
|
||||
level), you might want to show a loading screen with some indication
|
||||
that progress is being made. The main load method
|
||||
(``ResourceLoader::load`` or just ``load`` from gdscript) blocks your
|
||||
thread while the resource is being loaded, so It's not good. This
|
||||
(``ResourceLoader::load`` or just ``load`` from GDScript) blocks your
|
||||
thread while the resource is being loaded, so it's not good. This
|
||||
document discusses the ``ResourceInteractiveLoader`` class for smoother
|
||||
load screens.
|
||||
|
||||
@@ -273,27 +273,27 @@ Example:
|
||||
queue = preload("res://resource_queue.gd").new()
|
||||
queue.start()
|
||||
|
||||
# suppose your game starts with a 10 second custscene, during which the user can't interact with the game.
|
||||
# suppose your game starts with a 10 second cutscene, during which the user can't interact with the game.
|
||||
# For that time we know they won't use the pause menu, so we can queue it to load during the cutscene:
|
||||
queue.queue_resource("res://pause_menu.xml")
|
||||
queue.queue_resource("res://pause_menu.tres")
|
||||
start_curscene()
|
||||
|
||||
# later when the user presses the pause button for the first time:
|
||||
pause_menu = queue.get_resource("res://pause_menu.xml").instance()
|
||||
pause_menu = queue.get_resource("res://pause_menu.tres").instance()
|
||||
pause_menu.show()
|
||||
|
||||
# when you need a new scene:
|
||||
queue.queue_resource("res://level_1.xml", true) # use "true" as the second parameter to put it at the front
|
||||
# of the queue, pausing the load of any other resource
|
||||
queue.queue_resource("res://level_1.tscn", true) # use "true" as the second parameter to put it at the front
|
||||
# of the queue, pausing the load of any other resource
|
||||
|
||||
# to check progress
|
||||
if queue.is_ready("res://level_1.xml"):
|
||||
show_new_level(queue.get_resource("res://level_1.xml"))
|
||||
if queue.is_ready("res://level_1.tscn"):
|
||||
show_new_level(queue.get_resource("res://level_1.tscn"))
|
||||
else:
|
||||
update_progress(queue.get_process("res://level_1.xml"))
|
||||
update_progress(queue.get_process("res://level_1.tscn"))
|
||||
|
||||
# when the user walks away from the trigger zone in your Metroidvania game:
|
||||
queue.cancel_resource("res://zone_2.xml")
|
||||
queue.cancel_resource("res://zone_2.tscn")
|
||||
|
||||
**Note**: this code in its current form is not tested in real world
|
||||
scenarios. Ask punto on IRC (#godotengine on irc.freenode.net) for help.
|
||||
|
||||
@@ -16,7 +16,7 @@ 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
|
||||
given folder that contains an "project.godot" text file, even if such
|
||||
file is empty.
|
||||
|
||||
Accessing project files can be done by opening any path with ``res://``
|
||||
|
||||
@@ -127,7 +127,7 @@ load function:
|
||||
# First we need to create the object and add it to the tree and set its position.
|
||||
var newobject = load(currentline["filename"]).instance()
|
||||
get_node(currentline["parent"]).add_child(newobject)
|
||||
newobject.set_pos(Vector2(currentline["posx"],currentline["posy"]))
|
||||
newobject.set_position(Vector2(currentline["posx"],currentline["posy"]))
|
||||
# Now we set the remaining variables.
|
||||
for i in currentline.keys():
|
||||
if (i == "filename" or i == "parent" or i == "posx" or i == "posy"):
|
||||
@@ -152,4 +152,4 @@ the needs of a project this needs to be considered. Saving objects in
|
||||
stages (parent objects first) so they are available when child objects
|
||||
are loaded will make sure they're available for the add_child() call.
|
||||
There will also need to be some way to link children to parents as the
|
||||
nodepath will likely be invalid.
|
||||
NodePath will likely be invalid.
|
||||
|
||||
@@ -61,7 +61,7 @@ Transforming shapes
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As seen before in the collide functions, 2D shapes in Godot can be
|
||||
transformed by using a regular :ref:`Matrix32 <class_Matrix32>`
|
||||
transformed by using a regular :ref:`Transform2D <class_Transform2D>`
|
||||
transform, meaning the functions can check for collisions while the
|
||||
shapes are scaled, moved and
|
||||
rotated. The only limitation to this is that shapes with curved sections
|
||||
|
||||
@@ -159,11 +159,11 @@ To obtain it using a camera, the following code can be used:
|
||||
const ray_length = 1000
|
||||
|
||||
func _input(ev):
|
||||
if ev.type==InputEvent.MOUSE_BUTTON and ev.pressed and ev.button_index==1:
|
||||
if ev is InputEventMouseButton and ev.pressed and ev.button_index==1:
|
||||
|
||||
var camera = get_node("camera")
|
||||
var from = camera.project_ray_origin(ev.pos)
|
||||
var to = from + camera.project_ray_normal(ev.pos) * ray_length
|
||||
var from = camera.project_ray_origin(ev.position)
|
||||
var to = from + camera.project_ray_normal(ev.position) * ray_length
|
||||
|
||||
Of course, remember that during ``_input()``, space may be locked, so save
|
||||
your query for ``_fixed_process()``.
|
||||
|
||||
@@ -19,7 +19,7 @@ Dynamic nature
|
||||
Pros & cons of dynamic typing
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
GDScript is a Dynamically Typed language. As such, it's main advantages
|
||||
GDScript is a Dynamically Typed language. As such, its main advantages
|
||||
are that:
|
||||
|
||||
- The language is very simple to learn.
|
||||
@@ -310,8 +310,8 @@ states and quick structs:
|
||||
|
||||
# indexing
|
||||
|
||||
d.mother = "rebecca" # this doesn't work (use syntax below to add a key:value pair)
|
||||
d["mother"] = "rebecca" # this works
|
||||
d.mother = "rebecca"
|
||||
d["mother"] = "rebecca"
|
||||
d.name = "caroline" # if key exists, assignment does work, this is why it's like a quick struct.
|
||||
|
||||
For & while
|
||||
|
||||
@@ -339,15 +339,14 @@ Vector built-in types
|
||||
:ref:`Vector2 <class_Vector2>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
2D vector type containing ``x`` and ``y`` fields. Can alternatively
|
||||
access fields as ``width`` and ``height`` for readability. Can also be
|
||||
2D vector type containing ``x`` and ``y`` fields. Can also be
|
||||
accessed as array.
|
||||
|
||||
:ref:`Rect2 <class_Rect2>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
2D Rectangle type containing two vectors fields: ``pos`` and ``size``.
|
||||
Alternatively contains an ``end`` field which is ``pos+size``.
|
||||
2D Rectangle type containing two vectors fields: ``position`` and ``size``.
|
||||
Alternatively contains an ``end`` field which is ``position+size``.
|
||||
|
||||
:ref:`Vector3 <class_Vector3>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@@ -355,7 +354,7 @@ Alternatively contains an ``end`` field which is ``pos+size``.
|
||||
3D vector type containing ``x``, ``y`` and ``z`` fields. This can also
|
||||
be accessed as an array.
|
||||
|
||||
:ref:`Matrix32 <class_Matrix32>`
|
||||
:ref:`Transform2D <class_Transform2D>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
3x2 matrix used for 2D transforms.
|
||||
@@ -372,15 +371,14 @@ and a ``d`` scalar distance.
|
||||
Quaternion is a datatype used for representing a 3D rotation. It's
|
||||
useful for interpolating rotations.
|
||||
|
||||
:ref:`AABB <class_AABB>`
|
||||
:ref:`Rect3 <class_Rect3>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Axis Aligned bounding box (or 3D box) contains 2 vectors fields: ``pos``
|
||||
Axis Aligned bounding box (or 3D box) contains 2 vectors fields: ``position``
|
||||
and ``size``. Alternatively contains an ``end`` field which is
|
||||
``pos+size``. As an alias of this type, ``Rect3`` can be used
|
||||
interchangeably.
|
||||
``position+size``.
|
||||
|
||||
:ref:`Matrix3 <class_Matrix3>`
|
||||
:ref:`Basis <class_Basis>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
3x3 matrix used for 3D rotation and scale. It contains 3 vector fields
|
||||
@@ -390,7 +388,7 @@ vectors.
|
||||
:ref:`Transform <class_Transform>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
3D Transform contains a Matrix3 field ``basis`` and a Vector3 field
|
||||
3D Transform contains a Basis field ``basis`` and a Vector3 field
|
||||
``origin``.
|
||||
|
||||
Engine built-in types
|
||||
@@ -402,12 +400,6 @@ Engine built-in types
|
||||
Color data type contains ``r``, ``g``, ``b``, and ``a`` fields. It can
|
||||
also be accessed as ``h``, ``s``, and ``v`` for hue/saturation/value.
|
||||
|
||||
:ref:`Image <class_Image>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Contains a custom format 2D image and allows direct access to the
|
||||
pixels.
|
||||
|
||||
:ref:`NodePath <class_NodePath>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@@ -424,13 +416,6 @@ Resource ID (RID). Servers use generic RIDs to reference opaque data.
|
||||
|
||||
Base class for anything that is not a built-in type.
|
||||
|
||||
:ref:`InputEvent <class_InputEvent>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Events from input devices are contained in very compact form in
|
||||
InputEvent objects. Due to the fact that they can be received in high
|
||||
amounts from frame to frame they are optimized as their own data type.
|
||||
|
||||
Container built-in types
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -458,13 +443,13 @@ arrays are available. These only accept a single data type. They avoid memory
|
||||
fragmentation and also use less memory but are atomic and tend to run slower than generic
|
||||
arrays. They are therefore only recommended to use for very large data sets:
|
||||
|
||||
- :ref:`ByteArray <class_ByteArray>`: An array of bytes (integers from 0 to 255).
|
||||
- :ref:`IntArray <class_IntArray>`: An array of integers.
|
||||
- :ref:`FloatArray <class_FloatArray>`: An array of floats.
|
||||
- :ref:`StringArray <class_StringArray>`: An array of strings.
|
||||
- :ref:`Vector2Array <class_Vector2Array>`: An array of :ref:`Vector2 <class_Vector2>` objects.
|
||||
- :ref:`Vector3Array <class_Vector3Array>`: An array of :ref:`Vector3 <class_Vector3>` objects.
|
||||
- :ref:`ColorArray <class_ColorArray>`: An array of :ref:`Color <class_Color>` objects.
|
||||
- :ref:`PoolByteArray <class_PoolByteArray>`: An array of bytes (integers from 0 to 255).
|
||||
- :ref:`PoolIntArray <class_PoolIntArray>`: An array of integers.
|
||||
- :ref:`PoolRealArray <class_PoolRealArray>`: An array of floats.
|
||||
- :ref:`PoolStringArray <class_PoolStringArray>`: An array of strings.
|
||||
- :ref:`PoolVector2Array <class_PoolVector2Array>`: An array of :ref:`Vector2 <class_Vector2>` objects.
|
||||
- :ref:`PoolVector3Array <class_PoolVector3Array>`: An array of :ref:`Vector3 <class_Vector3>` objects.
|
||||
- :ref:`PoolColorArray <class_PoolColorArray>`: An array of :ref:`Color <class_Color>` objects.
|
||||
|
||||
:ref:`Dictionary <class_Dictionary>`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@@ -475,7 +460,7 @@ Associative container which contains values referenced by unique keys.
|
||||
|
||||
var d={4:5, "a key":"a value", 28:[1,2,3]}
|
||||
d["Hi!"] = 0
|
||||
var d = {
|
||||
d = {
|
||||
22 : "Value",
|
||||
"somekey" : 2,
|
||||
"otherkey" : [2,3,4],
|
||||
@@ -1092,8 +1077,8 @@ initializers, but they must be constant expressions.
|
||||
|
||||
# Typed arrays also work, only initialized empty:
|
||||
|
||||
export var vector3s = Vector3Array()
|
||||
export var strings = StringArray()
|
||||
export var vector3s = PoolVector3Array()
|
||||
export var strings = PoolStringArray()
|
||||
|
||||
# Regular array, created local for every instance.
|
||||
# Default value can include run-time values, but can't
|
||||
|
||||
@@ -36,21 +36,21 @@ Example of a file system contents:
|
||||
|
||||
::
|
||||
|
||||
/engine.cfg
|
||||
/enemy/enemy.scn
|
||||
/project.godot
|
||||
/enemy/enemy.tscn
|
||||
/enemy/enemy.gd
|
||||
/enemy/enemysprite.png
|
||||
/player/player.gd
|
||||
|
||||
engine.cfg
|
||||
project.godot
|
||||
----------
|
||||
|
||||
The engine.cfg file is the project description file, and it is always found at
|
||||
The project.godot file is the project description file, and it is always found at
|
||||
the root of the project. In fact its location defines where the root is. This
|
||||
is the first file that Godot looks for when opening a project.
|
||||
|
||||
This file contains the project configuration in plain text, using the win.ini
|
||||
format. Even an empty engine.cfg can function as a basic definition of a blank
|
||||
format. Even an empty project.godot can function as a basic definition of a blank
|
||||
project.
|
||||
|
||||
Path delimiter
|
||||
@@ -58,8 +58,8 @@ Path delimiter
|
||||
|
||||
Godot only supports ``/`` as a path delimiter. This is done for
|
||||
portability reasons. All operating systems support this, even Windows,
|
||||
so a path such as ``c:\project\engine.cfg`` needs to be typed as
|
||||
``c:/project/engine.cfg``.
|
||||
so a path such as ``c:\project\project.godot`` needs to be typed as
|
||||
``c:/project/project.godot``.
|
||||
|
||||
Resource path
|
||||
-------------
|
||||
@@ -69,7 +69,7 @@ cumbersome and non-portable. To solve this problem, the special path
|
||||
``res://`` was created.
|
||||
|
||||
The path ``res://`` will always point at the project root (where
|
||||
engine.cfg is located, so in fact ``res://engine.cfg`` is always
|
||||
project.godot is located, so in fact ``res://project.godot`` is always
|
||||
valid).
|
||||
|
||||
This file system is read-write only when running the project locally from
|
||||
|
||||
@@ -47,7 +47,7 @@ Input and drawing
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Controls receive input events by means of the
|
||||
:ref:`Control._input_event() <class_Control__input_event>`
|
||||
:ref:`Control._gui_input() <class_Control__gui_input>`
|
||||
callback. Only one control, the one in focus, will receive
|
||||
keyboard/joypad events (see
|
||||
:ref:`Control.set_focus_mode() <class_Control_set_focus_mode>`
|
||||
@@ -108,9 +108,9 @@ Add a script to that node, with the following code:
|
||||
else:
|
||||
draw_rect(r, Color(0,0,1) )
|
||||
|
||||
func _input_event(ev):
|
||||
func _gui_input(ev):
|
||||
|
||||
if (ev.type==InputEvent.MOUSE_BUTTON and ev.pressed):
|
||||
if (ev is InputEventMouseButton and ev.pressed):
|
||||
tapped=true
|
||||
update()
|
||||
|
||||
@@ -141,7 +141,7 @@ interactions or ways to present information are not necessary. They can
|
||||
be skinned easily with regular textures.
|
||||
|
||||
- :ref:`Label <class_Label>`: Node used for showing text.
|
||||
- :ref:`TextureFrame <class_TextureFrame>`: Displays a single texture,
|
||||
- :ref:`TextureRect <class_TextureRect>`: Displays a single texture,
|
||||
which can be scaled or kept fixed.
|
||||
- :ref:`TextureButton <class_TextureButton>`: Displays a simple textured
|
||||
button, states such as pressed, hover, disabled, etc. can be set.
|
||||
|
||||
@@ -43,11 +43,11 @@ the project manager using the 'Import' option:
|
||||
|
||||
.. image:: /img/importproject.png
|
||||
|
||||
Simply browse to inside the project location and open the "engine.cfg"
|
||||
Simply browse to inside the project location and open the "project.godot"
|
||||
file. The new project will appear on the list of projects. Edit the
|
||||
project by using the 'Edit' option.
|
||||
|
||||
This project contains two scenes "ball.scn" and "container.scn". The
|
||||
This project contains two scenes "ball.tscn" and "container.tscn". The
|
||||
ball scene is just a ball with physics, while container scene has a
|
||||
nicely shaped collision, so balls can be thrown in there.
|
||||
|
||||
@@ -63,7 +63,7 @@ Afterwards, push the link shaped button, this is the instancing button!
|
||||
|
||||
.. image:: /img/continst.png
|
||||
|
||||
Select the ball scene (ball.scn), the ball should appear at the origin
|
||||
Select the ball scene (ball.tscn), the ball should appear at the origin
|
||||
(0,0), move it to the center
|
||||
|
||||
of the scene, like this:
|
||||
|
||||
@@ -24,13 +24,12 @@ Examples of resources are
|
||||
:ref:`Script <class_Script>`,
|
||||
:ref:`Mesh <class_Mesh>`,
|
||||
:ref:`Animation <class_Animation>`,
|
||||
:ref:`Sample <class_Sample>`,
|
||||
:ref:`AudioStream <class_AudioStream>`,
|
||||
:ref:`Font <class_Font>`,
|
||||
:ref:`Translation <class_Translation>`,
|
||||
etc.
|
||||
|
||||
When Godot saves or loads (from disk) a scene (.scn or .xml), an image
|
||||
When Godot saves or loads (from disk) a scene (.tscn or .scn), an image
|
||||
(png, jpg), a script (.gd) or pretty much anything, that file is
|
||||
considered a resource.
|
||||
|
||||
@@ -71,7 +70,7 @@ begin with), it is considered a built-in resource.
|
||||
|
||||
For example, if the path \`"res://robi.png"\` is erased from the "path"
|
||||
property in the above example, and then the scene is saved, the resource
|
||||
will be saved inside the .scn scene file, no longer referencing the
|
||||
will be saved inside the .tscn scene file, no longer referencing the
|
||||
external "robi.png". However, even if saved as built-in, and even though
|
||||
the scene can be instanced multiple times, the resource will always
|
||||
be loaded only once. That means, different Robi robot scenes instanced
|
||||
@@ -112,7 +111,7 @@ must be used.
|
||||
::
|
||||
|
||||
func _on_shoot():
|
||||
var bullet = preload("res://bullet.scn").instance()
|
||||
var bullet = preload("res://bullet.tscn").instance()
|
||||
add_child(bullet)
|
||||
|
||||
This method creates the nodes in hierarchy, configures them (sets all
|
||||
|
||||
@@ -143,7 +143,7 @@ function:
|
||||
::
|
||||
|
||||
func _my_level_was_completed():
|
||||
get_tree().change_scene("res://levels/level2.scn")
|
||||
get_tree().change_scene("res://levels/level2.tscn")
|
||||
|
||||
This is a quick and useful way to switch scenes, but has the drawback
|
||||
that the game will stall until the new scene is loaded and running. At
|
||||
|
||||
@@ -143,7 +143,7 @@ Aaaand... Oops.
|
||||
.. image:: /img/neversaved.png
|
||||
|
||||
Scenes need to be saved to be run, so save the scene to something like
|
||||
hello.scn in Scene -> Save:
|
||||
hello.tscn in Scene -> Save:
|
||||
|
||||
.. image:: /img/save_scene.png
|
||||
|
||||
@@ -173,17 +173,17 @@ however, have several scenes so one of them must be set as the main
|
||||
scene. This scene is the one that will be loaded at the time the project
|
||||
is run.
|
||||
|
||||
These settings are all stored in the engine.cfg file, which is a
|
||||
These settings are all stored in the project.godot file, which is a
|
||||
plaintext file in win.ini format, for easy editing. There are dozens of
|
||||
settings that can be changed in this file to alter how a project executes,
|
||||
so to make matters simpler, a project setting dialog exists, which is
|
||||
sort of a frontend to editing engine.cfg
|
||||
sort of a frontend to editing project.godot
|
||||
|
||||
To access that dialog, simply go to Scene -> Project Settings.
|
||||
|
||||
Once the window opens, the task will be to select a main scene. This can
|
||||
be done easily by changing the application/main_scene property and
|
||||
selecting 'hello.scn'.
|
||||
selecting 'hello.tscn'.
|
||||
|
||||
.. image:: /img/main_scene.png
|
||||
|
||||
@@ -196,13 +196,13 @@ 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
|
||||
This means that the property will be saved to the project.godot 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
|
||||
configuration options and read them in run-time using the
|
||||
:ref:`Globals <class_Globals>` singleton.
|
||||
:ref:`GlobalConfig <class_GlobalConfig>` singleton.
|
||||
|
||||
To be continued...
|
||||
------------------
|
||||
|
||||
@@ -91,7 +91,7 @@ look like the image below. You can set the text in the Inspector pane.
|
||||
|
||||
.. image:: /img/label_button_example.png
|
||||
|
||||
Finally, save the scene, a fitting name could be "sayhello.scn"
|
||||
Finally, save the scene, a fitting name could be "sayhello.tscn"
|
||||
|
||||
.. _doc_scripting-adding_a_script:
|
||||
|
||||
@@ -127,7 +127,7 @@ be included by default:
|
||||
|
||||
There is not much in there. The "_ready()" function is called when the
|
||||
node (and all its children) entered the active scene. (Remember, it's
|
||||
not a constructor, the constructor is "_init()" ).
|
||||
not a constructor, the constructor is "_init()").
|
||||
|
||||
The role of the script
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -74,7 +74,7 @@ all enemies can be notified about the alarm sounding, by using
|
||||
::
|
||||
|
||||
func _on_discovered():
|
||||
get_tree().call_group(0, "guards", "player_was_discovered")
|
||||
get_tree().call_group("guards", "player_was_discovered")
|
||||
|
||||
The above code calls the function "player_was_discovered" on every
|
||||
member of the group "guards".
|
||||
@@ -208,14 +208,14 @@ first one is to load the scene from disk.
|
||||
|
||||
::
|
||||
|
||||
var scene = load("res://myscene.scn") # will load when the script is instanced
|
||||
var scene = load("res://myscene.tscn") # will load when the script is instanced
|
||||
|
||||
Preloading it can be more convenient sometimes, as it happens at parse
|
||||
time.
|
||||
|
||||
::
|
||||
|
||||
var scene = preload("res://myscene.scn") # will load when parsing the script
|
||||
var scene = preload("res://myscene.tscn") # will load when parsing the script
|
||||
|
||||
But 'scene' is not yet a node containing subnodes. It's packed in a
|
||||
special resource called :ref:`PackedScene <class_PackedScene>`.
|
||||
|
||||
@@ -177,9 +177,9 @@ default, so a small adjustment of ``pad_size / 2`` must be added.
|
||||
::
|
||||
|
||||
func _process(delta):
|
||||
var ball_pos = get_node("ball").get_pos()
|
||||
var left_rect = Rect2( get_node("left").get_pos() - pad_size*0.5, pad_size )
|
||||
var right_rect = Rect2( get_node("right").get_pos() - pad_size*0.5, pad_size )
|
||||
var ball_pos = get_node("ball").get_position()
|
||||
var left_rect = Rect2( get_node("left").get_position() - pad_size*0.5, pad_size )
|
||||
var right_rect = Rect2( get_node("right").get_position() - pad_size*0.5, pad_size )
|
||||
|
||||
Now, let's add some movement to the ball in the ``_process()`` function.
|
||||
Since the ball position is stored in the ``ball_pos`` variable,
|
||||
@@ -235,7 +235,7 @@ the ball, which was computed before:
|
||||
|
||||
::
|
||||
|
||||
get_node("ball").set_pos(ball_pos)
|
||||
get_node("ball").set_position(ball_pos)
|
||||
|
||||
Next, we allow the pads to move. We only update their position according
|
||||
to player input. This is done using the Input class:
|
||||
@@ -243,24 +243,24 @@ to player input. This is done using the Input class:
|
||||
::
|
||||
|
||||
# Move left pad
|
||||
var left_pos = get_node("left").get_pos()
|
||||
var left_pos = get_node("left").get_position()
|
||||
|
||||
if (left_pos.y > 0 and Input.is_action_pressed("left_move_up")):
|
||||
left_pos.y += -PAD_SPEED * delta
|
||||
if (left_pos.y < screen_size.y and Input.is_action_pressed("left_move_down")):
|
||||
left_pos.y += PAD_SPEED * delta
|
||||
|
||||
get_node("left").set_pos(left_pos)
|
||||
get_node("left").set_position(left_pos)
|
||||
|
||||
# Move right pad
|
||||
var right_pos = get_node("right").get_pos()
|
||||
var right_pos = get_node("right").get_position()
|
||||
|
||||
if (right_pos.y > 0 and Input.is_action_pressed("right_move_up")):
|
||||
right_pos.y += -PAD_SPEED * delta
|
||||
if (right_pos.y < screen_size.y and Input.is_action_pressed("right_move_down")):
|
||||
right_pos.y += PAD_SPEED * delta
|
||||
|
||||
get_node("right").set_pos(right_pos)
|
||||
get_node("right").set_position(right_pos)
|
||||
|
||||
We use the four actions previously defined in the Input actions setup
|
||||
section above. When the player activates the respective key, the
|
||||
|
||||
@@ -62,10 +62,10 @@ more complex behavior when switching between scenes.
|
||||
First download the template from here:
|
||||
:download:`autoload.zip </files/autoload.zip>`, then open it.
|
||||
|
||||
Two scenes are present, scene_a.scn and scene_b.scn on an otherwise
|
||||
Two scenes are present, scene_a.tscn and scene_b.tscn on an otherwise
|
||||
empty project. Each are identical and contain a button connected to a
|
||||
callback for switching to the other scene. When the project runs, it
|
||||
starts in scene_a.scn. However, this currently does nothing and pressing the
|
||||
starts in scene_a.tscn. However, this currently does nothing and pressing the
|
||||
button does not work.
|
||||
|
||||
global.gd
|
||||
@@ -160,7 +160,7 @@ and scene_b.gd:
|
||||
#add to scene_a.gd
|
||||
|
||||
func _on_goto_scene_pressed():
|
||||
get_node("/root/global").goto_scene("res://scene_b.scn")
|
||||
get_node("/root/global").goto_scene("res://scene_b.tscn")
|
||||
|
||||
and
|
||||
|
||||
@@ -169,7 +169,7 @@ and
|
||||
#add to scene_b.gd
|
||||
|
||||
func _on_goto_scene_pressed():
|
||||
get_node("/root/global").goto_scene("res://scene_a.scn")
|
||||
get_node("/root/global").goto_scene("res://scene_a.tscn")
|
||||
|
||||
Now if you run the project, you can switch between both scenes by pressing
|
||||
the button!
|
||||
|
||||
@@ -23,7 +23,7 @@ Set the display resolution to 800x450 in Project Settings, and set up a new scen
|
||||
|
||||
.. image:: /img/robisplashpreview.png
|
||||
|
||||
The nodes "background" and "logo" are of :ref:`TextureFrame <class_TextureFrame>`
|
||||
The nodes "background" and "logo" are of :ref:`TextureRect <class_TextureRect>`
|
||||
type. These have a special property for setting the texture to be
|
||||
displayed, just load the corresponding file.
|
||||
|
||||
|
||||
@@ -31,7 +31,7 @@ time, and the system will apply those rules automatically each time the
|
||||
asset is re-imported.
|
||||
|
||||
Godot does not do the re-import process automatically, though. It gives
|
||||
the team the option to do it at any time ( a red icon on the top right
|
||||
the team the option to do it at any time (a red icon on the top right
|
||||
of the screen, allows the ability to do it at any desired time).
|
||||
|
||||
Does it always work?
|
||||
@@ -101,7 +101,7 @@ For example, the repository layout can look like this:
|
||||
source_assets/fonts/myfont.ttf
|
||||
source_assets/translation/strings.csv
|
||||
source_assets/art/niceart.psd
|
||||
game/engine.cfg
|
||||
game/project.godot
|
||||
|
||||
In the above example, artists, musician, translators, etc. can work in
|
||||
the source_assets/ folder, then import the assets to the game/ folder.
|
||||
|
||||
@@ -50,8 +50,8 @@ Then also, the game itself is, in this case, inside a game/ folder:
|
||||
|
||||
::
|
||||
|
||||
myproject/game/engine.cfg
|
||||
myproject/game/scenes/house/house.scn
|
||||
myproject/game/project.godot
|
||||
myproject/game/scenes/house/house.tscn
|
||||
myproject/game/scenes/house/sometexture.tex
|
||||
myproject/game/sound/door_open.smp
|
||||
myproject/game/sound/door_close.smp
|
||||
@@ -83,9 +83,9 @@ like this:
|
||||
|
||||
::
|
||||
|
||||
game/engine.cfg
|
||||
game/scenes/scene1.scn
|
||||
game/scenes/scene2.scn
|
||||
game/project.godot
|
||||
game/scenes/scene1.tscn
|
||||
game/scenes/scene2.tscn
|
||||
game/textures/texturea.png
|
||||
game/textures/another.tex
|
||||
game/sounds/sound1.smp
|
||||
@@ -101,20 +101,20 @@ something like this:
|
||||
|
||||
::
|
||||
|
||||
game/engine.cfg
|
||||
game/scenes/house/house.scn
|
||||
game/project.godot
|
||||
game/scenes/house/house.tscn
|
||||
game/scenes/house/texture.tex
|
||||
game/scenes/valley/canyon.scn
|
||||
game/scenes/valley/rock.scn
|
||||
game/scenes/valley/canyon.tscn
|
||||
game/scenes/valley/rock.tscn
|
||||
game/scenes/valley/rock.tex
|
||||
game/scenes/common/tree.scn
|
||||
game/scenes/common/tree.tscn
|
||||
game/scenes/common/tree.tex
|
||||
game/player/player.scn
|
||||
game/player/player.tscn
|
||||
game/player/player.gd
|
||||
game/npc/theking.scn
|
||||
game/npc/theking.tscn
|
||||
game/npc/theking.gd
|
||||
game/gui/main_screen/main_sceen.scn
|
||||
game/gui/options/options.scn
|
||||
game/gui/main_screen/main_sceen.tscn
|
||||
game/gui/options/options.tscn
|
||||
|
||||
This model or similar models allows projects to grow to really large
|
||||
sizes and still be completely manageable. Notice that everything is
|
||||
|
||||
Reference in New Issue
Block a user