nodes_purposes.rst 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513
  1. .. _doc_nodes_purposes_visual_script:
  2. Nodes and Terminology
  3. =====================
  4. Before continuing, it must be noted that the *Node* terminology needs to be used with care.
  5. When referring to *Visual Script Nodes* (or generally *Nodes*) this text will refer to the little boxes you connect with lines, which are part of a graph.
  6. When referring to *Scene Nodes*, it is implied that the elements that make up a Scene are being referred, which are part of a tree. Their naming is similar but their function is different.
  7. When referring to *Node* here, it will be implied that a *Visual Script Node* is referred to unless indicated otherwise.
  8. .. image:: img/visual_script16.png
  9. Node Properties
  10. ---------------
  11. Like in most visual scripting implementations, each node has editable properties. In Godot, though, we try to avoid
  12. bloating the nodes with editable controls for the sake of readability.
  13. Nodes still display the required information as text, but editing is done via the *Inspector*. To edit them,
  14. select any node and edit its properties in the *Inspector*.
  15. Ports and Connections
  16. ---------------------
  17. Programming in Godot Visual Scripting is done via *Nodes* and *Port Connections* inside each function.
  18. Ports
  19. ~~~~~
  20. Nodes in Godot Visual Scripting have *Ports*. These are endpoints that appear to the
  21. left and right of nodes and which can be used to make *Connections*:
  22. There are two types of *Ports*: *Sequence* and *Data*.
  23. .. image:: img/visual_script17.png
  24. *Sequence Ports* indicate the order in which operations are executed.
  25. Typically when a *Node* is done processing, it will go to the next node from one of the ports at the right.
  26. If nothing is connected the function may end, or another output *Sequence Port* might be tried (this depends on the node).
  27. Thanks to this, you can follow the logic flow within a function by following the white lines.
  28. Not every *Node* has *Sequence Ports*. In fact, most do not.
  29. *Data Ports* ports contain typed values. Types can be any regular Godot types,
  30. such as a boolean, an integer, a string, a Vector3, an array, any Object or Scene Node, etc.
  31. A *Data Port* on the right side of a node is considered an output, while,
  32. a port on the left side is an input. Connecting them allows information to flow to the next node.
  33. Not all *Data Port* types are compatible and will allow connections, though.
  34. Pay special attention to colors and icons, as each type has a different representation:
  35. .. image:: img/visual_script18.png
  36. Connections
  37. ~~~~~~~~~~~
  38. Connecting is a relatively simple process. Drag an *Output Port* towards an *Input Port*.
  39. .. image:: img/visual_script_connect.gif
  40. Disconnecting takes a bit more practice. Disconnecting in *Data Ports* happens by
  41. dragging the *Input* away, while for *Sequence Ports*, this happens by dragging the *Output* away.
  42. .. image:: img/visual_script_disconnect.gif
  43. This may seem strange at the beginning, but it happens because *Data Ports* are 1:N
  44. (A single output port can connect to many inputs), while *Sequence Ports* are N:1
  45. (Many sequence outputs can be connected to a single input).
  46. Connecting to empty space (drag to connect but unpress over empty space) is also context sensitive, it will supply
  47. a list of most common operations. For sequences, it will be conditional nodes:
  48. .. image:: img/visual_script52.png
  49. While, for data, a contextual set/get/call menu will open:
  50. .. image:: img/visual_script53.png
  51. Adding Nodes
  52. ------------
  53. Finally! We got to the fun part! But, before explaining in more detail what each type of node does,
  54. let's take a short look at how nodes are most commonly added and dealt with.
  55. Accessing Scene Nodes
  56. ~~~~~~~~~~~~~~~~~~~~~
  57. One of the most common tasks is accessing Scene Tree Nodes (again, not to mistake with *Visual Script Nodes*).
  58. Dragging from the Scene Tree and dropping into the canvas will ask you to *call a method* (sometimes referred to as *member function*) on this node.
  59. .. image:: img/visual_script19.png
  60. While accessing properties is desired in most cases (more on that below), sometimes *calling methods* can be useful too.
  61. Methods execute specific actions on objects. In the above case, the mouse pointer can be warped to a position in local
  62. coordinates to the control. Another common use case is queueing a node for deletion, which is done with the *queue_free* method.
  63. .. image:: img/visual_script20.png
  64. Care must be taken that this only works if the scene being edited contains your *Visual Script* in one of the nodes! Otherwise, a warning will be shown.
  65. Accessing Scene Node Properties
  66. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  67. This is the most common way to edit *Scene Nodes* in Visual Scripting. Select a *Scene Node* from the *Scene Tree*, go to the Inspector, find *the Name* of the property you want to edit (hint, *not* the value!) and drag it to the canvas:
  68. .. image:: img/visual_script21.png
  69. The result is that this value can be changed from your script by writing to a *Data Port*.
  70. If instead reading this value is desired, drag the node again but hold the *Control* key (or Command on Mac). This will create a getter:
  71. .. image:: img/visual_script22.png
  72. In this case, the value can be read from a *Data Port*.
  73. Variables
  74. ~~~~~~~~~
  75. Variables are memory containers local to the script which can hold a value. This value can be read from any of the functions of the script or from other scripts via the method described in the previous step.
  76. To add a Variable, push the "+" button on the *Variables* section of the Members panel. Double-click the new variable to rename it:
  77. .. image:: img/visual_script23.png
  78. Right-clicking the variable allows you to configure its properties:
  79. .. image:: img/visual_script24.png
  80. .. image:: img/visual_script25.png
  81. As it can be seen above, the type and initial value of the variable can be changed, as well as some property hints (@TODO, document this).
  82. Ticking the "Export" options makes the variable visible in the Inspector when selecting the node. This also makes it available to other scripts via the method described in the previous step.
  83. .. image:: img/visual_script28.png
  84. To use the variable in the script, simply drag it to the canvas to create a getter:
  85. .. image:: img/visual_script26.png
  86. Likewise, hold *Control* (*Command* on Mac) to drop a setter:
  87. .. image:: img/visual_script27.png
  88. Signals
  89. ~~~~~~~
  90. It is also possible to create your own signals in a script and use them. For this, do the same steps you did for variables in the previous step, except for *Signals*:
  91. .. image:: img/visual_script29.png
  92. A signal can also be edited via right-click menu to customize its arguments:
  93. .. image:: img/visual_script30.png
  94. The signal you have created will appear in the Inspector along with the built-in node signals. This allows you to connect it from another script from another *Scene Node*:
  95. .. image:: img/visual_script31.png
  96. Finally, to emit the signal, simply drag it to the canvas:
  97. .. image:: img/visual_script32.png
  98. Remember that emitting a signal is a sequenced operation, so it must come from a Sequence port.
  99. Adding More Nodes
  100. -----------------
  101. Now that the basics are covered, let's discuss the large amount of utility nodes available for your canvas!
  102. Below the member panel, exists the list of all available node types:
  103. .. image:: img/visual_script33.png
  104. Ctrl-F (Command-F on Mac) allows you to search the list.
  105. Any of them can be dragged to the scene. Unlike nodes (e.g. dragging a property
  106. from the Inspector sets the context to the node being edited automatically), these are added without any "contextual" information, so this has to be done manually.
  107. .. image:: img/visual_script34.png
  108. Remember that you can check the class reference for what each node does, as they are documented there. That mentioned,
  109. a brief overview of node types follows:
  110. Constants
  111. ~~~~~~~~~
  112. Constant nodes are nodes that provide values that, while not changing over time, can be useful as reference values.
  113. Most of the time they are integer or float.
  114. .. image:: img/visual_script36.png
  115. The first one is "Constant" which allows you to select any value of any type as constant, from an integer (42) to a String ("Hello!"). In general this node is not used that often because of default input values in *Data Ports*, but it's good to know it exists.
  116. The second is the GlobalConstant node, which contains a long list of constants for global types in Godot. In there
  117. you can find some useful constants to refer to key names, joystick or mouse buttons, etc.
  118. The third one is MathConstant, which provides typical mathematical constants such as PI, E, etc.
  119. Data
  120. ~~~~
  121. Data nodes deal with all sorts of access to information. Any information in Godot is accessed via these nodes, so
  122. they are some of the most important ones to use and pretty diverse.
  123. .. image:: img/visual_script37.png
  124. There are many types of nodes of interest here, so a short attempt to describe them will follow:
  125. Action
  126. ^^^^^^
  127. Action nodes are vital when dealing with input from a device. You can read more about actions in the (@TODO ACTION TUTE LINK).
  128. In the following example below, the control is moved to the right when the "move_right" action is pressed.
  129. .. image:: img/visual_script38.png
  130. Engine Singleton
  131. ^^^^^^^^^^^^^^^^
  132. Engine singletons are global interfaces (meaning they can be accessed without a reference, unlike Scene Nodes, they are always available).
  133. They have several purposes, but in general they are useful for low level access or OS-related access.
  134. .. image:: img/visual_script39.png
  135. Remember that dragging a connection to empty space will help you call functions or set/get properties on these:
  136. .. image:: img/visual_script40.png
  137. Local Variables
  138. ^^^^^^^^^^^^^^^
  139. These are nodes you can use as temporary storage for your graphs. Make sure they all have the same name and type when using them and they will reference the same piece of memory.
  140. .. image:: img/visual_script41.png
  141. As it can be seen above, there are two nodes available: A simple getter, and a sequenced getter (setting requires a sequence port).
  142. Scene Node
  143. ^^^^^^^^^^
  144. This is just a reference to a node in the tree, but it's easier to use this node by dragging the actual node
  145. from the scene tree to the canvas (this will create it and configure it).
  146. Self
  147. ^^^^
  148. In some rare occasions, it may be desired to pass this Scene Node as argument.
  149. It can be used to call functions and set/get properties, or drag nodes (or event the node itself that has the script) from the Scene Tree to the canvas for this.
  150. SceneTree
  151. ^^^^^^^^^
  152. This node is similar to the Singleton node because it references the SceneTree, which contains the active scene.
  153. SceneTree, however, only works when the node is sitting in the scene and active, otherwise accessing it will
  154. return as an error.
  155. SceneTree allows for many low level things, like setting stretch options, calling groups, make timers, or even
  156. load another scene. It's a good class to get familiar with.
  157. Preload
  158. ^^^^^^^
  159. This does the same function as preload() in GDScript. It maintains this resource loaded and ready to use. Rather than
  160. instancing the node, it's simpler to drag the desired resource from the filesystem dock to the canvas.
  161. Resource Path
  162. ^^^^^^^^^^^^^
  163. This node is a simple helper to get a string with a path to a resource you can pick. It's useful in functions that
  164. load things from disk.
  165. Comment
  166. ^^^^^^^
  167. A Comment node works as a node you can resize to put around other nodes. It will not try to get focus or be brought
  168. to top when selecting it. It can also be used to write text on it.
  169. .. image:: img/visual_script42.png
  170. Flow Control
  171. ~~~~~~~~~~~~
  172. Flow control nodes allow the execution to take different branches, usually depending on a
  173. given condition.
  174. .. image:: img/visual_script43.png
  175. Condition
  176. ^^^^^^^^^
  177. This is a simple node that checks a bool port. If true, it will go via the "true" sequence port. If false,
  178. the second. After going for either of them, it goes via the "done" port. Leaving sequence
  179. ports disconnected is fine if not all of them are used.
  180. Iterator
  181. ^^^^^^^^
  182. Some data types in Godot (ie, arrays, dictionaries) are iterable. This means that a bit of code can run
  183. for each element that it has.
  184. The Iterator node goes through all elements and, for each of them, it goes via the "each" sequence port,
  185. making the element available in the "elem" data port.
  186. When done, it goes via the "exit" sequence port.
  187. Return
  188. ^^^^^^
  189. Some functions can return values. In general for virtual ones, Godot will add the Return node for you.
  190. A return node forces the function to end.
  191. Sequence
  192. ^^^^^^^^
  193. This node is useful mostly for organizing your graph. It calls its sequence ports in order.
  194. TypeCast
  195. ^^^^^^^^
  196. This is a useful and commonly used node. You can use it to cast arguments or other objects
  197. to the type you desire. Afterwards, you can even drag the object output to get full completion.
  198. .. image:: img/visual_script55.png
  199. It is also possible to cast to a script, which will allow complete script properties and functions:
  200. .. image:: img/visual_script54.png
  201. Switch
  202. ^^^^^^
  203. The Switch node is similar to the Condition node, but it matches many values at the same time.
  204. While
  205. ^^^^^
  206. This is a more primitive form of iteration. "repeat" sequence output will be called as long as
  207. the condition in the "cond" data port is met.
  208. Functions
  209. ~~~~~~~~~
  210. Functions are simple helpers, most of the time deterministic. They take some arguments as
  211. input and return an output. They are almost never sequenced.
  212. Built-In
  213. ^^^^^^^^
  214. There is a list of built in helpers. The list is almost identical to the one from GDScript (@TODO, link to gdscript methods?).
  215. Most of them are mathematical functions, but others can be useful helpers. Make sure to take a look at the list
  216. at some point.
  217. By Type
  218. ^^^^^^^
  219. Those are the methods available to basic types. For example, if you want a dot-product, you can search for "dot" instead of the Vector3 category.
  220. In most cases just search the list of nodes, it should be faster.
  221. Call
  222. ^^^^
  223. This is the generic calling node. It is rarely used directly but by dragging to empty space on an already configured node.
  224. Constructors
  225. ^^^^^^^^^^^^
  226. These are all the functions needed to create Godot basic datatypes. For example, If you need to create a Vector3 out of 3 floats, a constructor must be used.
  227. .. image:: img/visual_script44.png
  228. Destructor
  229. ^^^^^^^^^^
  230. This is the opposite to Constructor, it allows to separate any basic type (ie, Vector3) into its sub-elements.
  231. .. image:: img/visual_script45.png
  232. Emit Signal
  233. ^^^^^^^^^^^
  234. Emits signals from any object. In general it's not that useful, as dragging a signal to the canvas works better.
  235. Get/Set
  236. ^^^^^^^
  237. Generic Getter/Setter node. Dragging properties from the Inspector works better, as they appear properly configured on drop.
  238. Wait
  239. ^^^^
  240. The Wait nodes will suspend execution of the function until something happens (many frames can pass until resuming, in fact).
  241. Default nodes allow you to wait for a frame to pass, a fixed frame or a given amount of time until execution is resumed.
  242. Yield
  243. ^^^^^
  244. This node completely suspends the execution of the script, and it will make the function return a value that can be used to resume execution.
  245. Yield Signal
  246. ^^^^^^^^^^^^
  247. Same as Yield, but will wait until a given signal is emitted.
  248. Index
  249. ~~~~~
  250. Generic indexing operator, not often used but it's good that it exists just in case.
  251. Operators
  252. ~~~~~~~~~
  253. These are mostly generic operators such as addition, multiplication, comparison, etc.
  254. By default, these mostly accept any datatype (and will error in run-time if the types
  255. feeded do not match for the operator). It is always recommended to set the right
  256. type for operators to catch errors faster and make the graph easier to read.
  257. .. image:: img/visual_script46.png
  258. Expression Node
  259. ^^^^^^^^^^^^^^^
  260. Among the operators, the *Expression* node is the most powerful. If well used, it allows you to enormously simplify
  261. visual scripts that are math or logic heavy. Type any expression on it and it will be executed in real-time.
  262. Expression nodes can:
  263. - Perform math and logic expressions based on custom inputs (eg: "a*5+b", where a and b are custom inputs):
  264. .. image:: img/visual_script47.png
  265. - Access local variables or properties:
  266. .. image:: img/visual_script48.png
  267. - Use most of the existing built-in functions that are available to GDScript, such as sin(),cos(),print(), as well as constructors, such as Vector3(x,y,z),Rect2(..), etc.:
  268. .. image:: img/visual_script49.png
  269. - Call API functions:
  270. .. image:: img/visual_script50.png
  271. - Use sequenced mode, which makes more sense in case of respecting the processing order:
  272. .. image:: img/visual_script51.png