Character changing direction after animation

[fratello Manu]

Hi everyone!

My I'd like my MC to to play an animation in the proper direction (e.g. slash with a sword, give a punch, atishoo.... whatever!) when I press the right mouse button, while using a custom mouse mode. Left button will be for walking around.
So I defined my custom mode (let's say: Fight mode)  and I created 2 views: the first of character walking (with the 8 loops for the standard directions as usual), and the second with 8 animations for the Fight mode as well.
For some reason I don't understand, I can't get the character to face the proper direction, before animating, when pressing just the right mouse button.

E.G.

1. LB click, Player walks left
2. RB click, with cursor still at left side of character: Left fight animation is played (correct)
3. I move the mouse cursor at the right side of character and I press RB: still left fight animation is played (wrong!)
4. I move the character right (with LB) and then I press RB: right fight animation is played (correct)

I tried in several ways, with Player.Loop to catch its current direction, or with .Direction as well, but I can't fix it.

Here is an example on one of my attempts.
View 6 is for walking, and 10 for fighting:

Code: ags

function on_mouse_click(MouseButton button)
{
 
  if (IsGamePaused())
  {
    return;
  }

  if (button == eMouseLeft)
  {
    // if in fight mode, left click just has to move player:
    if (mouse.Mode == eModeUseWeapon)
    {
      Room.ProcessClick(mouse.x, mouse.y, eModeWalkto);
    }
    else
    {
      Room.ProcessClick(mouse.x, mouse.y, mouse.Mode);
    }
  }

  else if (button == eMouseRight)
  {

    if (mouse.Mode != eModeUseWeapon)
    {
      SetWalkToMode();  // a custom function which sets walk-to mode
    }
    else

    // In weapon-on mode, right-click = attack
    {

      MyPlayer.LockView(10, eStopMoving);
      MyPlayer.FaceLocation(mouse.x,  mouse.y, eNoBlock);
      int currentDirection = MyPlayer.Loop;
      
      MyPlayer.Animate(currentDirection, 1, eOnce, eBlock, eForwards);
      MyPlayer.UnlockView(eStopMoving);

    }
  }
}

For some reason, it seems that  MyPlayer.FaceLocation(mouse.x,  mouse.y, eNoBlock);  is not working (while in other contexts in game, of course it works).

Any suggestion?

thanks!

Manu

[Matti]

From the manual:

"If the character has Turning enabled (ie. the "Characters turn to face direction" game option is turned on, and the character does not have the "Do not turn before walking" option checked), then the character will turn on the spot in order to face the new direction. In this case, the BlockingStyle parameter determines whether the script waits for the character to finish turning (eBlock, the default) or whether the script continues immediately and the character finishes turning later on (eNoBlock).

If the character does not have Turning enabled, he will immediately turn to face the new direction and the BlockingStyle parameter has no effect. In this case, the screen will not be refreshed straight away -- if you want to see the character facing his new direction immediately, call Wait(1);"

Might one of these issues be the case? That the screen doesn't refresh or the script continues before the character has time to turn?

[Crimson Wizard]

the script continues before the character has time to turn?

This might be happening, as turning is done with eNoBlock, immediately followed by blocking Animate. Either make turning Blocking, or use Wait(n) to wait before starting an animation.

[Khris]

Also, you can use  player  to refer to the current player character, in case your game switches between multiple characters. It's good practice to always use  player.

Here's the revised part:

Code: ags

      player.LockView(10);
      player.FaceLocation(mouse.x,  mouse.y, eBlock);
      player.Animate(player.Loop, 1, eOnce);
      player.UnlockView();

[fratello Manu]

Guys, first of all thanks anyone for helping. Unfortunately, I didn't fix it yet...

Adding a Wait(1) or even more, I didn't solve, it was exactly the same.

I also already tried like this, before posting:

Code: ags

player.LockView(10);
player.FaceLocation(mouse.x,  mouse.y, eBlock);
player.Animate(player.Loop, 1, eOnce);
player.UnlockView();

Behaviour is different but still wrong (with eBlock): player always turns UP before animating...

So, with eNoBlock option it seems slightly better (at least MC faces the proper direction). But in both cases, the FaceLocation statement seems not to work

any idea?

Thanks!

Bye! Manu

[eri0o]

Does this room scrolls? (Is it bigger than the game screen?) I ask because FaceLocation uses Room coordinates and not screen coordinates.

[Crimson Wizard]

Behaviour is different but still wrong (with eBlock): player always turns UP before animating...

So, with eNoBlock option it seems slightly better (at least MC faces the proper direction). But in both cases, the FaceLocation statement seems not to work

There's "Characters turn to face direction" option in General Settings. If it's on, then turning is done over time, and with eNoBlock character should not be turning at all as you start animation immediately after.
If it's off, then character would instantly switch to final direction, but then you'd need to call Wait(1) to redraw the screen and see the effect before animation, as Matti quoted above. Also, in such case the player.Loop should have correct final destination after calling FaceLocation...
Unfortunatley, you did not mention what direction character was facing before you press the right mouse button. I am rather confused by the "character faces proper direction but FaceLocation does not work" (if it did not work, how it faces proper direction?).



Regarding why it may face wrong direction, for instance FaceLocation requires room coordinates, so proper use would be:

Code: ags

player.FaceLocation(mouse.x + Game.Camera.X,  mouse.y + Game.Camera.Y, eBlock);

(In pre-3.5.0 versions it's "mouse.x + GetViewportX(), mouse.y + GetViewportY()")


But another reason could be simply AGS facing logic not filling your expectations. As in - you click to the up-right from character, but it decides that the facing should be "up" rather then "right". In that case you may need to script your own math to decide which final direction to use.


Perhaps try commenting out Animate and experiment with character turning first?

[fratello Manu]

Does this room scrolls? (Is it bigger than the game screen?) I ask because FaceLocation uses Room coordinates and not screen coordinates.

YES! it is!

[fratello Manu]

Regarding why it may face wrong direction, for instance FaceLocation requires room coordinates, so proper use would be:

Code: ags

player.FaceLocation(mouse.x + Game.Camera.X,  mouse.y + Game.Camera.Y, eBlock);

I'll try! Thanks!

[eri0o]

You can also convert the coordinates (if you are using the newest versions of AGS) using

Code: ags

Point* room_point = Screen.ScreenToRoomPoint(mouse.x, mouse.y);
player.FaceLocation(room_point.x, room_point.y);

I actually haven't understood quite yet what's going on but other idea I would have is adding some offset in the y position to see if this fix FaceLocation. You can also write your own logic using FaceDirection. But I have trouble understanding text descriptions because I am a more visual person  .

[fratello Manu]

You can also convert the coordinates (if you are using the newest versions of AGS) using

Code: ags

Point* room_point = Screen.ScreenToRoomPoint(mouse.x, mouse.y);
player.FaceLocation(room_point.x, room_point.y);

I actually haven't understood quite yet what's going on but other idea I would have is adding some offset in the y position to see if this fix FaceLocation. You can also write your own logic using FaceDirection. But I have trouble understanding text descriptions because I am a more visual person  .

Great!  It works!!
Really thank you

[Snarky]

Perhaps try commenting out Animate and experiment with character turning first?

I cannot overemphasize what an important bit of advice this is. When something doesn't work, the first step should always be to break it down into the smallest parts possible to try to isolate the problem.