walkable area that inverts the player's directions...

[AnasAbdin]

Hello,

I created a walkable area that I would like the player's movement be inverted when walked on, so instead of going north I want him to go south and so on..

[Mazoliin]

Add an on_mouse_click() function in the room script. In that check if the player is trying to walk while his on the region. If he is, call processClick with the inverted mouse co-ordinates.

To invert the co-ordinates just substract them from the screens height and width.
Say if your game is made in 320x200 resolution. Then, the inverted co-ordinates will be:

Code: ags

ProcessClick(320 - mouse.x, 200 - mouse.y, eModeWalktTo);

[AnasAbdin]

Thanx alot Mazoliin

I don't think this will help much, you see I haven't explained it very well...
my game resolution is 640,480. I wanna do a walk-behind-hills thing.. I looked in this forum alot, however, I found alot of complicated solutions for such an easy problem.

check this image first (please)


so I think a single walkable area is enough for now. which covers the far and near hills.
I have also created a walkbehind that covers the NEARER hills only, but it is deactivated (baseline at top) as long as the player is on the NEARER hills...

i created  hotspot 1, the red thin line, at the peaks of the nearer hills..
this is my logic:

if (character walks on red line)
{
  if (character is on the near hill)
  {
  invert his Y movement;
  activate walkbehind;
 }
 else
 {
 invert his Y movement back to normal;
 deactivate walkbehind;
 }
}

hot spot 2 (the yellow one) is used to toggle the player's view between normal scaling and a little one.

if ( player walkes on hot spot 2)
{
 if (player is normal size && his Y direction is inverted )
 {
    make him smaller;
    invert his Y movement back to normal;
  //walkbehind is still activated.. so he should go uphill the visible parts of the far hills..
 }
 if (player is tiny)
 {
    make him normal size;
   invert his Y movement;
  //walkbehind is still activated.. so he should go uphill from behind the NEAR hills..
 }
}

I created a couple of variable within the room's script to control the conditions of having crossed the red line (hot spot 1) or walked over yellow (hot spot 2) so no biggy here..

I am only stuck on the inverting the Y movement   I am not sure of the 480 - y part would work..


Edit:
listen.. I have just tried this:

instead of inverting the player's movement, I created a view with the player's up and down walk cycles inverted.. so I assign the new inverted view to the player instead of playing with his Y directions...
it worked fine, the only problem is the transition between being front or behind the nearer hills.. it causes alot of looping problems (infinite loops...) so I solved it by forcing the character to walk alittle bit (about 16 pixels) to a safe zone (not hotspots) location.. until now, this is the only problem I'm working on the  logic rocked 

[Khris]

I looked in this forum alot, however, I found alot of complicated solutions for such an easy problem.

First of all, this isn't an easy problem.

Now, as a general note, to react to where the player walks you shouldn't use hotspots, that's what regions are for. They already come with "walks onto" and "walks off" events in addition to the hotspots' "stands on", which is only included for backwards compatibility (older AGS versions didn't have regions).

Also, it's not necessary to use regions/hotspots to change a character's scaling, just use multiple walkable areas; they all have their own scaling settings.

The core of the problem here is the 2D nature of walkable areas vs. the 3D nature of the depicted ground. An elegant (but a bit complicated) way of solving this is using a transparent character and converting the click to an imaginary overhead view, having the dummy walk to the overhead coords and converting the movement back to the actual background.
There isn't any easy, straightforward way to pull this off convincingly; it always comes down to change the rules mid-walking.

[AnasAbdin]

First of all, this isn't an easy problem.

man I'm trying to simplify things as possible sometimes the solution is within reach but we think it's just too complicated!

Now, as a general note, to react to where the player walks you shouldn't use hotspots, that's what regions are for.

why not hot spots? I use them and they work perfectly? please enlighten me.

Also, it's not necessary to use regions/hotspots to change a character's scaling, just use multiple walkable areas; they all have their own scaling settings.

I know that every walkable area can have its own scaling level.. but since I'm using one walkable area... I decided to create an 80% tinier view of my character that is activated when he walks on a hotspot.

my single-celled brain didn't understand much of the transparent character theory  Khris.. could you please explain it more.

[Khris]

