Player Input

Player Input is a library specifically designed for handling polling based input detection, made possible by the type specific input field on players that gives us 20hz access to the keybinds forward, backward, left, right, jump, sneak, sprint at all times, in all game modes, regardless of context, except within GUIs.

The goal of this library is two fold:

1. Optimize actionable retrieval of this data; many packs need this data but its worse for performance for all of them to be polling at the same time.
2. Create easy & useful DX for tracking and acting on changes in this data.

Usage

Packs that need access to this input data for few out of many players in specific scenarios should use the capture/player path to begin tracking of the data.

Packs that need access to input data for most/all of players should use the capture/players path to begin tracking of the data, and call the release/players when the data is no longer needed (use #minecraft:unload if the data is needed all of the time)

When data is being received, the exclusive player_input.* /tag labels are always made available.

Packs that need to do their own custom tracking every tick regardless of if the binds change can use the raw entrypoint. If only some players need to be checked use the #player_input:player/raw function tag (called as/at each player) and use your own /tag label to filter players your pack is operating with as the function tag will be called for all usage of the library.

Events:

These entrypoints are called as/at players that match the required state along with context data made available to functions in each tag, enabling event-based handling, instead of checking for state every tick.

To subscribe to any of these, call the appropriate capture function, then to clean up after usage, call the release function.

As with raw, make sure to /tag players that your pack is specifically handling, as the function tag will be called for all usage of the library.

• key_update - Called as/at players whose input stack has changed from the previous tick.
  • Tracked via the exclusive player_input.previous.* /tag labels and the player_input.current_tick/player_input.previous_tick composite Scores on the player.
  • This context is also available for the following events.
• key_down - Called as/at players that were not holding down any given key(s) in the previous tick and started to.
  • Tracked via the exclusive player_input.down.* /tag labels and the keys_down player_input.current_tick composite Score during execution.
• key_up - Called as/at players that were holding down any given key(s) in the previous tick and released them.
  • Tracked via the exclusive player_input.up.* /tag labels and the keys_up player_input.current_tick composite Score during execution.

Example

jetpack:jetpack/equip

tag @s add jetpack.equipped

function player_input:capture/player/key_update

# Jetpack Things...

jetpack:input_received

execute if entity @s[tag=jetpack.equipped] run function jetpack:jetpack/control

jetpack:jetpack/control

# Handle changes to player input

jetpack:jetpack/unequipped

tag @s remove jetpack.equipped

function player_input:release/player/key_update

# Jetpack Things...

#player_input:player/key_update

{
    "values": [
        "jetpack:input_received"
    ],
    "replace": false
}

Plans

• Create a couple full proof-of-concept survival packs using this library and Player Motion.
• Reimplement in the Sandstone official player library
• Create a vanilla usage harness and deploy it to this repo
• Archive the current manually written vanilla code, automatically publish generated code to this repository.
• Port proof-of-concept packs to Sandstone.
• Maintain for changes in minecraft updates.