path rotating and arguments

[Wild_West]

I'm trying to make board movement using paths and I want to rotate it based on the object's current direction input.
Problem is the direction values for path_rotate are different than the ones for direction, and I tested them all but for some reason I can't get it straight.

direction 90 made me go down on the path

direction 270 made me go left

direction 180 made me go right

and then direction right also made me go right.

what are the correct values for path_rotate?

 

[jo-thijs]

path_rotate replaces the path with a rotated version of it.
Your path originally goes to the left.
Rotating it 90 degrees makes it go down.
Rotating it 270 degrees undoes the effects of the 90 degree rotation, making the path go left again.
Rotating it 180 degrees then makes it go right.
Rotating it 0 degrees doesn't change it and leaves the path going right.

The problem probably is that path_rotate adds the new rotation to the path where expect it to set the rotation to what you give.

 

[Wild_West]

path_rotate replaces the path with a rotated version of it.
Your path originally goes to the left.
Rotating it 90 degrees makes it go down.
Rotating it 270 degrees undoes the effects of the 90 degree rotation, making the path go left again.
Rotating it 180 degrees then makes it go right.
Rotating it 0 degrees doesn't change it and leaves the path going right.

The problem probably is that path_rotate adds the new rotation to the path where expect it to set the rotation to what you give.

ah okay I see now, thanks.
They explained it in the manual but not as much as I guess I needed.

One more question if I could?
Since I was waiting for a reply I figured I may as well try a work around so I tried a dynamic approach and went for the idea of just creating path points equal to the number input for how many spaces to move on the board using a switch, but my object didn't move at all.

    switch(direction)
    {
      case 90  : 
                 path_add_point(pawn_move_path, x, y -64 *spaces_moved, 1);
                 path_start(pawn_move_path, 4, path_action_stop, false);
                 is_selected = false; 
                 image_index = 0;
                 spaces_moved = 0;
                 path_delete_point(pawn_move_path, 0 + spaces_moved);
      break;
      //-----------------------------------------------------------------------      
      case 270 : 
                 path_add_point(pawn_move_path, x, y +64 *spaces_moved, 1);
                 path_start(pawn_move_path, 4, path_action_stop, false);
                 is_selected = false; 
                 image_index = 0;
                 spaces_moved = 0;
                 path_delete_point(pawn_move_path, 0 + spaces_moved);
      break;
      //------------------------------------------------------------------------      
      case 180 : 
                 path_add_point(pawn_move_path, x -64 *spaces_moved, y, 1);
                 path_start(pawn_move_path, 4, path_action_stop, false);
                 is_selected = false; 
                 image_index = 0;
                 spaces_moved = 0;
                 path_delete_point(pawn_move_path, 0 + spaces_moved);
      break; 
      //-------------------------------------------------------------------------
      case 0   : 
                 path_add_point(pawn_move_path, x +64 *spaces_moved, y, 1);
                 path_start(pawn_move_path, 4, path_action_stop, false);
                 is_selected = false; 
                 image_index = 0;
                 spaces_moved = 0;
                 path_delete_point(pawn_move_path, 0 + spaces_moved);
      break;  
    }

 

[jo-thijs]

My guess would be because you're deleting points from the path directly after you've added some and started following it.
This can mess with the objects following the path. I'm not sure how it works though.

If I'm being honest, it sound like you're using paths for something you should not be using paths for.
Why don't you just set hspeed and vspeed at the correct times?

 

[Wild_West]

My guess would be because you're deleting points from the path directly after you've added some and started following it.
This can mess with the objects following the path. I'm not sure how it works though.

If I'm being honest, it doesn't sound like you're using paths for something you should not be using paths for.
Why don't you just set hspeed and vspeed at the correct times?

I haven't tried those yet just because I figured it'd be harder to set the stop point, since I'd need friction and there's gonna be a bunch of other pieces on the game board, so hey can't be colliding like they have physics.
Plus I could use the practice getting familiar with some new function uses.

I've got the movement perfect without the path_delete_point but only for the first try, after that the next path points I input get connected to the first and f course that's no good which is why I thought just deleting them after the piece was done moving would be fine..

 

[Wild_West]

I tried using this line to wait until the path was done to delete the newly added points but it's stopping , then the object's direction actually reverses and it moves backward on the path, with no points removed.
1 does mean end of path like the manual said, so I don't get why this is happening.
But if I can fix the reverse problem and get rid of the points after moving it'll be where I need it.

if(path_position == 1){ path_delete_point(pawn_move_path, spaces_moved); path_end(); }

The rest of the switch from earlier is the same I just added this right under path_start

 

[Wild_West]

