NPC < < input

ID:137870
 
Jun 27 2001, 3:56 pm
I know that < < was basically meant to send information (text, sounds, images, etc) to a player mob, but why not to a non-player mob?

For example, I discovered with glee tonight that I could actually send a proc (undocumented?) as input thusly: 
mob
  verb/whistle()
    usr << "You whistle..."
    orange(src) << hear_whistle()

  proc/hear_whistle()
    world << "[src] heard a whistle" // just a test line

When the whistle verb is used, the proc is called for PCs in the area, but not for NPCs.

I know I can easily code around this by cycling through mobs in the range, and calling the proc for each, but the attempt above would have been so much slicker.

Besides which, I think there should be a way for NPCs to react to text they hear. If you say something, and an NPC overhears it, it should be able to comment. They could even comment on, or react to shouts!

Yes, it's all kludgeable, but I guess you can put me down for requesting this for 3.0.

Carry on,

mob/skysaw</<>
Jun 27 2001, 4:12 pm
verb/whistle()
usr << "You whistle..."
orange(src) << hear_whistle()

Shouldn't orange(src) << hear_whistle() send the return value of hear_whistle() to every mob in orange? Which is, by default, null, so nothing gets output. (Is there no good past tense to output? Outputted sounds lame.)

And its pretty easy to make NPC's react to text, you just have to have a react proc that is called everyone time someone speaks, and pass it the text that was spoken. Then code away reactions however you want.

-AbyssDragon
Jun 27 2001, 4:15 pm
In response to AbyssDragon
On 6/27/01 7:12 pm AbyssDragon wrote:
verb/whistle()
usr << "You whistle..."
orange(src) << hear_whistle()

Shouldn't orange(src) << hear_whistle() send the return value of hear_whistle() to every mob in orange? Which is, by default, null, so nothing gets output. (Is there no good past tense to output? Outputted sounds lame.)

And its pretty easy to make NPC's react to text, you just have to have a react proc that is called everyone time someone speaks, and pass it the text that was spoken. Then code away reactions however you want.

-AbyssDragon

Hmm... it's possible that that is what is happening, in which case I take back the glee.

In any case, as I said, I have no trouble coding the behaviour I said I wanted. But I also have no problem in being given a cooler way to do it. Especially if it helps me code more lazily.
Jun 27 2001, 4:44 pm
In response to Skysaw
On 6/27/01 7:15 pm Skysaw wrote:
On 6/27/01 7:12 pm AbyssDragon wrote:
verb/whistle()
usr << "You whistle..."
orange(src) << hear_whistle()

Shouldn't orange(src) << hear_whistle() send the return value of hear_whistle() to every mob in orange? Which is, by default, null, so nothing gets output. (Is there no good past tense to output? Outputted sounds lame.)

And its pretty easy to make NPC's react to text, you just have to have a react proc that is called everyone time someone speaks, and pass it the text that was spoken. Then code away reactions however you want.

-AbyssDragon

Hmm... it's possible that that is what is happening, in which case I take back the glee.

In any case, as I said, I have no trouble coding the behaviour I said I wanted. But I also have no problem in being given a cooler way to do it. Especially if it helps me code more lazily.

My attitude here is: you're going to have to do some pretty substantial coding to make the NPCs react to the text anyway... getting the text to them in order for them to react is the easy part.

My games tend to parse "speech" type communications pretty heavily, anyway... (for example: if someone says the name of an administrative goddess currently online in LexyMUD, the text is relayed to said goddess.) So if I needed NPC reactions, I'd just code them in that proc.
Jun 28 2001, 3:55 am
In response to LexyBitch
On 6/27/01 7:44 pm LexyBitch wrote:
My games tend to parse "speech" type communications pretty heavily, anyway... (for example: if someone says the name of an administrative goddess currently online in LexyMUD, the text is relayed to said goddess.) So if I needed NPC reactions, I'd just code them in that proc.

*Remembers not to badmouth Lexy in her games* ;)
Jun 28 2001, 6:17 am

For example, I discovered with glee tonight that I could actually send a proc (undocumented?) as input


Yeah, actually AbyssDragon's comment is correct: it sends the return value of the proc, rather than calling the proc for each target in the list. What you happened to see was that the value of 'usr' got passed into the proc, not from the target list, but from the value of 'usr' in the calling proc. Hope that makes sense to you. This happens to be more efficient in most cases, because usually the same text gets sent to everyone in the target list, so it would be a big waste to call the proc once for each target (especially if you do something like world << Blah()). Also, not everyone would expect the value of 'usr' to change to the target in a case like that.

For now, you will want to use your own procedure to handle message broadcasts. Perhaps we can add a convenience in the future for this purpose.

Code on!

Jun 28 2001, 6:24 am
In response to Dan
On 6/28/01 9:17 am Dan wrote:
For example, I discovered with glee tonight that I could actually send a proc (undocumented?) as input


Yeah, actually AbyssDragon's comment is correct: it sends the return value of the proc, rather than calling the proc for each target in the list. What you happened to see was that the value of 'usr' got passed into the proc, not from the target list, but from the value of 'usr' in the calling proc. Hope that makes sense to you. This happens to be more efficient in most cases, because usually the same text gets sent to everyone in the target list, so it would be a big waste to call the proc once for each target (especially if you do something like world << Blah()). Also, not everyone would expect the value of 'usr' to change to the target in a case like that.

For now, you will want to use your own procedure to handle message broadcasts. Perhaps we can add a convenience in the future for this purpose.

Code on!

Yes, I realized the folly of my question (at of all times) as I drifted off to sleep last night. Of course this is what was happening!

"Most cases" would be accurate for what is most efficient, however, if you wanted each mob to handle the input in its own way, tickling a proc could be very efficient this way, as opposed to cycling through appropriate mobs and calling each individually.