Legacy GM 8-Directional attacking

[Blaize]

EDIT: I changed the title from 'Attacking while moving' to the new one since it didn't make sense to me after reading it back.
So, I've just started sorting my move and attacking into two states and for the most part, they work fine. Actually, I can attack up, down, left, right, up-right, and down-left (essentially when both x and y values are different).
The problem is when both x and y have the same value (up-left and down-right) when I press the attack key, my guy doesn't go into the attack state.

Here's my code:

///StateMain()
GetInput();

var horiz = Right - Left;
var vert = Down - Up;

if (horiz > 0)
    PlayerDir = 0; //determines which sprite to draw
else if (horiz < 0)
    PlayerDir = 2;

if (vert > 0)
    PlayerDir = 3;
else if (vert < 0)
    PlayerDir = 1;

sprite_index = vCharacterIdle;
image_index = PlayerDir;

if (Attack_)
{
    CurrentState = States.Attacking;
}

What's going on?

 

[T. Brugel]

Hey there!
For me to help you I would have to see some more of your code. For example, what is the Attack_ variable?
Could you also show me the attack script?
Cheers and goodluck!

 

[Blaize]

Hey there!
For me to help you I would have to see some more of your code. For example, what is the Attack_ variable?
Could you also show me the attack script?
Cheers and goodluck!

The Attack_ variable is a keypress, and at this point, the Attack script just has an animation playing (pretty bare).

///StateAtk
image_speed = 0.25;
sprite_index = AtkDir[PlayerDir];

EDIT: I also have an Animation End which sets the state back to the regular/base state after the attack animation ends.
All of this is controlled by a switch statement in the player's Step event.

 

[T. Brugel]

Hey there!
I can remember that I had the same problem as well some time.
I could not figure out the case so I changed my attack system just a little bit.
I made a switch statement in the attack script which checks the facing of the player.
Based on this it chooses which attack sprite to use.
I stored the facing of the player in a simple variable temporary variable called: dir.
This worked fine for me and I did not experience any problems with this method.
You might want to give it a try.
Cheers and goodluck!

 

[Blaize]

Hey there!
I can remember that I had the same problem as well some time.
I could not figure out the case so I changed my attack system just a little bit.
I made a switch statement in the attack script which checks the facing of the player.
Based on this it chooses which attack sprite to use.
I stored the facing of the player in a simple variable temporary variable called: dir.
This worked fine for me and I did not experience any problems with this method.
You might want to give it a try.
Cheers and goodluck!

Well that's what my attack script does at the moment, except it chooses a sprite based on the dir (stored in an array). But that's beside the issue. The issue is that when my character's x,y (edit: input values) are -1,-1 or 1,1, even if I press the attack key it doesn't go into that state. On the flip side, when the direction values are not the same, it'll go into the attack state no problem.
For the benefit of those who don't quite understand it, my problem is this (see image)

 

[Blaize]

Ok, so I just wanted to update the situation.
I've added a debug check in the StateMain() script when checking for the attack pressed so it looks like:

///StateMain()
GetInput();

if (Attack_)
{
    show_debug_message('pressed attack button'); //to see if I actually go into the state at all
    image_index = 0;
    CurrentState = States.Attacking;
}

And sure enough, the debug message appears in all input cases except for when my x-axis and y-axis values are the same (i.e, 1,1 and -1,-1). I seriously don't get this at all.

UPDATE:
My original attack code was:

Attack_ =  keyboard_check_pressed(vk_space);

At first I thought that using vk_space was the problem.
After changing it to a vk_lcontrol it worked perfectly - the bug was gone! Tested it again, this time with vk_enter and the problem was back - not a fix...what's going on here?