Okay so the reversing thing was just me forgetting to uncheck the "close path" option. that's why it kept thinking the end point was actually the start point.

So now the object stps where it should but the path points aren't getting deleted when it's done moving like I need.

I moved this to the step event :

if(path_position == 1){ path_delete_point(pawn_move_path, spaces_created); path_end(); }

 

[Wild_West]

Okay sorry final update :

The object is moving right, and I've got the path points being cleared, I think. I mean I drew them out and can see them reset when they should, except the only problem left I just can't seem to sort out is that when I complete the path I can't seem to move the object with it's new path direction only. It still moves the same as the first path direction I do, and then the new one gets added onto the first, making it go diagonal.

So I need a way to actually get rid of the old path points so they don't just attach to the old one.
if that's the problem and I'm not missing anything else.

This is the full obj code as it is now.

Information about object: pawn_object
Sprite: sprite0
Solid: true
Visible: true
Depth: -100
Persistent: false
Parent:
Children:
Mask:

No Physics Object
Create Event:

execute code:

///Pawn piece Variables

image_speed = 0;

is_selected = false;
spaces_moved = 0;

spaces_created = path_get_number(pawn_move_path);;

Step Event:

execute code:

///spaces to move in once a direction has been set, after selecting this piece

if(is_selected)
{
  image_speed = 0.1;


//direction of movement to set the piece to when it starts moving
if( keyboard_check_pressed(vk_right) ){direction =   0;}
if( keyboard_check_pressed(vk_left ) ){direction = 180;}
if( keyboard_check_pressed(vk_down ) ){direction = 270;}
if( keyboard_check_pressed(vk_up   ) ){direction =  90;}


//Movement input
if(keyboard_check_pressed( ord("0") ) ){spaces_moved = 0;}
if(keyboard_check_pressed( ord("1") ) ){spaces_moved = 1;}
if(keyboard_check_pressed( ord("2") ) ){spaces_moved = 2;}
if(keyboard_check_pressed( ord("3") ) ){spaces_moved = 3;}
if(keyboard_check_pressed( ord("4") ) ){spaces_moved = 4;}


spaces_created = path_get_number(pawn_move_path);


    switch(spaces_moved)
    {
      //Number of spaces
      case 0  : spaces_moved = 0;  break;
    
      case 1  : spaces_moved = 1;  break;
    
      case 2  : spaces_moved = 2;  break;
    
      case 3  : spaces_moved = 3;  break;
    
      case 4  : spaces_moved = 4;  break;
    
      default :  show_message("Pawns can only move 4 spaces at a time");  break;
    }

//-------------------------------------------------------------------------------------------------


  if(path_position == 1)
  {
    path_delete_point(pawn_move_path, spaces_created - 1);
    path_position = 0;//"The new position your on in-path is now seen as 0, not 1 for when the new path starts." 
  }
}else{ image_speed = 0; image_index = 0; }

Mouse Event for Left Button:

execute code:

///click on the piece you wish to move


move_piece = show_question("Move this piece");

