Target selecting, tanking and chasing

[EternalHarvest]

OK. What will happen If we allow Chose of Attacked MOB to be modified by Plugins, still checking it's clearness.???

Implying it isn't allowed?

Code: Select all

# a plugin
package Misc;
sub getBestTarget { $_[0] && @{$_[0]} ? $_[0][0] : undef }

[kLabMouse]

OK. What will happen If we allow Chose of Attacked MOB to be modified by Plugins, still checking it's clearness.???

Implying it isn't allowed?

Code: Select all

# a plugin
package Misc;
sub getBestTarget { $_[0] && @{$_[0]} ? $_[0][0] : undef }

Well. Yeah. good solution too.
But I mean, using usual system that Plugins use: Hook.

[EternalHarvest]

What's the point of insisting on a plugin when existing code works incorrectly? It would probably be merged with trunk right away anyway.

[kLabMouse]

What's the point of insisting on a plugin when existing code works incorrectly? It would probably be merged with trunk right away anyway.

True. But for Different classes it's better to use Different code for Target Selection.
And thins way is better for 3rd party developers to create and check new algos.

[Darki]

That's relative... Target selection in my opinion doesn't need to diffier between classes. When you play you usually pick the closest monsters that you're planning on killing. Maybe priority in target selection is not that "human", because I only tend to avoid closer monsters in favor of my priorities when there's somebody on sight so I kill the better exp/drops before anybody else.

The difference between classes would come in the chasing routines, because if you're a fighter you have to get closer, if you're ranged you gotta be in range all the combat, and if you're caster you only need to be in range when targetting. The routine to select target would be to get the closest monsters of each priority (if existed), and pick the highest priority closest one. In case there's no priority, then just the closest of all. If during the route to catch the monster there's now a closer monster (or a higher priority one in range), then bot should switch target. There would be some exceptions to this; for example if the monster was already engaged but moved away, or if the bot is closer enough (like 2~3 squares), the bot wouldn't switch targets.

