Flight
2011-03-29 10:12:03
Here's an example of how 'all' bots, using NPC/Object tracking, will find the nearest object.
The Red line represents the path taken to get to the nearest object.

Notice that even though it takes longer to get to the nearest object, the bot will still do so, ignoring the closest object to get to in the time factor. So why is this? Has this issue ever been brought up before, or has anyone tried to find a more realistic alternative?
Well, I gave it a shot, and at my current progress I've just gotten to debugging how many objects (intractable) are within the path from you to your destination. If we could use this, or a much further modified version of this, to estimate the closest objects to us in time rather than distance, we could have the advantage above all in speed and as well as human-characteristics.
Ok, here's my little debugger tool, just define the destination's tile and it'll tell you how many objects lay in your path. BIG thanks to TRiLeZ, the bulk of the code is from him.
So my idea is this: For example I'll use "GetObjectByIDEx" Find the nearest and second nearest object tiles, use my bit of code to detect which of the two tiles has the most objects laying in the path, compare the distance - to - objectcount to determine which object is the real nearest.
Of course this is very much just a rough draft and is no where near official, but anyways you get the idea of how this could be possible. This part: "MyObj := GetObjectAt(ObjTile, OBJECT_TYPE_INTERACTABLE);" could be changed to wall objects or even floor objects such as water. If you've ever seen the bots in the fishing guild fishing on Dock A, when their spot moves just 5 tiles away on the same dock, they'll instead run all the way to the other dock just because it's closer to their current X/Y.
So post your thoughts on how this might be done. Don't hand me bits of code because I think beyond this point it's out of my league. :( But you could imagine the advantage this would give us…
The Red line represents the path taken to get to the nearest object.

Notice that even though it takes longer to get to the nearest object, the bot will still do so, ignoring the closest object to get to in the time factor. So why is this? Has this issue ever been brought up before, or has anyone tried to find a more realistic alternative?
Well, I gave it a shot, and at my current progress I've just gotten to debugging how many objects (intractable) are within the path from you to your destination. If we could use this, or a much further modified version of this, to estimate the closest objects to us in time rather than distance, we could have the advantage above all in speed and as well as human-characteristics.
Ok, here's my little debugger tool, just define the destination's tile and it'll tell you how many objects lay in your path. BIG thanks to TRiLeZ, the bulk of the code is from him.
{*******************************************************************************
Procedure getObjCount
By: Flight
Description: Returns the # of obj's between you and your target
*******************************************************************************}
Procedure getObjCount(DestTile: TTile);
Var
myTile,ObjTile: TTile;
xDist,yDist,tDist,xStep,
yStep,xN,yN,i,Count: integer;
myObj: TRSObject;
begin
myTile := GetMyPos;
tDist := Distance(myTile.x, myTile.y, DestTile.x, DestTile.y);
if (tDist <= 1) then
Exit;
if (DestTile.x > myTile.x) then
xDist := (DestTile.x - myTile.x);
if (DestTile.x < myTile.x) then
xDist := (myTile.x - DestTile.x);
if (DestTile.y > myTile.y) then
yDist := (DestTile.y - myTile.y);
if (DestTile.y < myTile.y) then
yDist := (myTile.y - DestTile.y);
xStep := (xDist / tDist);
yStep := (yDist / tDist);
for i := 1 to tDist do
begin
if (DestTile.x > myTile.x) then
xN := myTile.x + (xStep * i);
if (DestTile.x < myTile.x) then
xN := myTile.x - (xStep * i);
if (DestTile.x = myTile.x) then
xN := myTile.x;
if (DestTile.y > myTile.y) then
yN := myTile.y + (yStep * i);
if (DestTile.y < myTile.y) then
yN := myTile.y - (yStep * i);
if (DestTile.y = myTile.y) then
yN := myTile.y;
ObjTile := PointToTile(Point(xN,yN));
MyObj := GetObjectAt(ObjTile, OBJECT_TYPE_INTERACTABLE);
if MyObj.ID > 0 then
Inc(Count);
//writeln ('ID: '+inttostr(MyObj.ID)+', Tile('+inttostr(MyObj.Tile.x)+','+inttostr(MyObj.Tile.y)+')');
end;
Count := Count-1; //Because it counts your target tile
if (Count < 0) then
Count := 0;
writeln(''+IntToStr(Count)+' objects in path.');
end;So my idea is this: For example I'll use "GetObjectByIDEx" Find the nearest and second nearest object tiles, use my bit of code to detect which of the two tiles has the most objects laying in the path, compare the distance - to - objectcount to determine which object is the real nearest.
Of course this is very much just a rough draft and is no where near official, but anyways you get the idea of how this could be possible. This part: "MyObj := GetObjectAt(ObjTile, OBJECT_TYPE_INTERACTABLE);" could be changed to wall objects or even floor objects such as water. If you've ever seen the bots in the fishing guild fishing on Dock A, when their spot moves just 5 tiles away on the same dock, they'll instead run all the way to the other dock just because it's closer to their current X/Y.
So post your thoughts on how this might be done. Don't hand me bits of code because I think beyond this point it's out of my league. :( But you could imagine the advantage this would give us…