if(!move_piece){exit;}else
{ show_message("Hold UP, DOWN, LEFT or RIGHT to choose a direction,
                then input the number of spaces you'd like to move this piece. (Max = 4)");
              
    is_selected = true;//This piece can move with the inputs given now
}

Draw Event:

execute code:

draw_self();

draw_set_font(font0);
draw_text(view_xview, view_yview, "Path Points = " +string(spaces_created) );
draw_text(view_xview, view_yview+50, "Movement = " +string(spaces_moved) );
draw_text(view_xview, view_yview+100, "Path Angle = " +string(direction) );
draw_text(view_xview, view_yview+150, "Path Position = " +string(path_position) );

draw_path(pawn_move_path, x, y, true);

Key Release Event for <Space> Key:

execute code:

///Move the piece after deciding on a direction and number
  
if(is_selected)
{
  
    {
        switch(direction)
        {
          case 90  :
                     path_add_point(pawn_move_path, x, y -64 *spaces_moved, 10);
                     path_start(pawn_move_path, 10, path_action_stop, false);
          break;
          //--------------------------------------------------------------------------------------------------- 
          case 270 :
                     path_add_point(pawn_move_path, x, y +64 *spaces_moved, 10);
                     path_start(pawn_move_path, 10, path_action_stop, false);
          break;
          //-----------------------------------------------------------------------------------------------------   
          case 180 :
                     path_add_point(pawn_move_path, x -64 *spaces_moved, y, 10);
                     path_start(pawn_move_path, 10, path_action_stop, false);
          break;
          //-----------------------------------------------------------------------------------------------------
          case 0   :
                     path_add_point(pawn_move_path, x +64 *spaces_moved, y, 10);
                     path_start(pawn_move_path, 10, path_action_stop, false);
          break; 
        }
    }
}

 

[jo-thijs]

So, you want to replace this:

    path_delete_point(pawn_move_path, spaces_created - 1);

by this?

    path_delete_point(pawn_move_path, 0);

However, I'm still thinking you should not be using paths here.

What is it you're trying to do exactly?

 

[Wild_West]

So, you want to replace this:

    path_delete_point(pawn_move_path, spaces_created - 1);

by this?

    path_delete_point(pawn_move_path, 0);

However, I'm still thinking you should not be using paths here.

What is it you're trying to do exactly?

I was trying to just add the needed points in the needed direction of movement so I don't have to make a dozen and one different paths for each game piece's movement.

It would start with a single point, located wherever the game piece was at the time, and then based on the direction and number input by the player the path points would be created, and destroyed after the game iece had finished it's move. allowing the path to be blank again for next turn with new inputs.

But it wasn't working and I didn't think path_delete with path_add was a good idea.
So I just scrapped it and went with manual control afterall.
I mean I wanted automatic but I couldn't figure out how to get the knight or bishop piece to move right with lengthdir_x and y

 

[Yal]

Try drawing the path you created using path_draw()... getting visual feedback on things like this is a LOT more useful than trying to figure it out by iterative testing. If you can, also store all points you WANT to create path points at and draw lines between those (in a different color)... if they don't overlap with the path, something is wrong... and HOW they don't overlap should give you clues, e.g. if they start off close but deviate more and more for each point, your method of finding the next point is inaccurate.

 

[jo-thijs]

So, you're creating chess game?
I don't know why you would need lengthdir_x and lengthdir_y.
Is there ever a situation in which you need to move in 2 directions one directly after the other?
I don't think that's ever the case for chess.

 

[Wild_West]

So, you're creating chess game?
I don't know why you would need lengthdir_x and lengthdir_y.
Is there ever a situation in which you need to move in 2 directions one directly after the other?
I don't think that's ever the case for chess.

well for the knight, I mean you know how it moves, but I was trying to get it not to just snap to the new location.

 

[Wild_West]

Try drawing the path you created using path_draw()... getting visual feedback on things like this is a LOT more useful than trying to figure it out by iterative testing. If you can, also store all points you WANT to create path points at and draw lines between those (in a different color)... if they don't overlap with the path, something is wrong... and HOW they don't overlap should give you clues, e.g. if they start off close but deviate more and more for each point, your method of finding the next point is inaccurate.

I was drawing the path and points already but I only ever saw 2. One on the first point where my object started and one way up in the 0,0 corner of the room.

Probably my draw code's issue, but it doesn't matter now I guess since I gave up on the way I was trying to do the movement in favor of the simpler approach.

 

[jo-thijs]

Using paths, I don't see the issue.
Using hspeed and vspeed, you can just do:

var tx = ...; // x coordinate to move to
var ty = ...; // y coordinate to move to
var dx = tx - x;
var dy = ty - y;
var d = spd / sqrt(dx * dx + dy * dy);

hspeed = dx * d;
vspeed = dy * d;

 

[Wild_West]

Using paths, I don't see the issue.
Using hspeed and vspeed, you can just do:

var tx = ...; // x coordinate to move to
var ty = ...; // y coordinate to move to
var dx = tx - x;
var dy = ty - y;
var d = spd / sqrt(dx * dx + dy * dy);

hspeed = dx * d;
vspeed = dy * d;

And if I were any kind od decent at math that would've come to me.

 

[Yal]

I was drawing the path and points already but I only ever saw 2. One on the first point where my object started and one way up in the 0,0 corner of the room.

Or the first point is correct, and all the other points has coordinates (0,0), but since they overlap you only see a single point.

 

[Wild_West]

Or the first point is correct, and all the other points has coordinates (0,0), but since they overlap you only see a single point.

That could've been it but then why would they be spawning at that point rather than the spots I specified with path_point_add( x + 64 * spaces_moved, y); ?
I remember I did see the lines from draw_path appearing , well sort of in the right areas.

My draw code looped through the path_length starting at 0 because I didn't know what arguments to put in, which I'm guessing is what led to the place the path points were on.

 

[Yal]

That could've been it but then why would they be spawning at that point rather than the spots I specified with path_point_add( x + 64 * spaces_moved, y); ?

Hard to tell without knowing what x, spaces_moved and y are for each point... if all are zero, of course the points will be added at (0,0). Try writing some show_debug_message() messages to display those for each step.