RunTo and RunLikeHell getting stuck

[Liquid Zebra]

I wanted to see if anyone else has had this problem. Have you?

Every once in a while, not too uncommon actually, RunTo or RunLikeHell will get stuck.

It seems that it is so close to it's destination (0.001-ish) that it can't click it's destination because it's too close. So it just sits there.

Solution?
Put in 5-second check or something. If executing a RunTo or RunLikeHell and your character hasn't moved in 5 seconds or so, re-execute the last RunTo/RunLikeHell.
OR Give it some leniency. If you're within like 0.1 of where you're supposed to be, continue.

I understand that RunLikeHell is a custom behavior (QB) unlike RunTo.

Thoughts? Better Solutions?

 

[633csi]

I saw this in two places on a profile I just made. It has about 200 runto functions but only two got stuck, I changed both where he was stuck and the next one and haven't seen it again for ~24 hours. Obviously not a fix but it worked for me.

 

[Natfoth]

I know what you are talking about, problem is because it very rarely happens it is hard to debug and figure out why its actually stopping so extreamly close to where it needs to stop but it doesnt realize its stopped. Nothing that you guys can do about it, something that I have to look into.

 

[Liquid Zebra]

I know what you are talking about, problem is because it very rarely happens it is hard to debug and figure out why its actually stopping so extreamly close to where it needs to stop but it doesnt realize its stopped. Nothing that you guys can do about it, something that I have to look into.

Think my solutions are viable? Either leniency or a certain seconds check.

EDIT: Or make sure that a waypoint isn't too close to the final destination unless it is the final destination.

 

[AknA]

Well, you can check your current location and based on that compare it to where it should move, if your current location is within range of where you should move it can skip the moveto, but then you have to add such code to every single moveto, and would make your profile ALOT longer and more frustrating to code.

 

[Liquid Zebra]

Well, you can check your current location and based on that compare it to where it should move, if your current location is within range of where you should move it can skip the moveto, but then you have to add such code to every single moveto, and would make your profile ALOT longer and more frustrating to code.

Wouldn't work because if it's stuck on a "moveto" it's still on the moveto therefore you couldn't check if you were within range to move somewhere else unless you used hyper-threading, which I believe is only possible in plugins and custom behaviors, not directly in the profile.

 

[AknA]

Wouldn't work because if it's stuck on a "moveto" it's still on the moveto therefore you couldn't check if you were within range to move somewhere else unless you used hyper-threading, which I believe is only possible in plugins and custom behaviors, not directly in the profile.

Can't swear this will work but :

<If Condition="(Me.X &gt; 100.050 && Me.X &lt; 99.950) && (Me.Y &gt; 100.050 && Me.Y &lt; 99.950)" > 
    <RunTo X="100" Y="100" Z="Whatever" />
</If>

Logically it should "release" the RunTo if you are within the above coordinates, but like I said, can't swear it would work, it depends how RunTo is coded.

 

[Liquid Zebra]

Can't swear this will work but :

<If Condition="(Me.X < 100.050 && Me.X > 99.950) && (Me.Y < 100.050 && Me.Y > 99.950)" > 
    <RunTo X="100" Y="100" Z="Whatever" />
</If>

Logically it should "release" the RunTo if you are within the above coordinates, but like I said, can't swear it would work, it depends how RunTo is coded.

Right but let's say it gets stuck at (99.999, 99.999). Then what? You're stuck, it doesn't loop. Even with a while loop it wouldn't loop because it's getting stuck DURING the RunTo.

 

[AknA]

Right but let's say it gets stuck at (99.999, 99.999). Then what? You're stuck, it doesn't loop. Even with a while loop it wouldn't loop because it's getting stuck DURING the RunTo.

Like I said, it depends on how RunTo is coded, in your example you are within the If condition so then it shouldn't do the RunTo command, if RunTo uses Navigator with CTM or something then it should work.... I think.

 

[AknA]

If RunTo works like a Quest Behavior then the way I sugested could be added by Natfoth to the code for RunTo, that it your current location is +/- whatever of the location it should reach then "behavior" is done.

 

[Natfoth]

RunTo works like a behavior and will only return once the code is finished, also it has all those checks in it already and it has the checks for the leniency also.

 

[AknA]

RunTo works like a behavior and will only return once the code is finished, also it has all those checks in it already and it has the checks for the leniency also.

Maybe increase the leniency abit or add a movement check like Liquid Zebra thought about in the first post, that if the RunTo behavior gets "stuck" and haven't moved for lets say 3 seconds then send behavior done.

 

[chinajade]

Put in 5-second check or something. If executing a RunTo or RunLikeHell and your character hasn't moved in 5 seconds or so, re-execute the last RunTo/RunLikeHell.
OR Give it some leniency. If you're within like 0.1 of where you're supposed to be, continue.

I understand that RunLikeHell is a custom behavior (QB) unlike RunTo.

Well, you can check your current location and based on that compare it to where it should move, if your current location is within range of where you should move it can skip the moveto, but then you have to add such code to every single moveto, and would make your profile ALOT longer and more frustrating to code.

Hi all,

