Open TheGoodIdeaFairy opened 2 years ago
Digging into the code it looks like the JoystickCondition class eventually calls DILL._dll.get_button(), which I assume is polling the physical device rather than the recorded state... I haven't been able to track down what happens after el.joystick_event.emit() in macro.py, but I'm assuming there is a JG managed structure that holds the current state of the buttons, etc.
Unless I'm missing something, this looks like it would be a massive change to alter the way this works, and a separate plugin for a different approach to evaluating Joystick-State Conditions would be the better solution here. I could use some pointers to the name and/or location of the data struct that holds the state of the buttons and axes.
The typical way to get joystick state information is via the JoystickProxy
class which returns JoystickWrapper
instances which cache device state information based on the events Gremlin receives. The reason this is not used for conditions is that this cache is updated using the same information that triggers callbacks. This runs on top of QT's signal and slot mechanism which does not guarantee an execution order of callbacks. Thus, there is no guarantee that the cached device state reflects the true device state.
In fact, it is almost surely never true as a common issue people run into is using the Joystick Condition for released actions on the input being pressed, which effectively always fails and is one of the reasons the "This (virtual) button" condition exists.
If you set an action to activate only when a Joystick button is activated, then activate that Joystick button via a macro rather than using the physical button, the condition does not recognize that the Joystick button has been activated.
Expected behavior is Joystick buttons activated via macro behave the same as physically activated Joystick buttons.