stan220/godot-docs
1
0
Fork 0
mirror of https://github.com/stan220/godot-docs.git synced 2026-09-08 21:29:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fixed formatting in inputevent tutorial

Browse Source 
Fixed a malformed enumeration list and removed erroneous use of "it's" when it should be "its".
This commit is contained in:
Griatch
2016-03-09 13:26:43 +01:00
parent 2943d53fa7
commit 3297b86563
1 changed files with 24 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tutorials/engine/inputevent.rst
+24 -24
View File
@@ -31,32 +31,32 @@ 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 :ref:`Control <class_Control>` will be called the
virtual function :ref:`Control._input_event() <class_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 :ref:`Control.accept_event() <class_Control_accept_event>` and the event will
not spread any more.
control can receive it. If so, the :ref:`Control <class_Control>` will be called the
virtual function :ref:`Control._input_event() <class_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 :ref:`Control.accept_event() <class_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
:ref:`Node.set_process_input() <class_Node_set_process_input>`) and override
:ref:`Node._input() <class_Node__input>`). If any function consumes the event, it can
call :ref:`SceneTree.set_input_as_handled() <class_SceneTree_set_input_as_handled>`, and the event will
not spread any more.
will be called in any node with input processing enabled (enable with
:ref:`Node.set_process_input() <class_Node_set_process_input>`) and override
:ref:`Node._input() <class_Node__input>`). If any function consumes the event, it can
call :ref:`SceneTree.set_input_as_handled() <class_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
:ref:`Node.set_process_unhandled_input() <class_Node_set_process_unhandled_input>`) and override
:ref:`Node._unhandled_input() <class_Node__unhandled_input>`). If any function consumes the
event, it can call :ref:`SceneTree.set_input_as_handled() <class_SceneTree_set_input_as_handled>`, and the
event will not spread any more.
will be called (enable with
:ref:`Node.set_process_unhandled_input() <class_Node_set_process_unhandled_input>`) and override
:ref:`Node._unhandled_input() <class_Node__unhandled_input>`). If any function consumes the
event, it can call :ref:`SceneTree.set_input_as_handled() <class_SceneTree_set_input_as_handled>`, and the
event will not spread any more.
4. If no one wanted the event so far, and a :ref:`Camera <class_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
:ref:`CollisionObject._input_event() <class_CollisionObject__input_event>` function in the relevant
physics object (bodies receive this callback by default, but areas do
not. This can be configured through :ref:`Area <class_Area>` properties).
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
:ref:`CollisionObject._input_event() <class_CollisionObject__input_event>` function in the relevant
physics object (bodies receive this callback by default, but areas do
not. This can be configured through :ref:`Area <class_Area>` properties).
5. Finally, if the event was unhandled, it will be passed to the next
Viewport in the tree, otherwise it will be ignored.
Viewport in the tree, otherwise it will be ignored.
Anatomy of an InputEvent
------------------------
@@ -67,7 +67,7 @@ anything and only contains some basic information, such as event ID
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.
properties, according to its role.
Example of changing event type.
@@ -142,6 +142,6 @@ InputMap
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 it's state is run
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
type needs to store settings in the way the programmer sees best fit.