What you are suggesting is exactly how the UnstuckHandler works. It measures distance traveled over time (and other things), and invokes the unstuck procedure if not enough progress is being made for the expected travel speed (e.g., 'foot' or 'mount').

RunTo uses Honorbuddy's Navigator which also has hysteresis built in to prevent 'spinning' and other unwanted effects that navigation can create. I have no explanation why you would *ever* see the problem you describe with RunTo.

As for RunLikeHell, its probably using ClickToMove which intentionally bypasses the Navigator (and StuckHandler), because you are supposed to be follow a very specific, predefined path.

 

[Liquid Zebra]

Maybe increase the leniency abit or add a movement check like Liquid Zebra thought about in the first post, that if the RunTo behavior gets "stuck" and haven't moved for lets say 3 seconds then send behavior done.

Done and re-execute the previous RunTo or something.

 

[Liquid Zebra]

Hi all,

What you are suggesting is exactly how the UnstuckHandler works. It measures distance traveled over time (and other things), and invokes the unstuck procedure if not enough progress is being made for the expected travel speed (e.g., 'foot' or 'mount').

RunTo uses Honorbuddy's Navigator which also has hysteresis built in to prevent 'spinning' and other unwanted effects that navigation can create. I have no explanation why you would *ever* see the problem you describe with RunTo.

As for RunLikeHell, its probably using ClickToMove which intentionally bypasses the Navigator (and StuckHandler), because you are supposed to be follow a very specific, predefined path.

Well something needs tweaking it seems. I understand the StuckHandler (i.e. get stuck (caught) running behind a box). Your character is in the process of moving, yet it's coordinates are not changing. In my case, my coordinates are not changing, however, I'm not actually moving (running in place). There is no CTM I'm headed towards. Surely this may have been overlooked because it is assumed that you are always "trying" to move when executing a RunTo. How much is the leniency if I may ask?

 

[chinajade]

Well something needs tweaking it seems. I understand the StuckHandler (i.e. get stuck (caught) running behind a box). Your character is in the process of moving, yet it's coordinates are not changing. In my case, my coordinates are not changing, however, I'm not actually moving (running in place). There is no CTM I'm headed towards. Surely this may have been overlooked because it is assumed that you are always "trying" to move when executing a RunTo. How much is the leniency if I may ask?

Hi again, Liquid Zebra,

The hysteresis threshold scales based on expected travel speed. I believe on foot its 1.5 units, ground mounted its 5 units, and uncertain about about swimming and flying values.

cheers,
chinajade

 

[Liquid Zebra]

Hi again, Liquid Zebra,

The hysteresis threshold scales based on expected travel speed. I believe on foot its 1.5 units, ground mounted its 5 units, and uncertain about about swimming and flying values.

cheers,
chinajade

Something tells me that they aren't working as intended. The 5 units for a ground mount, especially. My guys are always running in a circle trying to get exactly on top of a coordinate while mounted, which is why I'd rather run over mounting sometimes.

 

[Liquid Zebra]

Marvelous! After more research, I've gotten my character stuck again and recorded the current location and the location it was trying to get to!

Current Location: X = -200.566 Y = 259.2639 Z = -50.09369
Destination: X = -201.3245 Y = 258.066 Z = -49.59687

If you run these coordinates through a simple distance formula, (I used a calculator.) you'll get sqrt(2.2571167724000065) which is approximately 1.50237038456 units! WHICH IS GREATER THAN 1.5!

I'm actually happy that I figured this out, not upset. Yay me!

If you could please change the leniency to 2 units (to be safe) for walking ASAP, I would really appreciate it.

Thanks!
Liquid Zebra

EDIT: Also, I don't suppose you could tell me how to change the leniency on the version I have now could you? If you can't, no worries, just glad I could figure this out for you guys. I know it's a pretty big fix.

 

[Liquid Zebra]

Another spot I got stuck in is shown below:

Current Location: X = -218.36 Y = 234.57 Z = -50.48
Destination: X = -219.3023 Y = 233.6328 Z = -50.4059

Distance Apart: sqrt(4.086935940000065) ~ 2.0216171596 units

So, maybe you should change the leniency to 2.25-ish.

Regards,
Liquid Zebra

 

[chinajade]

Another spot I got stuck in is shown below:

Current Location: X = -218.36 Y = 234.57 Z = -50.48
Destination: X = -219.3023 Y = 233.6328 Z = -50.4059

Distance Apart: sqrt(4.086935940000065) ~ 2.0216171596 units

So, maybe you should change the leniency to 2.25-ish.

Regards,
Liquid Zebra

Hi, Liquid Zebra,

First, let me say I really admire the detective skills you've demonstrated in this and other threads.

But on this issue, I think you are missing the point completely. It doesn't matter what the 'leniency' number actually is, you will always run into situations that will trigger whatever scenario you've discovered. We could make the leniency 15 and you could still find scenarios where that was insufficient.

The problem is simply you are getting stuck. And each stuck situation should be reported to the Navigation thread thread, so something can be done to the meshes to address the situation.

There is also the issue of why isn't the StuckHandler resolving the problem for you. So, an eye should be turned in that direction also.

But, trust me, the precision used by the navigator is not the root cause of the problem you are observing.

cheers,
chinajade