Getting off course

[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?

[jduartedj]

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 

[rock5]

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?

[jduartedj]

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

[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.

[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?

[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.

[rock5]

Here is a comparison of as it is now and how it would move if the 2 distance tests were separate.