When #409 is resolved with a pull request, the node interfacing with the Pro Controller will become very complex. It could probably use some form of refactoring to make it easier to extend in the future.
The biggest cause of the complexity is the not quite optimal abstraction we have for the concept of controller modes and controller mappings.
A potential option to simplify the abstraction is to have an interface that represents a keyboard mapping. It would have functions for each button, similar to the current implementation of the Pro Controller node. Functions that would behave the same in most nodes can then be made default functions under the interface. Then for each mode, one would write a class that implements the interface and does the appropriate things based on the button presses. Then within the main node, one would instantiate the available modes and store them in a collection, and based on the current mode, the appropriate instance will be invoked.
When #409 is resolved with a pull request, the node interfacing with the Pro Controller will become very complex. It could probably use some form of refactoring to make it easier to extend in the future.
The biggest cause of the complexity is the not quite optimal abstraction we have for the concept of controller modes and controller mappings.
A potential option to simplify the abstraction is to have an interface that represents a keyboard mapping. It would have functions for each button, similar to the current implementation of the Pro Controller node. Functions that would behave the same in most nodes can then be made default functions under the interface. Then for each mode, one would write a class that implements the interface and does the appropriate things based on the button presses. Then within the main node, one would instantiate the available modes and store them in a collection, and based on the current mode, the appropriate instance will be invoked.