Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input Modules #4

Open
FavouriteDragon opened this issue Jan 28, 2023 · 1 comment
Open

Input Modules #4

FavouriteDragon opened this issue Jan 28, 2023 · 1 comment
Assignees

Comments

@FavouriteDragon
Copy link
Member

FavouriteDragon commented Jan 28, 2023

Input will be consolidated into isolated input modules. An input module has a couple of tasks:

  1. Register any listeners it needs for input
  2. Listen and keep track of input
  3. Emit events to the radix tree as they occur

For example, within the context of the keyboard & mouse input module, this would look like this:

  1. Subscribing to the correct Forge events
  2. Keeping track of mouse movement and traversing a radix tree based on the keypresses
  3. Send a start input event once the bending toggle key is pressed, send Forms as they are formed from keyboard presses or mouse movement, then send the stop input event once the bending toggle key is pressed once more.

So, what is needed is at least an implementation of the keyboard & mouse input module. A base input module interface might be helpful, but it shouldn't be too restrictive as it is up to each individual input module to decide how they want to structure themselves, as data is passed directly from each input module to the radix tree.

Important is that input modules should be dynamic. It should be possible to unregister and register them at any point, even mid-game.

@FavouriteDragon
Copy link
Member Author

TLDR:
InputModules take a list of InputData per Form or Modifier. They then turn these into Conditions to add to the forge event bus.
Every piece of InputData passed to the bus has its own queue. The InputModule tracks data passed by Conditions and generic Modifier listeners to put it in the queue. Forms and Modifiers that have their requirements fulfilled are added to a new queue. If a Form or Modifier overlap, the one with the more complex requirements is kept, and the other one is removed from the queue. The InputModule then passes these forms to the Radix Tree which moves down.
Additionally, some Forms will be denoted as "leaf nodes" for certain Skills. Upon these nodes being hit, the queue for listening data is cut off, and attempts to assign a Modifier or Form, or is cleared if nothing matches. These leaf nodes do not make the InputModule stop listening, however. Any Modifier flagged with affectsLeaf (or whatever you choose) will still be listened to. E.g Focus, Multi (repeating the "execute"/leaf node).

@aidan99davis aidan99davis moved this from 📋 Backlog to 🏗 In progress in 2023 Full Release Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🏗 In progress
Development

No branches or pull requests

2 participants