-
Notifications
You must be signed in to change notification settings - Fork 671
Support multiple DS backends for generated gamepad classes #8376
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
base: 2027
Are you sure you want to change the base?
Conversation
|
This PR modifies commands. Please open a corresponding PR in Python Commands and include a link to this PR. |
|
Why does the gamepad code care if a button press came from one DS software or another? (TBH, this kinda smells of abstracting at the wrong layer.) |
|
The old DS doesn't have the same mappings as a new DS. And at least for the time being, we need to support both. Because theres no standard to what the NI DS outputs, we can't do anything at a lower layer. |
|
I think we should keep overloads taking int indexes; teams using one DS won't care about the indexes in the other and shouldn't have to pass a parameter that's irrelevant to them. Do we have usage reporting of people using GenericHID directly (by index) rather than using the subclasses with named buttons? |
|
I actually can't keep the indexer ones around for a lot of the things. Because the enum is the key into the dictionary so the system can keep track of which buttons have events on them. The only way to really make it work would be to make the key be "Object", but there might be other issues with that too. Would need to investigate. |
| if (DriverStation.isNiDs()) { | ||
| index = button.getNiIndex(); | ||
| } else { | ||
| index = button.getSdlIndex(); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- What should happen if the DS didn't connect yet? I have a feeling this is going to cause a lot of issues, similar to the alliance color issues in the past.
- Is defaulting to SDL the desired behavior?
- This evaluation should be pulled up to somewhere, rather than littering it all over the code, for consistency (in defaults etc) and code dedup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- These functions are already broken if used before a DS has been connected. They'll return false anyway, it doesn't matter what index you set.
- Defaulting to SDL is the desired behavior.
- Yeah I'm planning on working on that.
|
So perhaps we could make a factory that returns a pair for a single value? |
WIP, still needs C++, and for the mappings to actually be made correct. Plus the op mode PR.