godotengine/godot-docs
1
0
Fork 0
mirror of https://github.com/godotengine/godot-docs.git synced 2026-01-05 22:09:56 +03:00
Code Issues Packages Projects Releases Wiki Activity

Update ui_code_a_life_bar.rst

Browse Source
This commit is contained in:
Jonathan
2018-04-09 14:09:56 +02:00
committed by GitHub
parent 9edbba1d25
commit 10857bb00e
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
getting_started/step_by_step/ui_code_a_life_bar.rst
View File

@@ -171,12 +171,12 @@ function and look at the health value? Accessing nodes this way creates
tight coupling between them. If you did it sparingly it may work. As
your game grows bigger, you may have many more connections. If you get
nodes from a bad it's becomes very complex very soon. Not only that: you
need to listen to the changes state constantly in the ``_process``
function. The check happens 60 times a second and you'll likely break
need to listen to the state change constantly in the ``_process``
function. This check happens 60 times a second and you'll likely break
the game because of the order in which the code runs.
On a given frame you may look at another node's property *before* it was
updated: you get a value that from the last frame. This leads to obscure
updated: you get a value from the last frame. This leads to obscure
bugs that are hard to fix. On the other hand, a signal is emitted right
after a change happened. It **guarantees** you're getting a fresh piece
of information. And you will update the state of your connected node