@ Orange Brat, It's basically unchanged, although the movement to avoid obstacles to get to goal was improved some. As far as terrain movement though, I didn't test it on that, which is probably what you are concerned with. As far as non-terrain movement, they shouldn't get stuck often, usually only by dynamic models, and it does stop the entity from moving after it tries to try reach it's next waypoint for a certain amount of moves so there is no endless loops for an entity trying to reach it's next waypoint that can't be reached. A solution that helps, although I did not include in this version, is if an entity cannot reach it's current waypoint within the waypointMoveCount limit, is to reset the waypointMoveCount to zero and get the next waypoint (or the next few, one at a time) and see if it can reach one of them, if not, then consider it stuck and give up and stop it's waypoint (Astar) movement.

The reason that a entity sometimes moves back and forth around it's goal position when it's goal position is close to a wall or obstale is due to the real-time avoid obstacle code during the actual movement. This could be tweaked out so it won't happen, I just never got around to it. What is happenning though, is that the entity realizes that there is an obstacle close somewhere in it's movement direction and is trying to avoid it as it moves. This avoidance code can actually keep the entity from reaching it goal though when it's goal position is very close to a wall or obstacle, so it will bounce back and forth try to reach goal until the code determines by means of the waypointMoveCount that the goal cannot be reached, at which point it will quit trying to reach the goal. The trick is to get the obstacle markers where the entity still avoids obstacles decently during movement, but yet is still able to actually reach it's goal when it is close to a wall, or keep the goal position a certain distance away from wall/obstacles somehow.

Since there have been a lot of good point and click contributions lately and I am back working heavy on The kID, I am discontinueing this for now unless there is a lot of interest.

I did upload one last fix on the program, where a single selected entity wasn't facing the desired pan the player selected with r-click (hold) at destination.

Unless you change the DLL, if you use the LocoPath DLL in your code, the following 4 skills must be at these skill positions.
define ENTITY_ID, skill10;
define WAYPOINT_X, skill14;
define WAYPOINT_Y, skill15;
define WAYPOINT_Z, skill16;

All the DLL actually does, is allow you to have 500 possible entities using Astar, as long as their ENTITY_ID's (1-499) are specific to them. It could be increased to however many entities you want, but I figured 500 was enough. The actual astar code is in the open_astar.wdl, it just stores all the waypoints and current waypoint data in the dll, so you can retrieve it easily and have more entities using Astar than would be possible with C-Script without a lot of trickiery in the coding. The DLL is actually quite short and simple. Basically it just stores waypoints in a multi-dimensional array larger than 3dgs can handle, and once an entity reaches it's current waypoint when it's MOVEMODE == MODE_PATH, you just call DLLGetNextWaypoint(TheEntity); to get it's next waypoint. The function returns how many waypoints are left and set's TheEntity.WAYPOINT_X, _Y, and _Z. If you have SDK, the source for the DLL is included and you can do whatever you want with it.

EDIT: One more note, if you ever stop moving through the waypoints while getting to goal position while entity's MOVEMODE == MODE_PATH, i.e., run into an enemy and start fighting him on way to goal or set a new goal for the selected team or entity while they are currently using waypoints, make sure you call DLLClearWaypoints(TheEntity.ENTITY_ID); in your C-Script .

I am not going to cover how to you should change movement to work with c_move() and c_trace(), but, if you want the open_astar.wdl (Astar Code) to work with c_trace() change this part of code in in open_astar.wdl, function astar(),

From:

ME = pSelEntity;
trace_mode=IGNORE_ME+IGNORE_PASSABLE+IGNORE_PASSENTS+IGNORE_SPRITES+USE_BOX;
result=trace(vDist1,vCurrent);
if(terrainMod==1){result=0;}
vDist1.X=0;
vDist1.Y=0;
vDist2.Z=vCurrent.Z;
if(result==0 && vec_dist(vDist1,vDist2)<nodeDist)

To this:

ME = pSelEntity;
result = c_trace(vDist1,vCurrent,IGNORE_ME+IGNORE_PASSABLE+IGNORE_PASSENTS+IGNORE_SPRITES);
if(terrainMod==1){trace_hit=0;}
vDist1.X=0;
vDist1.Y=0;
vDist2.Z=vCurrent.Z;
if(trace_hit==0 && vec_dist(vDist1,vDist2) < nodeDist)

The
"vec_dist(vDist1,vDist2) < nodeDist"
should allow for some verticle movement within the waypoints of Astar up to node distance, like stairs and such, I forget whether this was in Phillip Walser's original Astar program.

The updated code is at the same place in my 3dgs site Pathfinding - CrusadeAlpha01.zip .

Later,
Loco