Event_proximity_say

[Derision]

Following discussion in another thread, I added a new EVENT_PROXIMITY_SAY.

Example quest:

sub EVENT_SPAWN {
   $x = $npc->GetX();
   $y = $npc->GetY();
   quest::set_proximity($x - 500, $x + 500, $y - 500, $y + 500);
}

sub EVENT_PROXIMITY_SAY {

        if($text=~/hate bixby/i) {
                quest::shout("So $name hates me huh ? I'll show you!");
                quest::attack($name);
        }
}

The way it works is this. When you call quest::set_proximity, the code checks to see if the NPC also has an EVENT_PROXIMITY_SAY. If it does, it sets a flag in the proximity entry, and also sets a global flag to indicate that EVENT_PROXIMITY_SAY is in use for this instance of this zone.

When a client says something and has nothing targetted, if the global flag is set, the proximities are run through, looking for one that is associated with an NPC that has an EVENT_PROXIMITY_SAY and for which the client is within the proximity.

I'm unsure as to whether the EVENT_PROXIMITY_SAY should be called even if the player has something targetted. You quest writers let me know and I can change it if required.

[So_1337]

Very nice work, as always. I do have one concern that needs to be stated, though. I can only imagine what would happen if a group of NPCs that all have the PROXIMITY_SAY activated and all have "hail" triggers were to be used in a populated zone like PoK. They'd be talking non-stop, to no one nearby.

With that in mind I'd have to say this is something that should only be used in a very few limited instances, such as the throne in Kael for the Coldain Ring quest line. Not something that we should go back and blanket all quest givers with.

Just that quick word of caution. Other than that, brilliant work! =)

[Andrew80k]

Oh, I was thinking about putting these on my buffers in PoK to see if they would talk to each other if I was sitting in the middle of them. Setup some random phrases...could be a lot of fun.

[janusd]

I Love You Derision!

[blackdragonsdg]

Originally Posted by So_1337

Very nice work, as always. I do have one concern that needs to be stated, though. I can only imagine what would happen if a group of NPCs that all have the PROXIMITY_SAY activated and all have "hail" triggers were to be used in a populated zone like PoK. They'd be talking non-stop, to no one nearby.

With that in mind I'd have to say this is something that should only be used in a very few limited instances, such as the throne in Kael for the Coldain Ring quest line. Not something that we should go back and blanket all quest givers with.

Just that quick word of caution. Other than that, brilliant work! =)

Triggering multiple npc's could be overcome with a check to see which npc has priority. What i mean is if multiple npcs would be triggered use the distance from you to the npc's to determine which one you are closest to and make the closest have priority. If it is a class specific quest you could make the check look at the characters class and only trigger on a specific class. You could also use targeting or any other form of check to help keep npc's from chattering mindlessly.

[trevius]

That is really awesome, Derision! Very nice way of handling it without causing too much overhead.

Personally, I think that the target should not matter. If they are within the proximity, it should parse the say, target or not. If someone wanted to require a target, they can always put that requirement into the script easy enough.

One example I can think of for this is the invisible NPC in PoGrowth that would kill you if you said something like "ph4t l3wtz" and were in range of it. Obviously, you wouldn't have this targeted when you said this, but if you targeted yourself, a group member or any other NPC in the zone, I still think it should parse that say. It isn't really a big deal, but just something to consider. Either way, I am glad to see this functionality added. I am sure Kayen and myself can come up with some fun uses for it on Storm Haven

[joligario]

May want to ignore "hail" in that if you are going to do non-target responses. Would be funny to hear 10 NPCs in PoK respond to 1 hail...

[trevius]

You may be misunderstanding what this is for. This will not effect how any current NPC scripts work. So, you won't see 10 NPCs in pok responding to a hail unless that is something that was setup specifically to be that way by the script writer. I don't think hail should be ignored. If someone wants hail to require a target, they could set it that way.

What if I wanted to write a quest where people have to go through a zone looking for an invisible NPC and the only way to find them is by running around hailing to see if they get a response?

sub EVENT_SPAWN {
   $x = $npc->GetX();
   $y = $npc->GetY();
   quest::set_proximity($x - 500, $x + 500, $y - 500, $y + 500);
}

sub EVENT_PROXIMITY_SAY {

        if($text=~/Hail/i) {
                quest::me("A mysterious voice responds from the darkness.");
                quest::say("So, you have found me at last.  Would you please [free] my soul?");
        }

#and so on...
}

IMO, the proximity say should have no restrictions, because any wanted restriction could be added by the script writer in the individual script. Proximity say probably won't be used overly much, so there isn't much reason to set restrictions on it. But, it will certainly be nice to have the option to use it now.

I didn't check the code for it yet, but I was curious if Proximity says would work even if the NPC has aggro on the player?

[joligario]

Ah, I see. Yeah, no problem then.

[trevius]

I went ahead and removed the No Target requirement for proximity says. So, now you can have a target and still trigger a proximity say, which I think makes them a bit more flexible. You can still check for a target within the script easily enough if you really don't want the player to have a target when triggering a proximity say.