alphappy
commented
2 weeks ago Frontend design would most likely involve specifying the vector directional input directly. For instance, (70,-50)J would send a package with x=0.7, y=-0.5, jmp=True.
The actual input sent may not reflect what a macro author writes in the case of vectors exceeding unit magnitude. For instance, (100, 55) exceeds unit magnitude (114.1%) and would be scaled down to about (87.62, 48.19). Both vectors still have the same direction. However, the latter vector falls into the default vertical deadzone, and only a RIGHT digital input would be sent without UP, despite a possible expectation from the macro author that the line should send an UP input since the y exceeds 50%.
As such, it might be worth supporting specifying the polar coordinates of the directional input instead. This could look something like {35.53,86.02}J, which would be roughly equivalent to (70,-50)J.
{35.53,86.02}J presents direction as a conventional angle with 0 pointing rightward and increasing counter-clockwise. It would be reasonable to support switching the notation to, e.g., meteorological convention of 0 being upward and increasing clockwise.
On the backend, care needs to be taken to make sure that digital inputs are always set as expected, which may require an IL hook.
Add support for analog input beyond fastroll.