I can tell you what I did, which works for me in 3D and so should work for you in 2D.
What I do is, first take my InputAxis floats and make them into a vector (for you, as Z and Y, since they control up/down/left/right rather than front/back/ left/right) Then I do a vector length check and feed it to a Select Vector node; if the length = 0, I use a vector of 0,0,0, otherwise I normalize the vector created by the inputs (thus, the stick vector can only either be a unit vector in any direction, or a 0 vector).
Now from here, I do some complicated math which generates a reference frame based on the character’s rotation (i.e. if he’s facing 8° left of center, the 8-way direction quantization needs to be within that reference frame)
but for you, you can skip that step and go right to the fun vector math!
Assume, for the purposes of a 2D game, that X = depth axis (i.e. foreground to background), Y = travel axis (i.e. left to right), and Z = vertical axis.
Get ATan2 Degrees, where the A input is fed by the float “1” (technically this would be a magnitude value but your magnitudes are 1 because all of your vectors are unit normalized) and the B input is fed by the dot product of your input vector and the vector 0,1,0 (i.e. Forward). This gives you the angle between your two vectors. Next, get the cross product of 0,1,0 and your input vector (in that order), get the dot product of the result and the vector 1,0,0 (the plane your inputs exist on), and take the “Sign” operation on that and multiply it by the float from the first part. This is the (positive or negative) degrees difference between your input direction and “Forward”.
The last step is to run two separate checks; first, if the input vector is equal to “0,-1,0”, swap the output above (using a select float) for “-180” (the original math will sometimes treat this exactly parallel opposite angle angle as 0 rather than 180 or -180, this catches that). Second, if the inout vector has a LENGTH of “0”, swap the output for something arbitrary and impossible based on the above math (I like to use 720). This “impossible angle” (outside of one complete rotation) is a placeholder for “no input”.
Now, take this float, which should go from -180 to 180 and then also include 720, and divide it by 45, run a round operation, and then multiply the resulting output by 45. This should quantize the input vector into discrete 45° steps (and 720°, which remember indicates no input).
Finally, you do some Array checking. IF the Input Array has a length of 0 AND the input vector length is nonzero, you want to start your Array-Clearing timer (0.25s or whatever) and add the Int from your vector math to the Input Array. Otherwise get the value in the Input Array at the index defined by Length - 1 (i.e. the last value), and IF the Int from your vector math is NOT equal to this value, add it to your array and reset the Array-Clearing timer
This way, every tick, the game listens to your inputs, which are defined by 8 discrete angles (and one value for NULL). Once you press something, it listens for another value which is not the same as the current one, so you don’t update the array every tick with identical presses.
The trick to using this well is to print the outputs it generates and watch the print log as you perform input sequences. For example, a shoryuken would probably not be possible with “0, -90, -45”; it would probably require (or at least often yield) “0, 720 (NULL), -90, -45”. Forward-Forward isn’t “0, 0”, it’s “0, NULL, 0”. Etc. this way, you can trigger the same “input” twice even though the tick-countering logic demands a value CHANGE before registering it.
You also need to make sure you check your values against the player rotation; this way you can either modify them or check for separate input strings when he’s facing the opposite way.
Hope this helps