Support for more types of inputs #93

Open
opened 6 months ago by kimimaru · 3 comments
Owner

The input syntax and input handler are fitting only for joystick inputs. Mouse, touch, and drag inputs don't make sense given the current syntax.

Ways to allow this may involve the following, in no particular order:

  • Abstract the ParsedInput struct into an interface with implementations for each type of input (Ex. JoystickInput, MouseInput, TouchInput).
  • Abstract the syntax into a separate ISyntax interface and Syntax implementation class. The interface would help with testing the syntax down the road.
  • Similarly, add a concrete type for input subsequences to clean up the code. A temporary name could be ParsedInputSubsequence.
  • Multiple IInputHandler implementations depending on the type of input. The current InputHandler would be turned into JoystickInputHandler. It would be preferable to have #80 finished beforehand to make it easier to wait on multiple input handlers in an input subsequence to finish before moving to the next input subsequence.
  • Virtual controllers would need to be generalized to virtual input devices. Each type of input handler would handle a given virtual input device.

This is all brainstorming right now; things will probably change during the implementation. This is a very large task that would take a lot of refactoring. Before doing this, it would be beneficial to have more tests and benchmarks so it'll be easier to compare the performance of parsing and executing inputs.

The input syntax and input handler are fitting only for joystick inputs. Mouse, touch, and drag inputs don't make sense given the current syntax. Ways to allow this may involve the following, in no particular order: - Abstract the `ParsedInput` struct into an interface with implementations for each type of input (Ex. `JoystickInput`, `MouseInput`, `TouchInput`). - Abstract the syntax into a separate `ISyntax` interface and `Syntax` implementation class. The interface would help with testing the syntax down the road. - Similarly, add a concrete type for input subsequences to clean up the code. A temporary name could be `ParsedInputSubsequence`. - Multiple `IInputHandler` implementations depending on the type of input. The current `InputHandler` would be turned into `JoystickInputHandler`. It would be preferable to have https://codeberg.org/kimimaru/TRBot/issues/80 finished beforehand to make it easier to wait on multiple input handlers in an input subsequence to finish before moving to the next input subsequence. - Virtual controllers would need to be generalized to virtual input devices. Each type of input handler would handle a given virtual input device. This is all brainstorming right now; things will probably change during the implementation. This is a very large task that would take a lot of refactoring. Before doing this, it would be beneficial to have more tests and benchmarks so it'll be easier to compare the performance of parsing and executing inputs.
kimimaru added the
enhancement
refactor
labels 6 months ago
Poster
Owner

The InputHandler has been rewritten to use Tasks and seems to be performing well so far. I've also written tests for it, all of which pass. I'll give it more time in a deployment before deciding if it's stable enough to merge.

The `InputHandler` has been rewritten to use Tasks and seems to be performing well so far. I've also written tests for it, all of which pass. I'll give it more time in a deployment before deciding if it's stable enough to merge.
Poster
Owner

Another type of input can be a CommandInput. In other words, an input that acts as a command. For example, "say" could be a CommandInput for the SayCommand.

Another type of input can be a `CommandInput`. In other words, an input that acts as a command. For example, "say" could be a `CommandInput` for the `SayCommand`.
Poster
Owner

I feel the first step of this implementation could be to allow for a more flexible syntax. Some ideas:

  • A new Syntax table in the database with rows for the Name, Definition, and SyntaxType
  • The Description could take the form of each IPreparser (in some way) or a raw regex. The purpose of the former would be to make it trivial to piece together existing preparsers to make a new syntax.
  • The SyntaxType could be values corresponding to Joystick, Mouse, etc. This would be a bitwise field to describe the types of inputs the syntax supports.
  • Custom could be another type that takes in a C# source file to use as the parser. This should allow for a completely customized parser!
I feel the first step of this implementation could be to allow for a more flexible syntax. Some ideas: - A new **Syntax** table in the database with rows for the `Name`, `Definition`, and `SyntaxType` - The `Description` could take the form of each `IPreparser` (in some way) or a raw regex. The purpose of the former would be to make it trivial to piece together existing preparsers to make a new syntax. - The `SyntaxType` could be values corresponding to Joystick, Mouse, etc. This would be a bitwise field to describe the types of inputs the syntax supports. - `Custom` could be another type that **takes in a C# source file** to use as the parser. This should allow for a completely customized parser!
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Loading…
There is no content yet.