Page 1 of 1
Getting off course
Posted: Tue Nov 09, 2010 10:30 pm
by rock5
I have MAX_TARGET_DIST set to 200 but I find my player chasing mobs 400 to 500 away from my path. I thought we fixed this. Didn't we?
Re: Getting off course
Posted: Tue Nov 09, 2010 10:45 pm
by jduartedj
rock5 wrote:I have MAX_TARGET_DIST set to 200 but I find my player chasing mobs 400 to 500 away from my path. I thought we fixed this. Didn't we?
Hey i've been looking for that option and now i found it! useful also near cliffs!
BTW aren't these options deprecated? (below)
Code: Select all
HARVEST_SCAN_WIDTH = 5, -- steps horizontal
HARVEST_SCAN_HEIGHT = 5, -- steps vertical
HARVEST_SCAN_STEPSIZE = 60, -- wide of every step
HARVEST_SCAN_TOPDOWN = false, -- true = top->down false = botton->up
HARVEST_SCAN_XMULTIPLIER = 1.0, -- multiplier for scan width
HARVEST_SCAN_YMULTIPLIER = 1.1, -- multiplier for scan line height
HARVEST_SCAN_YREST = 10, -- scanspeed
HARVEST_SCAN_YMOVE = 1.1, -- move scan area
Re: Getting off course
Posted: Tue Nov 09, 2010 11:54 pm
by rock5
jduartedj wrote:BTW aren't these options deprecated? (below)
Code: Select all
HARVEST_SCAN_WIDTH = 5, -- steps horizontal
HARVEST_SCAN_HEIGHT = 5, -- steps vertical
HARVEST_SCAN_STEPSIZE = 60, -- wide of every step
HARVEST_SCAN_TOPDOWN = false, -- true = top->down false = botton->up
HARVEST_SCAN_XMULTIPLIER = 1.0, -- multiplier for scan width
HARVEST_SCAN_YMULTIPLIER = 1.1, -- multiplier for scan line height
HARVEST_SCAN_YREST = 10, -- scanspeed
HARVEST_SCAN_YMOVE = 1.1, -- move scan area
Yes, of course they are deprecated ... and off topic.
I'll describe better what happens.
First it targets a mob about 150 away and kills it. Then it targets a mob a further 150 away and kills it. Then it targets another mob about 150 away and kills it.
By the time there are no more mobs, it has killed about 3-4 mobs and has to travel about 450-500 to get back.
Looking at the code it looks like the code to check the distance to the path was added way back in revision 487 by Administrator. Did it used to work?
Re: Getting off course
Posted: Wed Nov 10, 2010 1:48 pm
by jduartedj
rock5 wrote:
Yes, of course they are deprecated ... and off topic.
I'll describe better what happens.
First it targets a mob about 150 away and kills it. Then it targets a mob a further 150 away and kills it. Then it targets another mob about 150 away and kills it.
By the time there are no more mobs, it has killed about 3-4 mobs and has to travel about 450-500 to get back.
Looking at the code it looks like the code to check the distance to the path was added way back in revision 487 by Administrator. Did it used to work?
Sorry about the off topic;
But can't you just make a variable that conserves the distance from the original path and them use it?
like so:
variable is distance and max is 150.
1. get a mob at 100.
2. attack it
3. get a mob at another 50 or less and attack it, repeat until sum of distances is 150 or +
-- or
3. get a mob at 50+ and don't attack it
4. return to path
Re: Getting off course
Posted: Wed Nov 10, 2010 8:34 pm
by rock5
Like I said, the code is there but doesn't seem to work properly.
I tested the "getNearestSegmentPoint()" function and it seems to work.
Next I had a look at the section in "evalTargetDefault" to do with MAX_TARGET_DIST" and I think I see the problem.
Code: Select all
if( (not target.Aggressive) and (__WPL:getMode() == "waypoints") ) then
-- We only want passive creatures near our waypoint path
local pA = wpl:getNextWaypoint();--CWaypoint(wpl.Waypoints[wpl.CurrentWaypoint].X, wpl.Waypoints[wpl.CurrentWaypoint].Z);
local pB = wpl:getNextWaypoint(1);
V = getNearestSegmentPoint(player.X, player.Z, pA.X, pA.Z, pB.X, pB.Z);
else
-- We'll fight aggressive creatures that are near the player
-- or any creature if we're not using a proper waypoint list
V = CWaypoint(player.X, player.Z);
end
This only checks the distance from the path only if the mob is
not aggressive which is wrong. It should always check distance to path. I'm not sure why Administrator did it this way. I'll change it and do some testing.
Re: Getting off course
Posted: Wed Nov 10, 2010 10:32 pm
by rock5
This is working but I'm not sure I like the logic.
There are 2 things to check;
1. If the mob is close enough to the player and
2. If the mob is close enough to the path.
The way it works now is to merge the 2 by checking the distance of the mob to the point on the path that is closest to the player. That means it is possible to have a mob that is within the MAX_TARGET_DIST distance from the path and close to the player but not be deemed a valid target. Here is a diagram showing what I mean.
It probably would eventually get targeted but the point is, at that moment, the target should be valid but isn't.
I think I'll change it to 2 separate tests that way anything in the green zone that is within range of the player will be targeted.
We could use MAX_TARGET_DISTANCE for both tests but I think it would be better with another variable for 'distance from path'. That way you could set the 'distance from path' to a small value on treacherous paths without changing MAX_TARGET_DISTANCE.
What do you think?
Re: Getting off course
Posted: Thu Nov 11, 2010 12:27 am
by rock5
Also, this looks to be wrong as these are the waypoint you are heading towards and the one after that. It should be the one you are coming from and the one you are going to.
Code: Select all
local pA = wpl:getNextWaypoint();
local pB = wpl:getNextWaypoint(1);
Even if we used;
Code: Select all
local pA = wpl:getNextWaypoint(-1);
local pB = wpl:getNextWaypoint();
(assuming -1 is allowed) it still wouldn't be right because the waypoint you are coming from might not be the waypoint number you are heading to - 1. For example when the user uses __WPL:setWaypointIndex().
I'll talk to the Administrator about using a variable to remember the last waypoint number.
Re: Getting off course
Posted: Fri Nov 12, 2010 8:47 pm
by rock5
Here is a comparison of as it is now and how it would move if the 2 distance tests were separate.