[closed] allow hook in to inbuilt keyboard shortcuts

[aubergine18]

Looking through the various .cfg locale files, I spotted these __CONTROL__ values:

Code: Select all

* toggle-driving
* build
* build-ghost
* close-gui
* move-up, down, left, right
* open-character-gui
* open-gui
* stack-transfer
* rotate
* shoot-enemy
* next-weapon
* show-info
* mine
* pick-items
* (assuming but not seen) drop-items

There are probably others. Anyway...

It would be supremely useful if mods could listen to the resulting events (some are already available as standard events) even if the `event` object that results from them doesn't contain any useful information. Simply knowing the key has been pressed will be hugely useful to mods.

For example:

Code: Select all

script.on_event( 'mine', function(event)
  -- i know the player tried to *start* mining
end )

The benefit here is that mod doesn't need to define a `custom-input` prototype, it can just listen for the inbuilt input events.

However, if a custom-input approach is preferred, then can we at least reference the __CONTROL__ value as the keys definition, so that the custom-input will always be synchronised with the players choice of keyboard shortcut for the standard game input.

For example:

Code: Select all

data:extend {
  {
    type = 'custom-input',
    name = "mine",
    key_sequence = "__CONTROL__mine",
    consuming    = <whatever>
  }
}

[Rseding91]

Keyboard events are long since meaningless by the time the game starts to process them.

For instance:

Rotate entity: when the game actually starts to rotate the entity it has been *latency input time on the multiplayer game* since the keyboard was actually pressed. The game gets an event "rotate the selected entity of player X" and so it does it. The same thing happens with all other input. By the time the game processes the input it has no idea what keyboard key sequence or mouse sequence actually triggered it - because that data is meaningless.

That's why there are events as there are now: on_player_rotated_entity , on_player_mined_item and so on. You don't care about the input - you care about the final result of the input.

[aubergine18]

Valid point about the MP lag, I keep overlooking that.

There are some cases where knowing about the initial trigger of an action would be useful, for example knowing when user has opened a GUI. Currently we use on_tick() to regularly check properties on player to see if they've opened something for example.