# Pathfinding trouble

8 posts

 - pathfinder works great for things that move one at a time. -when multiple things are allowed to move at once in a real time situation theres long bouts of lag with certain units failing to pathfind because something just moved where they were going to move to. -To solve this simply checking if the desired end location is occupied, if not, we move one tile at a time to it - the very next tile we are to move to we check if its full and if it isn’t we change it to being full - once we have made it to the next tile, the old tile is unoccupied - If we cannot move to the next tile, stop pathfinding. I don’t know if this is the best solution. But I can’t get it to work properly. Currently its screwing up and the next tile isn’t being marked as occupied until we are fully there, if we move more then a few tiles away it really screws up and we no longer occupy anything, leaving behind a tile thats occupied by nothing. If anyone can point out whats wrong with it, or if I’m simply taking the wrong approach to this, let me know. I’ll be changing pieces of it to see if I can figure out whats wrong. **unit.as** ` private function loop(e:Event){ if(!path || path.length < 2){moving = false;return;} if(!moving && path.length > 1){ moving = true; } if(moving && path.length > 1) { if(path[1].traversable == true || nextOccupiedTile != null) { if(nextOccupiedTile == null) { path[1].traversable = false; nextOccupiedTile = path[1]; } runTo(path[1]); }else { path[1].traversable = true; nextOccupiedTile = null; path.length = 0; } } } private function runTo(n){ if(!n)return; if(x == (n.x + xOffset) && y == (n.y + yOffset)){ occupiedTile.traversable = true; nextOccupiedTile.traversable = false; occupiedTile = nextOccupiedTile; path.shift(); return; } //code that causes unit to move to next tile not shown here } ` It looks like the }else { is just floating around by itself not attached to anything. Seems to me that would cause path1 to always become traversable and nextOccupiedTile to become null no matter what if it somehow compiled. Freaking Egyptian braces…Here, readable version: ` private function loop(e:Event) { if(!path || path.length < 2){moving = false;return;} if(!moving && path.length > 1) { moving = true; } if(moving && path.length > 1) { if(path[1].traversable == true || nextOccupiedTile != null) { if(nextOccupiedTile == null) { path[1].traversable = false; nextOccupiedTile = path[1]; } runTo(path[1]); } else { path[1].traversable = true; nextOccupiedTile = null; path.length = 0; } } } ` weird. I didn’t notice that. They aren’t Egyptian braces in the file… I guess when I pasted them in it moved the brackets. I actually just started to stop doing the Egyptian bracket thing about a month or two back, it makes finding connecting brackets hell. [Also Thanks](http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html) I now know a little more jargon. Buh, don’t like that article. If anyone REALLY uses the term “Higgs-Bugson” they should be forbidden from programming ever again. This is a case of cooperative pathfinding. There’s something nice I saw a while back called the Increasing Cost Tree Search, but I never really tried it out. Low quality video: [http://ijcai-11.iiia.csic.es/video/46](http://ijcai-11.iiia.csic.es/video/46) The presentation starts at ~20:30. The slides can be found on that page too. Might be a bit overkill for your purposes though :) Edit: actually, i just realized that it is actually very very slow lol. You might want to look into some of the decoupled approaches instead. Ha seriously. That author was trying a little too hard to be witty. Cool duck story though. Thank you jon. I’m going to watch that whole thing… I’ve also got a few nice pdf’s to study. I figured it out. I overlooked setting nextOccupiedTile to null upon reaching a new tile. The lag is probably just the sheer amount of nodes each unit has to go through, so I’m going to split groups of nodes into sections, ect.