I have overlapping walkable areas so I have this script in my room's repeatedly execute:
if ((GetWalkableAreaAt(player.x, player.y)) == 1) RemoveWalkableArea(5);
if ((GetWalkableAreaAt(player.x, player.y)) == 5) RemoveWalkableArea(1);
if ((GetWalkableAreaAt(player.x, player.y)) == 4) {
RestoreWalkableArea(1);
RestoreWalkableArea(5);
}
It -works-, but I get a LOT of slowdown as a result of it checking every second. So, I'd like to put an "if walkable area # is on, remove..." type line in, but (and I'm still getting used to the new style of scripting and even the way the manual is set out, so it could be blatently obvious) I can't find how to do this in the manual.
I'm not even sure if that would prevent the slowdown, since it's still checking(but not constantly "turning off"), but I thought I'd give it a try.
I think just checking whether a walkable area is on or off doesn't take much time, compared to constantly turning an area on/off, but like you I didn't find a way to check them from the manual, I may assume it's not implemented into the engine yet, and I think it may be worthy of adding this feature if not done already.
Currently, you can use a variable to track down the last area the player's in, if the character is still in the same area this game loop, nothing was changed, else do the changes. Like:
On top of script, declare variables as usual:
int thiswalk, lastwalk=999;
In repeatedly_execute():
thiswalk=GetWalkableAreaAt(player.x, player.y);
if (thiswalk!=lastwalk){
Ã, lastwalk=thiswalk;
Ã, if (thiswalk == 1) RemoveWalkableArea(5);
Ã, if (thiswalk == 5) RemoveWalkableArea(1);
Ã, if (thiswalk == 4) {
Ã, Ã, RestoreWalkableArea(1);
Ã, Ã, RestoreWalkableArea(5);
Ã, }
}
Alternatively, you may use regions, just define regions EXACTLY as the walkable areas, and put in the area modifying codes in "Player walks onto region" interaction of the respective regions, this is the easiest way, but won't be good if you need to use the regions for other more important purposes.
Hmm, thanks. I might give using regions a go then.
Er, I guess I'll stick suggestion on this topic because I think if checking walkable areas isn't currently available it'd be a good idea.
EDIT: Well, I'm using regions now which works fine except for one problem. I'm using the Interaction editor for regions, putting RemoveWalkableArea() etc in the "When player walks onto region" section. Basically, I have them set out like this:
REGION#4
REGION#5
REGION#1
All touching like that, and all corresponding to walkable areas of the same number. When I step onto REGION 4, it restores all the walkable areas. When I step onto REGION 5, it removes walkable area 1. If I walk onto #5 and stop, the whole thing works. If I move without stopping from 4 onto 5 and keep heading down, my character is able to walk onto #1 and then gets stuck because #1 finally disappears.
So, does this mean these commands are being blocked? Is this supposed to happen?
hmmm didn't expect this, I think possibly that region interaction is triggered only when the character stops.
In that case you may try my variable checking method instead.
If the character is doing a blocking walk, the region events get queued up until the game is no longer blocked, I believe. So walking over 2 regions DOES trigger both events, but if the second region event happens to cancel out the first region's events, or if it is too late by then anyway then tough. This also means that Gilbert's code will need to go in rep_ex_always, I believe. Another solution, though, I think is to make sure that all walking (including to hotspots, etc) are done NON-blocking.
I'm gonna give Gilbot's code a try then.
EDIT: The verdict - If I start on walkable area #1, all is well, and walkable area #5 is off. If I then move onto walkable area #4 (inevitable to get to #5), walkable area #5 is off and I can't find any way to turn it back on.
If I start on walkable area #5, all the walkable areas are on at once, and I can't turn any of them off by moving anywhere. Also, after a minute or so of walking around, my character froze (the game was still running) seemingly because walkable area #1 was turned off (that's where I was currently standing, anyway).
I can't see how these things happened, but ... anyway, I shall do some more thorough testing and see what I can come up with.
EDIT2: Hmm.
I set up a couple of labels to tell me if and when each walkable area is on or off. All I can say is that there's either a bug at work, or I'm just insane. The areas are turning on and off when I walk over areas that are all VERY MUCH in the same walkable area, nowhere near the boundaries. Not only that, but they turn on at points that are about 50-100 pixels away from wherever they turn off. the strangest thing is that it seems random, but only a little random. At first, I thought there must be some other walkable area at play and I kept walking over it's boundaries, but the on/off positions kept changing and then staying the same as I moved between on and off, but not with much accuracy either.
This has to be a bug.
I think at this stage it might be better for me to wait for a function to detect walkable areas.
EDIT3: I'm now using this code
if (((GetWalkableAreaAt(player.x, player.y)) == 1) && (region[5].Enabled == true)) {
RemoveWalkableArea(5);
region[5].Enabled = false;
SetLabelText(27, 0, "5 is off");
}
if (((GetWalkableAreaAt(player.x, player.y)) == 5) && (region[1].Enabled == true)) {
RemoveWalkableArea(1);
region[1].Enabled = false;
SetLabelText(27, 1, "1 is off");
}
if (((GetWalkableAreaAt(player.x, player.y)) == 4) && ((region[1].Enabled == false) || (region[5].Enabled == false))) {
RestoreWalkableArea(1);
RestoreWalkableArea(5);
region[1].Enabled = true;
region[5].Enabled = true;
SetLabelText(27, 0, "5 is on");
SetLabelText(27, 1, "1 is on");
}
With regions/walkable areas corresponding to each other and the same thing is happening, so it's not your code Gil. I'm rather clueless about what would cause this.
Quote from: Kinoko on Wed 29/06/2005 13:38:40Not only that, but they turn on at points that are about 50-100 pixels away from wherever they turn off. the strangest thing is that it seems random, but only a little random.
While characters are moving, their coordinates are not very accurate (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=79).
GetWalkableAreaAt expects screen coordinates while character coordinates are room coordinates. If you have a scrolling room, you may have to
substract GetViewportX and GetViewportY from the player coordinates.
Edit: add => substract
They're not all that in-accurate, actually. I wrote a small function at the beginning of my script which stores the scaling at (player.x, player.y) in an int. If the coordinates are within a valid Walkable Area, it updates the value. If not, it just keeps the old one. I'm using that for a multitude of functions and haven't had a single problem with it so far.
Edit: As for the issue at hand, I'm having trouble picturing in my mind what you're trying to achieve. I imagine that you can't go directly between the two areas anyway (as they turn eachother off), so wouldn't it be easier to just handle the on/off on two different regions INBETWEEN area 1 and 5? Otherwise, could you post a screenshot to illustrate the problem?
Some sort of IsWalkableAreaEnabled function wouldn't be a bad idea, I'll look into it.
This is the general area
(http://kinoko.futariba.com/misc/x1.gif)
This is where the walkable areas are:
(http://kinoko.futariba.com/misc/x2.gif)
Basically above that, #1 eventually meets up with #4.
Below here (which is the screen above of the previous ones), in the red circles is basically where I'm having areas turn on and off (some of the places, anyway).
(http://kinoko.futariba.com/misc/x3.gif)
Thinking about this is giving me a headache. It's almost like looking at an Escher drawing :) Instead of using areas 1 and 5 to switch eachother off, what if you split area 4 into two different areas, where the one closest to 1 turned 1 on and 5 off, and vice versa?
Also, you could make it only check if player.Moving is true to mimize slowdowns.
Really? I think my code is pretty simple. It works and I'm happy with it, the only problem is this "bug" that makes absolutely no sense to me. If someone could shed some light on what it could be, I'd very much appreciate it.
Not the code as much as the pictures :) The only possible cause I can see are the corners where the WalkableAreas are within a pixel of eachother. But you said that it doesn't matter how close to the edge you are?
And this isn't a scrolling room by any chance?
It's a scrolling room. Very scrolling.
Ah, that could be the problem. Player coordinates are room coordinates, WalkableArea coordinates are screen coordinates. You have to use GetViewportX and Y and subtract them from the player coords.
Edit: Alternately, if your regions are identical to your walkable areas, you could use Region.GetAtRoomXY(player.x, player.y).
Edit 2: Doh, I see that strazer pointed this out ages ago. So I assume you did already take care of it in your script?
Edit 3: Except he said "add", shouldn't you rather subtract?
AH! It works! Thanks so much, GG! ^_^ That was really stumping me, I hadn't realised screen coords might be involved, but it explains everything.
I don't know why I missed strazers comment up there. Sorry strazer! I think I read it and then read your reply right after and forgot about it. Yet again, I embarrass myself in the tech forum.
Glad to hear it worked. I had missed strazer's comment as well, until I went back and checked it now :)
Quote from: GarageGothic on Thu 30/06/2005 16:48:59Edit 3: Except he said "add", shouldn't you rather subtract?
Hehe, indeed. :)
Edit:
Quote from: Pumaman on Wed 29/06/2005 18:34:40
Some sort of IsWalkableAreaEnabled function wouldn't be a bad idea, I'll look into it.
Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=530