[Solved] Issues with Paths, Direction, and Animation

For context, I'm working on a top-down, tactics-style game. While the player is in battle, they pull up a menu, and to move, the player selects "Move" from the menu. From there, a grid selector is created, and each time the selector moves, it adds a new point to a created path. When the player has chosen its desired path, they hit "Enter," and the path from the selector object is copied over to the player object, and the player object follows that path.

The issue arises when the player objects animates while on the path. When traveling either up or left, there is no issue, i.e. the player object gets the correct sprite from the sprite index based on its direction variable. However, when traveling either down or right, it continually flips between down/up or right/left, i.e. the player's direction variable flips between the correct value and its 180 degree partner (e.g. 270 -> 90-> 270, etc; 0 -> 180 -> 0, etc.). I have no variables set other than the reading of direction to choose the right sprite for the player object:
Code:
    if (direction >= 316) || (direction <= 45) {sprite_index = spr_PlayerR;}
    if (direction >= 46) && (direction <= 135) {sprite_index = spr_PlayerU;}
    if (direction >= 136) && (direction <= 225) {sprite_index = spr_PlayerL;}
    if (direction >= 226) && (direction <= 315) {sprite_index = spr_PlayerD;}
I've also tried it where the above code only checks against directions of exactly 0, 90, 180, and 270 to set the player sprite. It seems to be some interaction between the path and the direction variable, but even attempting to set the direction variable manually (i.e. using something like an "if (x > xprevious) {direction= 0}" statement has proved ineffectual. I imagine that this particular solution could create issues if the player was able to move all the time, but given the tactics movement system, the player can only move one direction and only one of the cardinal directions (0, 90, 180, or 270) at a time. I'm also aware of the semi-solution of using image_xscale *= -1 to switch between left and right sprites, but that would not solve the up/down issue, and given they share a common root issue, I haven't applied that just yet.
 

NightFrost

Member
Value of direction is automatically set when following a path, but I don't remember when this happens. So, manually setting direction too early will just get overridden when automation updates it according to path movement. However, your direction detection will flip out when:
Code:
45 < direction < 46
135 < direction < 136
225 < direction < 315
in case there are some fractional parts in direction. I haven't played around with paths too much so I don't know if this could happen even if the path is supposedly axis-aligned, but it is worth checking by changing the second through third checks to start (plus else ifs so comparison terminates after first hit):
Code:
else if(direction > 45) ...
else if(direction > 135) ...
else if(direction > 225) ...
 
Value of direction is automatically set when following a path, but I don't remember when this happens. So, manually setting direction too early will just get overridden when automation updates it according to path movement. However, your direction detection will flip out when:
Code:
45 < direction < 46
135 < direction < 136
225 < direction < 315
in case there are some fractional parts in direction. I haven't played around with paths too much so I don't know if this could happen even if the path is supposedly axis-aligned, but it is worth checking by changing the second through third checks to start (plus else ifs so comparison terminates after first hit):
Code:
else if(direction > 45) ...
else if(direction > 135) ...
else if(direction > 225) ...
Awesome! Thanks very much! Will try this as soon as possible and report back.
 
It took some tinkering, but I did get to the root cause. The flips were occurring when the player object arrived at the exact coordinates of the grid system, so I thought it might be an issue of the path and the player object arriving at a new point on the path. After quickly whipping up a few lines of code (shown below), I thought my problem was solved:
Code:
repeat(obj_Player.movement_speed/32){
                    if (path_get_point_x(path_live,i) = path_get_point_x(path_live,i+1)) && ((path_get_point_x(path_live,i+1) = path_get_point_x(path_live,i+2))){path_delete_point(path_live,i+1)}
                    if (path_get_point_y(path_live,i) = path_get_point_y(path_live,i+1)) && ((path_get_point_y(path_live,i+1) = path_get_point_y(path_live,i+2))){path_delete_point(path_live,i+1)}
                }
This code smoothed out the number of points, leaving only those at the end points of contiguous lines and those that change the player direction. When this didn't work, I was forced to dive a little deeper. The flip problem was caused because of some code I used to align the player to the 32x32 grid. When the player arrived at the next 32x32 block, at those exact coordinates, the sprite would flip for a frame. Here's the gross code that I wrote that was causing the problem:
Code:
if (x - (32*round(x/32)) > 0) {
    x = x + (x - (32*round(x/32)));
    } else {}
if (x - (32*round(x/32)) < 0) {
    x = x - (x - (32*round(x/32)));
    } else {}
if (x - (32*round(x/32)) = 0) {
    } else {}
if (y - (32*round(y/32)) > 0) {
    y = y + (y - (32*round(y/32)));
    } else {}
if (y - (32*round(y/32)) < 0) {
    y = y - (y - (32*round(y/32)));
    } else {}
if (y - (32*round(y/32)) = 0) {
    } else {}
Though I'm still not sure exactly *why* this was causing it, I'm thrilled to have the major mystery solved. Thanks again for your help, NightFrost!
 
Top