But that line checks against a real value. If you type hi while the actor is moving, you will see that it returns 0. Hit hi again while he is stopped, but not because he is stuck, and you will see that it returns 1. Try it again while he is stuck but should be moving and you'll see the 0 again. So in the case of the 1, you are sending him off and running when he shouldn't be moving at all... Remember the first time you hit hi, he is stopped, he doesn't start until after the print statement....
That is pretty cool though that he does something. Just not quite sure why he is doing what he's doing lol with that value changed to 1
Collector, the x step of a character varies, but is usually pretty small. A single valid step may only be a few pixels. Since I am checking every cycle, I want to know when he comes to a dead stop. Which clearly happens, by checking the hi values repeatedly when he is stuck, the current = recent check should come up positive.
Oh yeah Gumby thanks for the absolute operator, I knew there was one out there just couldn't remember what it was.
EDIT:
Wow, that was really ugly...
So I know my boundary is a vertical line. At this point I am just trying some options to get around it. Here is what I did.
First I changed section 4, including the line that Gumby pointed out
// step 4. determine if hungup
//*******************************
(if(== (thisActor:isStopped) 1) // should be moving.
(if((== recentX currentX) and (== recentY currentY))
// Print("stuck")
= stealControl TRUE
= attempt Random(0 3)
)
(else
= recentX currentX
= recentY currentY
)
)
Oh yeah, I also trimmed down section 3 to what it should have been originally.
// step 3. determine distance...
//********************************
= currentDistanceX Abs(- currentX targetX)
= currentDistanceY Abs(- currentY targetY)
And I changed the values in section 10, like I said I know how he's stuck and which side I am sticking him on so while these won't get us anywhere near production, it is at least a good test with expectable results. Regardless though, this sort of worked but not really at all.
// step 10. make a path...
//********************************
// Now that we have some variables, lets send our actor walking...
(if((> currentDistanceX 30) or (> currentDistanceY 20))
(if(not(stealControl))
(thisActor:setMotion(MoveTo targetX targetY))
)
(else
// Try an alternative path here
(switch(attempt)
(case 0 (thisActor:setMotion(MoveTo (- currentX 2) (- currentY 30)(pathScript:changeState(0)))))
(case 1 (thisActor:setMotion(MoveTo (- currentX 2) (- currentY 60) (pathScript:changeState(0)))))
(case 2 (thisActor:setMotion(MoveTo (- currentX 30) currentY (pathScript:changeState(0)))))
(case 3 (thisActor:setMotion(MoveTo (- currentX 60) currentY (pathScript:changeState(0)))))
)
)
)
(else
(thisActor:setMotion(NULL))
)
And finally, I changed the default line in the changestate method so that it was the case 0 that the moveto in the last section was looking for in order to trigger the following bit of code again.
(method (changeState newState)
(= state newState)
(switch (newState)
(case 0 = stealControl FALSE)
)
)// end method
The good news, suprisingly the actor made it around the solid line. The bad news, he didn't do it in any sort of fashion that he should have. It was ugly and not at all recognisable by the moveTo statements. Also, with the isStopped value changed, when he is successful and made it within the distance to ego the stuck message still fired. I am still positive that check should be set to 0
EDIT #2
And actually, even though my attempt to get him around the boundary was to subtract from his x position, he got around the wall just as well going from east to west. I certainly don't think that should have been the case. This is just plain wierd... but he got around the wall from both sides. I guess I need to make a box or a harder shape and see what happens.