Changing Views for Walkable Areas

[bauldur_rises]

Hi everyone,

I have room with a stair case in the middle running from left to right, and when the player walks down it it looks a little awkward when they face up or down. I've creates a second walkable area on the stairs and am trying to use the following code to chance his view to a new one with only left and right facing sprites:

Code: ags

function room_RepExec()
{
if ((player.NormalView == 2)&&(GetWalkableAreaAt(player.x, player.y)==2))
  {
    player.ChangeView (92);
  }
if ((player.NormalView == 92)&&(GetWalkableAreaAt(player.x, player.y)!=2))
  {
    player.ChangeView (2);
  }
}

However, no change is apparent in the room when he walks in the given area - he stays at view 2.

Does anyone have any solutions?  Thanks.

[dayowlron]

Is this a scrolling room? that could throw off the coordinates you are passing into GetWalkableAreaAt.
Just grasping at straws, not sure if that matters or not.
something you could do is put a gui on the screen with 2 labels on it and set one label to the player.NormalView and the other one to Get... call and see where the code is breaking down. looks to me like it should work.

Code: ags

function room_RepExec()
{
if ((player.NormalView == 2)&&(GetWalkableAreaAt(player.x, player.y)==2))
  {
    player.ChangeView (92);
  }
if ((player.NormalView == 92)&&(GetWalkableAreaAt(player.x, player.y)!=2))
  {
    player.ChangeView (2);
  }
label1.Text = player.NormalView;
label2.Text = GetWalkableAreaAt(player.x, player.y);
}

[Cassiebsg]

You could try and change it to a region, maybe?

[bauldur_rises]

Cassiebsg - That works!  Thank you very much.

dayowlron - I saw Cassiebsg's first and did that, so sorry I didn't try yours...

For anyone who cares, this is the script I used:

Code: asg

function room_RepExec()
{
if ((player.NormalView != 92)&&(Region.GetAtRoomXY(player.x, player.y)== region[1]))
  {
    player.ChangeView (92);
  }
if ((player.NormalView == 92)&&(Region.GetAtRoomXY(player.x, player.y)!= region[1]))
  {
    player.ChangeView (2);
  }
}

[edit] Also, in case you were wondering, it is a scrolling room.

[Crimson Wizard]

As noted in manual, GetWalkableAreaAt requires SCREEN coordinates, while player.x/y is ROOM coordinates.
(For historical reasons there is a strange inconsistency between getting region, walkable area and some other objects by coordinates, some require room coordinates and others screen coordinates)

Converting ROOM->SCREEN coordinates is done by subtracting GetViewportX() and GetViewportY() from x and y room coordinates.
Converting SCREEN->ROOM coordinates is done by adding GetViewportX() and GetViewportY() to screen coordinates.

For example, in your case code for using walkable areas would be:

Code: ags

int screen_x = player.x - GetViewportX();
int screen_y = player.y - GetViewportY();
if ((player.NormalView == 2)&&(GetWalkableAreaAt(screen_x, screen_y)==2))
  {
    player.ChangeView (92);
  }
if ((player.NormalView == 92)&&(GetWalkableAreaAt(screen_x, screen_y)!=2))
  {
    player.ChangeView (2);
  }

[monkey0506]

Unrelated to the issue at hand, but as a matter of logic/style, you should avoid explicitly checking the same thing more than once, especially if a function call is involved. In the same way that CW stored the screen_x and screen_y variables, you should consider storing the walkable area ID or Region*, instead of manually reinspecting the exact same thing. And using else will prevent you having to check the same condition with an inverted operator (that counts as a form of code duplication, and is generally frowned upon). I also recommend using the view names instead of hard-coded view numbers. You can always rename the views if they need to be rearranged for some reason, but if you hard-code their values then you would have to update all of your scripts. Using the names also makes your scripts more legible, which will be helpful six months from now when you've forgotten which view "92" is.

Code: ags

// using walkable areas
function room_RepExec()
{
  int screen_x = player.x - GetViewportX();
  int screen_y = player.y - GetViewportY();
  int walkable_area = GetWalkableAreaAt(screen_x, screen_y);
  if (walkable_area == 2)
  {
    if (player.NormalView == VEGO_NORMAL)
    {
      player.ChangeView(VEGO_LEFTRIGHT);
    }
  }
  else if (player.NormalView == VEGO_LEFTRIGHT)
  {
    player.ChangeView(VEGO_NORMAL);
  }
}

Code: ags

// using regions
function room_RepExec()
{
  Region *rat = Region.GetAtRoomXY(player.x, player.y);
  if (rat == region[1])
  {
    if (player.NormalView == VEGO_NORMAL)
    {
      player.ChangeView(VEGO_LEFTRIGHT);
    }
  }
  else if (player.NormalView == VEGO_LEFTRIGHT)
  {
    player.ChangeView(VEGO_NORMAL);
  }
}

While this probably won't impact your specific use-case here, it will make your code overall easier to read and (marginally) more efficient.

[Cassiebsg]

Okay, when I suggested to use regions, I was thinking of the regions events: walks off, walks on, while standing, to change the views and avoid to have it on RepExec...
But glad it's working.

[Crimson Wizard]

Okay, when I suggested to use regions, I was thinking of the regions events: walks off, walks on, while standing, to change the views and avoid to have it on RepExec...
But glad it's working.

I found the issue when using walk on/off region events. The problem is that these events are not called when character walks in blocking mode or if "Wait" is called in a loop inside another script function. They only work if character is walked non-blocking by player's command. This makes these events impractical if you are also playing cutscenes in the same room, during which the character may cross regions.

[Cassiebsg]

I found the issue when using walk on/off region events. The problem is that these events are not called when character walks in blocking mode or if "Wait" is called in a loop inside another script function. They only work if character is walked non-blocking by player's command. This makes these events impractical if you are also playing cutscenes in the same room, during which the character may cross regions.

Yes, I've noticed that, rather annoying, as I'm using that to open/close doors on my game, there's still one "bug" I haven't ironed out due to this annoyance... Not to mention npcs don't trigger regions.