I'm sorry but you seem to be set to do things your own way regardless of what others tell you, why? It's a bit irritating. So please excuse me If I seem rude.

1. Calling something an easy problem doesn't make it an easy problem. Whether a problem is easy or not is of course highly subjective, but what you said was basically "I saw all those complicated solutions to a problem that should be simple because I want it to be, so I refuse to face the fact that it is much more difficult than I imagine".
I'm also not sure how you're simplifying this merely by stating that it is easy (when it in fact isn't).

2. Yes, hotspots do work. And I did mention that they are still usable in that way because they used to be the only way to keep track of the player. The downside of using them is that they might screw with modules or require additional code to distinguish them from actual clickable hotspots.
You can skip all that hassle by simply using regions, the very feature that was implemented precisely to keep track of the player's position.
You can of course write lots of code to emulate all that regions do using hotspots, the question remains, why the fuck would you? You can always use a frying pan to drive a nail into the wall, but why not use the friggin' hammer right next to it..?
Also note that all drawn areas concerned with walking are supposed to be at least three pixels wide because the pathfinding algorithm only looks at every second or third pixel. I'm not sure if this applies to the actual movement as well but a walking character is moved several pixels per frame (their MovementSpeedX/Y) so they might not touch a one pixel wide line.

3. And again. Why the fuck would you resize all animation frames to 80% and stick them in a second view, then change the view manually in code?
Why go through these lengths WHEN YOU KNOW ABOUT WALKABLE AREA SCALING?
Are you trying to make creating your game as tedious as possible by skipping all the cool features or are you just unable to say "cool, I didn't know that, thanks"?

Seriously, if you want my help, stop being a know-it-all-better until you actually have a fucking clue.
A guy who has been posting here for years recently told us that indenting code was the most useless thing ever. Please don't become that way after a week.

[AnasAbdin]

Wowoowoooowoooo
chill! I used hotspots and they worked perfectly, deal with it  

knowing basic features of AGS does not make me a known it all!!!?? I'm 100% sure I know less than 1% of what you know, still, this doesn't deprive me from giving suggestions and opinions. I don't mean to makeyou look any lesser, you helped me solve coding problems and I respect and appreciate you

and please, I'd appreciate it if you don't use the F word in my threads

edited: for the sake of being professional, I have tried using regions, all I did was creating regions exactly where the hotspots used to be.. I copy/pasted the code I used in the hotspots into the region's walks-into... worked the same, no difference 

[Khris]

"I used the frying pan and the nail is in the wall, deal with it" :

NO, knowing basic household tools doesn't make you a know-it-all, BUT telling me that using a frying pan as a hammer is just as good when I repeatedly explained why it isn't does.
It's nice that you say you appreciate my advice, but that seems to be the case only for stuff you haven't "all figured out" yet. And that's all I objected to. It doesn't surprise me that you didn't address the 80% scaling issue.
See, that's why I'm reacting even more pissed off, you don't even seem to get what you did that pissed me off (although I pretty much spelled it out). I hope you do now.

And you still don't get at all why I recommended to use regions. It might not make a difference YET with the specific thing you're implementing, but, again, there's a good chance it WILL at some point.
The nail is in the wall, but you might discover that the frying pan no longer works because the bottom has a dent now (to use this analogy one last time, hopefully).
So if somebody gives you advice here, maybe just take it and do some research instead of repeatedly doubting them. You cannot start too early with good coding practice.

Also the hotspot's "stands on" event is fired 40 times per second as long as the player is standing on it while the region's "walks onto" event is fired once and not again until the player walks off of the region and back onto it again.
To have code executed repeatedly you'd use the region's "while standing on" event, which is equivalent to the hotspot's, and it's very well possible that it doesn't make a difference with the specific piece of code you're currently using, yes. That's not the point though and never has been.

Also, please choose one or more acceptable versions of FUCK:
1) F*CK   2) FSCK   3) F...CK   4) F....K
so I'll not make you feel uncomfortable in "your" thread in the future.

[monkey0506]

There are several differences between hotspots and regions. Hotspots are intended to be able to be something that the player can interact with. They can look at it, use inventory items on it, etc. So, since hotspots are supposed to be an interactable area, they are given user-friendly Names (descriptions) that can, for example, be displayed on a label (and will be automatically if you use @OVERHOTSPOT@ in the label text, which despite the name works with hotspots, characters, inventory items, objects, ie. the interactable items).

