You might (for long distance pathfinding in a maze-like terrain) have to preprocess the map using some 'portal' technique to identify the chokepoints and build a A* network of those (and the 'room' area centers). The nodes (and edges?) would have an extra value of ClearRadius predetermined of what sized object can go through that nodes constrictions. Network edges would be prechecked paths between the node points on the map.

This all would be a coarse level navigation (and probably be a smaller network which will saves on A* processing). Out-of-sight navigation might not have to be perfect and the less-than-optimal 'paths' of a coarser network might not be significant.

Then you will still be doing the fine grid navigation while in-sight of the player or maneuvers more than just distance moving (where precise collision detection for moving nearer the obstacles is required - like moving near cover in combat).

Of course if you have dynamic obstacles then you will have to do separate processing to handle those.

i modified the code so it checks a bbox around a tile to determine if its impassable, when expanding a neighbor.

seems to work ok. the closed list leaves nice little open areas around obstacles now.

still have to get wolfgang to follow the nodes correctly. i think the path is stored in collision map coords, and is not getting converted to world coords correctly. i plan to put a trace on it today. but that's just the move to node zero or move to node 1 code. the actual astar with bbox seems to be working just fine. and the overhead of the bbox check is negligible.

i modified the code so it checks a bbox around a tile to determine if its impassable, when expanding a neighbor.

seems to work ok. the closed list leaves nice little open areas around obstacles now.

If i understand you are doing this as you move??

You should be able to preprocess each tile with a radius series of expanding bounding boxes (complete edge of the box, not just the end points) and then when

that radius collides the tile is marked with the biggest size (clearance all around) that can pass freely using IT.

Even if you have dymamic objects that will act as obstacles, you can shortcut (cull out) at least the FIXED terrain part of the collision checking (and for A* thats the planned movement well ahead while path planning -- when you might not know where dynamic objects move before you get near them)

by checking to allow an object of radius R to only used tiles (to move on ) which have their 'clearance' radius of that size or larger assured.

If you have a highly dynamic terrain obstacles then you can RE-check paths some limited time BEFORE the object has to traverse a spot (as it may or may not be clear at that point in time). But the static parts of the terrain wont change and you can plan the path around those limitations early/initially.

If i understand you are doing this as you move?? You should be able to preprocess each tile with a radius series of expanding bounding boxes (complete edge of the box, not just the end points) and then when that radius collides the tile is marked with the biggest size (clearance all around) that can pass freely using IT.

No, not as I move, only when I run Astar to generate a path. Instead of generating a map for each size of critter, I use a different size bounding box for each size of critter - and just use a single collision / astar map. This means i can use a single collision map at scale = 1 for collisions and astar for all critters of all sizes.

Collision maps are generated on the fly as needed and cached. They can be generated at any scale (feet per tile). When used for collisions, I refer to them as the collision map. When used for Astar, I refer to then as the Astar map, as the two might be different maps of the same terrain chunk at different scales. But now I have it all working with BBox Astar and collision/Astar maps of scale = 1. And BBox radius = critter radius for collisions, and critter radius + 1 for Astar pathing. Right now I'm finishing up the special cases such as the goal is not on the same collision map as the start point, so you try to get the open node along the edge of start's collision map that is closest to the line of sight to the goal, and no node on that edge is open.

Also, none of this would affect your looping problem.

That was caused by "remove from closed" which is not necessary if the heuristic is admissible.