When no path can be found to the next waypoint, Windbot will skip this waypoint. This happens regardless of waypoint type (the docs disagree, so this might be a bug). I think this is a bad idea and that you cannot make reliable scripts in this way. There are some circumstances when you'd wish to skip the waypoint, but these are rare exceptions, and not the rule. Instead I think that the best way to deal with a blocked path is to just stand still and set a flag that let's any running lua persistents know that the path is blocked.
Every script have some actions that simply cannot be skipped, such as buying supplies before leaving the town. This means that you must have at least some position checkers that force you to redo certain waypoints if you didn't reach them. However, this means that script never will be able to loop all the way through all waypoints and get back a reachable waypoint once it starts skipping. Instead you need to split the script into sections such that if you fail to reach the end of a given section it will go back to its beginning. Note that these sections don't have to correspond to actual waypoint tabs, but that is one way to do it.
However, this also means that when your path is genuinely blocked you'll end up going back to the first waypoint in the section, walking the same path again until you get to the blocked waypoint again at which point you'll loop back to the beginning again... In short, we end up in a loop, but since we're not standing still $standtime doesn't go up so any running lua persistents won't know that we're stuck. This is a major problem when the path is blocked by furniture as a persistent furniture destroyer is the only way to get unstuck.
There are two workarounds for this:
- Add a position checker after every waypoint so that you're in fact forced to stand still when your path gets blocked. These can automatically be inserted by a good context menu or waypoint button script, but makes things unnecessarily complicated, in particular if we later want to move waypoints around. Essentially this is just forcing the walker to not skip waypoints, which is how it ought to be behave in the first place.
- Try to detect that you're stuck in some other way. Beyond being complicated and not always reliable, this also has the problem that the walker will try to take us away from the position where our blocking furniture is, which makes our job of destroying it a lot harder. You might argue walking away backwards is the correct behavior when your path is blocked by a player instead of furniture, but this only applies if you're deadlocked and furthermore it's an action that's easy to carry out in lua so it remains available even if you don't skip waypoints.
All in all waypoint skipping is not unmanageable, but makes it a hell of a lot more difficult to make reliable scripts. It also introduces a lot of situations where you not only risk getting stuck, but risk getting banned, if you don't have checkers before certain lua actions. The latter problem is made even worse by the standard library containing possibly infinite loops in functions like depositerbank. This makes waypoint skipping unsuitable both for experienced scripters wanting to make something that works 100% of the time, and for beginners wanting to make something that works most of the time but without any risk of getting stuck in an infinite lua loop that likely will get them banned.
My suggestion is that nodes should be skipped if you're within the set node range, stands should never be skipped (not even if you're standing next to the waypoint -- you'd have to actually be inside it) and walks should always be skipped. However, this might break some scripts that have abused the fact that waypoints are skippable in order to do cute things so an alternative would be to simply introduce two new waypoint types: unskippable variants of node and stand.
Finally, there are some circumstance when skipping a waypoint of any type is fine. This is when the waypoint is either located on a different floor or inside a wall as these are situations that neither will resolve themselves given time, nor can be resolved by persistents.
