inputevent.rst 9.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147
  1. .. _doc_inputevent:
  2. InputEvent
  3. ==========
  4. What is it?
  5. -----------
  6. Managing input is usually complex, no matter the OS or platform. To ease
  7. this a little, a special built-in type is provided, :ref:`InputEvent <class_InputEvent>`.
  8. This datatype can be configured to contain several types of input
  9. events. Input Events travel through the engine and can be received in
  10. multiple locations, depending on the purpose.
  11. How does it work?
  12. -----------------
  13. Every input event is originated from the user/player (though it's
  14. possible to generate an InputEvent and feed then back to the engine,
  15. which is useful for gestures). The OS object for each platform will read
  16. events from the device, then feed the to MainLoop. As :ref:`SceneTree <class_SceneTree>`
  17. is the default MainLoop implementation, events are fed to it. Godot
  18. provides a function to get the current SceneTree object :
  19. **get_tree()**.
  20. But SceneTree does not know what to do with the event, so it will give
  21. it to the viewports, starting by the "root" :ref:`Viewport <class_Viewport>` (the first
  22. node of the scene tree). Viewport does quite a lot of stuff with the
  23. received input, in order:
  24. .. image:: /img/input_event_flow.png
  25. 1. First, it will try to feed the input to the GUI, and see if any
  26. control can receive it. If so, the :ref:`Control <class_Control>` will be called the
  27. virtual function :ref:`Control._input_event() <class_Control__input_event>` and the signal
  28. "input_event" will be emitted (this function is re-implementable by
  29. script by inheriting from it). If the control wants to "consume" the
  30. event, it will call :ref:`Control.accept_event() <class_Control_accept_event>` and the event will
  31. not spread any more.
  32. 2. If the GUI does not want the event, the standard _input function
  33. will be called in any node with input processing enabled (enable with
  34. :ref:`Node.set_process_input() <class_Node_set_process_input>`) and override
  35. :ref:`Node._input() <class_Node__input>`). If any function consumes the event, it can
  36. call :ref:`SceneTree.set_input_as_handled() <class_SceneTree_set_input_as_handled>`, and the event will
  37. not spread any more.
  38. 3. If so far no one consumed the event, the unhandled input callback
  39. will be called (enable with
  40. :ref:`Node.set_process_unhandled_input() <class_Node_set_process_unhandled_input>`) and override
  41. :ref:`Node._unhandled_input() <class_Node__unhandled_input>`). If any function consumes the
  42. event, it can call :ref:`SceneTree.set_input_as_handled() <class_SceneTree_set_input_as_handled>`, and the
  43. event will not spread any more.
  44. 4. If no one wanted the event so far, and a :ref:`Camera <class_Camera>` is assigned
  45. to the Viewport, a ray to the physics world (in the ray direction from
  46. the click) will be casted. If this ray hits an object, it will call the
  47. :ref:`CollisionObject._input_event() <class_CollisionObject__input_event>` function in the relevant
  48. physics object (bodies receive this callback by default, but areas do
  49. not. This can be configured through :ref:`Area <class_Area>` properties).
  50. 5. Finally, if the event was unhandled, it will be passed to the next
  51. Viewport in the tree, or it will be ignored.
  52. Anatomy of an InputEvent
  53. ------------------------
  54. :ref:`InputEvent <class_InputEvent>` is just a base built-in type, it does not represent
  55. anything and only contains some basic information, such as event ID
  56. (which is increased for each event), device index, etc.
  57. InputEvent has a "type" member. By assigning it, it can become
  58. different types of input event. Every type of InputEvent has different
  59. properties, according to it's role.
  60. Example of changing event type.
  61. ::
  62. # create event
  63. var ev = InputEvent()
  64. # set type index
  65. ev.type=InputEvent.MOUSE_BUTTON
  66. # button_index is only available for the above type
  67. ev.button_index=BUTTON_LEFT
  68. There are several types of InputEvent, described in the table below:
  69. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  70. | Event | Type Index | Description |
  71. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  72. | :ref:`InputEvent <class_InputEvent>` | NONE | Empty Input Event |
  73. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  74. | :ref:`InputEventKey <class_InputEventKey>` | KEY | Contains a scancode and unicode value, as well as modifiers |
  75. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  76. | :ref:`InputEventMouseButton <class_InputEventMouseButton>` | MOUSE_BUTTON | Contains click information, such as button, modifiers, etc. |
  77. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  78. | :ref:`InputEventMouseMotion <class_InputEventMouseMotion>` | MOUSE_MOTION | Contains motion information, such as relative, absolute positions and speed. |
  79. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  80. | :ref:`InputEventJoystickMotion <class_InputEventJoystickMotion>` | JOYSTICK_MOTION | Contains Joystick/Joypad analog axis information. |
  81. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  82. | :ref:`InputEventJoystickButton <class_InputEventJoystickButton>` | JOYSTICK_BUTTON | Contains Joystick/Joypad button information. |
  83. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  84. | :ref:`InputEventScreenTouch <class_InputEventScreenTouch>` | SCREEN_TOUCH | Contains multi-touch press/release information. (only available on mobile devices) |
  85. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  86. | :ref:`InputEventScreenDrag <class_InputEventScreenDrag>` | SCREEN_DRAG | Contains multi-touch drag information. (only available on mobile devices) |
  87. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  88. | :ref:`InputEventAction <class_InputEventAction>` | SCREEN_ACTION | Contains a generic action. These events are often generated by the programmer as feedback. (more on this below) |
  89. +-------------------------------------------------------------------+--------------------+-------------------------------------------------------------------------------------------------------------------+
  90. Actions
  91. -------
  92. An InputEvent may or may not represent a pre-defined action. Actions are
  93. useful because they abstract the input device when programming the game
  94. logic. This allows for:
  95. - The same code to work on different devices with different inputs (ie:
  96. keyboard on PC, Joypad on console)
  97. - Input to be reconfigured at run-time.
  98. Actions can be created from the Project Settings menu in the Actions
  99. tab. If you read the :ref:`doc_simple_2d_game` tutorial, there is an
  100. explanation on how the action editor works.
  101. Any event has the methods :ref:`InputEvent.is_action() <class_InputEvent_is_action>`,
  102. :ref:`InputEvent.is_pressed() <class_InputEvent_is_pressed>` and :ref:`InputEvent <class_InputEvent>`.
  103. Alternatively, it may be desired to supply the game back with an action
  104. from the game code (a good example of this is detecting gestures).
  105. SceneTree (derived from MainLoop) has a method for this:
  106. :ref:`MainLoop.input_event() <class_MainLoop_input_event>`. You would normally use it like this:
  107. ::
  108. var ev = InputEvent()
  109. ev.type=InputEvent.ACTION
  110. # set as move_left, pressed
  111. ev.set_as_action("move_left", true)
  112. # feedback
  113. get_tree().input_event(ev)
  114. InputMap
  115. --------
  116. Customizing and re-mapping input from code is often desired. If your
  117. whole workflow depends on actions, the :ref:`InputMap <class_InputMap>` singleton is
  118. ideal for reassigning or creating different actions at run-time. This
  119. singleton is not saved (must be modified manually) and it's state is run
  120. from the project settings (engine.cfg). So any dynamic system of this
  121. type needs to store settings in the way the programmer sees best fit.