From 3297b8656351dc2f4329ec8ebfd96b3cb76916cd Mon Sep 17 00:00:00 2001 From: Griatch Date: Wed, 9 Mar 2016 13:26:43 +0100 Subject: [PATCH] Fixed formatting in inputevent tutorial Fixed a malformed enumeration list and removed erroneous use of "it's" when it should be "its". --- tutorials/engine/inputevent.rst | 48 ++++++++++++++++----------------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/tutorials/engine/inputevent.rst b/tutorials/engine/inputevent.rst index 83c23e88f..1311ecbe8 100644 --- a/tutorials/engine/inputevent.rst +++ b/tutorials/engine/inputevent.rst @@ -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 ` will be called the -virtual function :ref:`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() ` and the event will -not spread any more. + control can receive it. If so, the :ref:`Control ` will be called the + virtual function :ref:`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() ` 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() `) and override -:ref:`Node._input() `). If any function consumes the event, it can -call :ref:`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() `) and override + :ref:`Node._input() `). If any function consumes the event, it can + call :ref:`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() `) and override -:ref:`Node._unhandled_input() `). If any function consumes the -event, it can call :ref:`SceneTree.set_input_as_handled() `, and the -event will not spread any more. + will be called (enable with + :ref:`Node.set_process_unhandled_input() `) and override + :ref:`Node._unhandled_input() `). If any function consumes the + event, it can call :ref:`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 ` 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() ` function in the relevant -physics object (bodies receive this callback by default, but areas do -not. This can be configured through :ref:`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() ` function in the relevant + physics object (bodies receive this callback by default, but areas do + not. This can be configured through :ref:`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 ` 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.