kimimaru
/
TRBot
2
2
Fork 1
Code Issues 14 Pull Requests Projects 1 Releases 13 Activity
Labels Milestones
New Issue

Support for more types of inputs #93

Open
opened 6 months ago by kimimaru · 3 comments
kimimaru commented 6 months ago
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
kimimaru commented 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.
kimimaru commented 3 months ago
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`.
kimimaru commented 3 weeks ago
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 Branch/Tag Specified
Branches Tags
NET6Upgrade
ReadExternalEvents
ReworkInvalidInputCombos
SyntaxTutorialUpdate
develop
master
Labels
Apply labels
Clear labels
bug
Something isn't working CI
Tasks regarding Codeberg Continuous Integration critical
Critical bug or issue that needs to be addressed as soon as possible documentation
Concerns documentation duplicate
This issue or pull request already exists enhancement
New feature or request good first issue
Good for newcomers help wanted
Extra attention is needed high priority
Higher priority issues that aren't critical but take precedence over other issues invalid
This doesn't seem right low priority
Low Priority Issues meta on hold
Will be revisited at a later date ongoing
Concerns work that persists over longer periods of time question
Further information is requested refactor
Primarily involves heavy code refactoring service
New service or a problem specific to one wontfix
This will not be worked on
No Label bug CI critical documentation duplicate enhancement good first issue help wanted high priority invalid low priority meta on hold ongoing question refactor service wontfix
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Depends on
#80 Reconsider refactoring the InputHandler to use Tasks
kimimaru/TRBot
Write Preview
Loading…
Cancel
Save
There is no content yet.
Delete Branch '%!s(MISSING)'

Deleting a branch is permanent. It CANNOT be undone. Continue?

No
Yes