[Pierre-Marie Baty]

@A$$A$$IN: this is indeed the simplest method, however it is unpractical because it won't work on a certain number of case. For example, if the bot falls down the Aztec bridge, the bot will still be in movement but the path will have failed. Also, if a path between 3 nodes make less than a 90 degree angle (circling around a wall, for example), the bot will reach the waypoint then face back and start walking the other side, and this might trigger your stuck check algorithm. One more common situation, is when the bot is already walking, then is told to walk another path that starts right behind it ; the bot's speed will decrease, stop, and then increase backwards and that doesn't mean the bot is stuck. I'm long experienced in tweaking stuck checking algorithms like this one, and unfortunately I never could reach any acceptable result.

@botmeister: your first idea looks promising! I hadn't thought about this one yet. I'll try it. Your second idea though is the traditional way to go for such algorithms when the bot faces its next waypoint perfectly, and thus is ASSURED to reach it. However mine don't, they use the strafe keys instead, and this causes problems when they come closer to the waypoint as the distance can really vary much, decreasing then increasing several times in a second, but it doesn't mean the bot is stuck though.