This, in case of fighters would make them to pick naturally the closest target and switch between them easily, while ranged classes would only switch targets if the original one was off range (as the monster would be engaged successfully if in range, so it wouldn't switch).

When I play I usually pick the closest monster, but I only switch targets for proximity when I'm playing a fighter because you lose time. Ranged and caster jobs, as anything in their range is instantly reachable, shouldn't care about switching enemies too often.

[Andrew08]

kore used to attack nearest monster. But now kore randomly attacking further one.

[madnoh]

kore used to attack nearest monster. But now kore randomly attacking further one.

I do not think so, because the bot perfectly and I did not do the unexpected.

so in my opinion, likely was less than perfect in the config.

sorry my english not very well

[EverythingIsAllright]

After an evening of disappointment, little me that has no knowlede of Pearl whatsoever, figured out the problem... i guess.
The respective code, that checks the list of avaliable monsters, apparently misses the distance check in 2 of 4 occasions (where weirdly in the other 2 the check was implemented)
Explicit i mean:

Code: Select all

if (!defined($highestPri) || ($priority{$name} > $highestPri)) {
			$highestPri = $priority{$name};
			$smallestDist = $dist;
			$bestTarget = $_;
		}
		if ((!defined($highestPri) || $priority{$name} == $highestPri)
		       && (!defined($smallestDist) || $dist < $smallestDist)) {
			$highestPri = $priority{$name};
			$smallestDist = $dist;
			$bestTarget = $_;
		}

When it says the checked monsters priority is greater than the last priority checked, (which is the case whenever you did not set any priority at all, i assume) it substitutes the just checked monster for the last one.
That way the outcome is, the overall last checked monster will be the $bestTarget.
So you basically have to weave

Code: Select all

 && (!defined($smallestDist) || $dist < $smallestDist)

into the first condition, which exists twice (once for line-of-sight monsters and once for the others), or set the desired monster explicit as the highest priority target i figure.
I`ve been maintaining my bot for about 30 minutes with this modification now, and it has yet to fail me.
On 10/10 occasions, where it had the opportunity to do its little dance, it didnt and killed the monsters one after the other in order of their distance.

If someone with knowledge of the code could check my suspicion, i would be happy, because maybe i didnt think of some issues that my little workaround could cause.

Greetz, EverythingIsAllright

[EternalHarvest]

After an evening of disappointment, little me that has no knowlede of Pearl whatsoever, figured out the problem... i guess.
The respective code, that checks the list of avaliable monsters, apparently misses the distance check in 2 of 4 occasions (where weirdly in the other 2 the check was implemented)
Explicit i mean:

Code: Select all

if (!defined($highestPri) || ($priority{$name} > $highestPri)) {
			$highestPri = $priority{$name};
			$smallestDist = $dist;
			$bestTarget = $_;
		}
		if ((!defined($highestPri) || $priority{$name} == $highestPri)
		       && (!defined($smallestDist) || $dist < $smallestDist)) {
			$highestPri = $priority{$name};
			$smallestDist = $dist;
			$bestTarget = $_;
		}

When it says the checked monsters priority is greater than the last priority checked, (which is the case whenever you did not set any priority at all, i assume) it substitutes the just checked monster for the last one.

Nope, in Perl undef's number value is 0. The real bug here is a bit different:

If you set no priority (quite a normal configuration for the majority of monsters), $priority{$name} (data from the control file) would be undef.
Then, $highestPri would become (or rather stay) undef as well.
Then, !defined($highestPri) condition (which is, I believe, used as a flag "no monsters are checked yet, so use the very first one") triggers for every monster which has no priority set.

It can be fixed, for example, by checking for !defined($bestTarget) ($bestTarget is always a number when any monster is marked as the best target so far) instead of !defined($highestPri) (diff includes addtional debug output for testing):

Code: Select all

@@ -3108,13 +3109,16 @@
 		##if ($nonLOSNotAllowed && ($config{'attackMaxDistance'} < $dist)) {
 		##	next;
 		##}
-		if (!defined($highestPri) || ($priority{$name} > $highestPri)) {
+		warning "possible attack target: $monster (@{$pos}{qw(x y)}, dist $dist)\n";
+		if (!defined($bestTarget) || ($priority{$name} > $highestPri)) {
+			warning "marking as the best (priority)\n";
 			$highestPri = $priority{$name};
 			$smallestDist = $dist;
 			$bestTarget = $_;
 		}
-		if ((!defined($highestPri) || $priority{$name} == $highestPri)
+		if ((!defined($bestTarget) || $priority{$name} == $highestPri)
 		  && (!defined($smallestDist) || $dist < $smallestDist)) {
+			warning "marking as the best (dist)\n";
 			$highestPri = $priority{$name};
 			$smallestDist = $dist;
 			$bestTarget = $_;
@@ -3129,12 +3133,12 @@
 			my $pos = calcPosition($monster);
 			my $name = lc $monster->{name};
 			my $dist = round(distance($myPos, $pos));
-			if (!defined($highestPri) || ($priority{$name} > $highestPri)) {
+			if (!defined($bestTarget) || ($priority{$name} > $highestPri)) {
 				$highestPri = $priority{$name};
 				$smallestDist = $dist;
 				$bestTarget = $_;
 			}
-			if ((!defined($highestPri) || $priority{$name} == $highestPri)
+			if ((!defined($bestTarget) || $priority{$name} == $highestPri)
 			  && (!defined($smallestDist) || $dist < $smallestDist)) {
 				$highestPri = $priority{$name};
 				$smallestDist = $dist;

Try this.

[EternalHarvest]

The respective code, that checks the list of avaliable monsters, apparently misses the distance check in 2 of 4 occasions (where weirdly in the other 2 the check was implemented)

That's right, if monster has the higher priority, it should be chosen regardless of distance. Your fix works in case there are no priorities set.