Regions are not meant to be interacted with by the player. They have built-in events that you can define to control what happens when the player walks on or off of them. They do not have user-friendly names at run-time, they only have script names for design-time. The reason for that is because the user doesn't actually interact with them, but the player will fire off the events as appropriate.

Just because something works doesn't mean it's the best way of going about doing it. That's what Khris was trying to convey. Even if the end-results are exactly the same in this particular example, you're developing habits now while you're learning AGS that could make you less successful with it in the long run. Learning the difference between hotspots and regions, and when each one is the more appropriate to use, are among those habits.

Regarding what Khris said about the "know-it-all" attitude, he was referring to the way you've been rather flippant when receiving help, saying things like, "I'm not that dumb" when as the case turned out to be, you did make a mistake. He's not trying to berate you (nor am I), but the way you respond indicates that you're not gleaning as much from Khris' posts as he expects you to. Honestly, I don't think he's asking too much, so I kind of understand where he's coming from.

In any case, this entire post is off-topic, and I think I'll just let Khris handle the technical side of this one.

[Mazoliin]

WARNING: This is code is untested

Make regions as the hills top and bottom. In their "player walks onto" function, turn on/off the walkbehind, adjust the scaling of the walkable area, and tell the game if the movement sould be inverted or not. This is how I think it should be done.

Have some variables to keep track of which hill we're on, if the mouse is inverted, and if the walkbehind is active.

Code: ags

bool _invertedWalk; // Is the movement inverted
bool _onFarHill; // Are we on the far away hill
bool _walkbehindOn // Keep track if the walkable area is active

This is how I invert the mouse (same idea as my first post)

Code: ags

// PLACE THIS INSIDE THE ROOM SCRIPT
function on_mouse_click(MouseButton button)
{
  // Rooms can have their own on_mouse_click function too
  if (_invertedWalk && mouse.Mode == eModeWalkTo)
  {
    int invertY = ROOM_HEIGHT - mouse.y;
    ProcessClick(mouse.x, invertY, eModeWalkTo);
    ClaimEvent(); // Prevent global on_mouse_click to get run.
  }
}

This is the "walks onto" function for the first hills top.

Code: ags

WalkOntoHillTop // Should be the "walks onto" function for the region that is the hill top
{
  // If the player is on the far away hill, this region does nothing
  if (_onFarHill)
    return;

  // We are on the fist hill, figure out if we're walking to the back or front of it.
  if (!_walkbehindOn)
  {
    // Walk to the back of the fist hill
    SetWalkBehindBase(THE_ID_OF_THE_WALKBEHIND_YOU_USE, HEIGHT_OF_YOUR_ROOM);
    _walkbehindOn = true;

    // Whe sould invert the walk. So if we click at the bottom of the front hill, the character will walk upp the back
    // then down the front.
    // If we click the backgroun hill, the player should walk down the first hill, then up the second.
    _invertedWalk = true;
  }
  else
  {
     // Walk to the front of the fist hill
    SetWalkBehindBase(THE_ID_OF_THE_WALKBEHIND_YOU_USE, 0);
    _walkbehindOn = false;

    // Reset movement to normal
    _invertedWalk = false;
  }

  // Since the player is at the top of the hill, he should start walking down.
  // So get the distance that he have left to walk.
  int dist = player.y - mouse.y;

  // Have the player walk down that last bit
  ProcessClick(mouse.x, player.y + dist, eModeWalkTo);
}

The second region should do the same. Check wich hill we're on, check if we're behind of infront of it. Check where we are going, and based of all that, change our direction, scale, and so forth if needed.

As I said, this code is untested. I've ony did a quick test of my idea, but it was not as neatly done as this.
I don't want to get in to the off-topic discussion, but seriously, use regions for this kind of stuff, it's what they're made for :

[Ali]

I'm surprised no one has mentioned SSH's module for walking behind hills:

http://www.adventuregamestudio.co.uk/yabb/index.php?topic=29235.0

It's a bit out-of-date but it's easy to get it working. It only supports 4 walking directions at the moment, but I don't think it would be much trouble to bring it up to 8.

[AnasAbdin]

I appreciate all your help tuck