i just realized that it's likely because the npc's target is at the top of the hate list (the first entity in the array), and the loop you have is trying to get the npc to cast the spell on a new target while he's still casting on the first one.

you could attempt to address this by putting a delay (sleep($seconds)) equal to the cast time of the spell in the loop (you'd want to place it after the casting has begun). you could also check $npc->IsCasting() periodically to see if you needed to continue on to the next target. that way you wouldn't have a lengthy delay between casts if the cast was ever interrupted by the players. i'm not sure what sort of load that would cause on the server, however.

DUH.

or you could set the cast time to 0 in CastSpell()... i forgot that one. :)

CastSpell(spell_id, target_id, slot= 10, casttime= -1, mana_cost= -1)

The spell didn't have a cast time in the first place. I couldn't get it to work with npc->CastSpell, but for some reason, quest::castspell works perfectly.

in the source code, quest::castspell() calls Mob::SpellFinished() while $npc->CastSpell() calls Mob::CastSpell(). i haven't looked over the source to be able to tell you exactly what the difference is, nor do i know the benefits of using one instead of the other (except for the fact that only one is working for you).

looks like quest::castspell() skips a lot of the validation checks (movement, stun, combat, etc) and timers involved with spell casting. i'm going to have to guess that the problem with using $npc->CastSpell() is still timer related, since it hits one target when you use it. otherwise, clients would probably see interruption messages while in combat with the npc in question.