ID:906587
 
Keywords: npc, talk, talking, to
Code:
Problem description: Well what i was wondering is how could someone(myself)create such a code to where if a player is near a NPC let say right next to them and if the player were to say hello or something then the NPC would say Hello or what ever I want to say. with that being said i mean without them having to rick click or double click or press anything but to have the NPC like read what they say and reply accordingly.
A very basic form would be something like this, you can play with it till it suits your needs.
mob
npc
talker
var
list/triggers = list()
response = ""

verb
Say(msg as text)
for(var/mob/npc/talker/M in oview(1))
if(istype(M, /mob/npc/talker))
if(msg in M.triggers)
src << M.response
oh okay thanks
In response to GreatFisher
It didn't work, but maybe i did it wrong here is what i did.

mob
npc
talker
var
list/triggers = list("Hi","Hello")
response = "Hello."

verb
NPCTalk(msg as text)
for(var/mob/npc/talker/M in oview(2))
if(istype(M, /mob/npc/talker))
if(msg in M.triggers)
src << M.response
First use dm tags when showing code and second I didn't test it I probably should of done.
It works perfectly for me. You have to say one of the things in the triggers list exactly correct capitals and all.
still didn't work
Well it works for me so not sure how I can help you there.
In response to Joejoe13
Joejoe13 wrote:
still didn't work


How are you testing this? When standing next to the NPC are you saying "hello", or "Hello"?
I'm Saying Hello
but maybe i have it in my say verb wrong. i have it like this.
mob
verb
Say(msg as text)

if(!usr.OOC)
return
if(usr.testing)
usr<<"Not right now!"
return
if(filter(msg,tags) == TRUE) //if the msg has profanity in it
usr.html() // call the proc
return
if(filter(msg,profane) == TRUE) //if the msg has profanity in it
usr.profane() // call the proc
return //stop it from sending
if(filter(msg,bannedwords) == TRUE) // if the msg has banned words in it
usr.bannedwords() //call the proc
return
else //if it checks out
if(spamcheck == TRUE)//if the player is spamming
usr << "Spam rate exceeded please wait a moment and try again!"//tell him to wait for a second
return //stop it from sending
else//if the message is ok to send
usr.spamcheck()//check for spam
msg=cuttext(msg)
view(usr) << output("<font size=1><font face=verdana><b><font color=white>[usr]<font color=green> Says: [msg]","chat")
if(log)//if logging is turned on
text2file("[time2text(world.realtime)]:[usr] says, [msg]","log.txt") // add it to the log
for(var/mob/M in oview(usr))
if(M.isGedouRinneTensei)
for(var/mob/GedouJutsu/GedouBody/G)
if(G.owner == usr)
G.owner<< output("<font size=1><font face=verdana><b><font color=white>[usr]<font color=green> Says: [msg]","chat")
view(G) << "<font size=1><font face=verdana><b><font color=white>[G]:<font color=green> [msg]"
for(var/mob/npc/talker/M in oview(1))
if(istype(M, /mob/npc/talker))
if(msg in M.triggers)
src << M.response
mob/verb/say(T as text)
world<<"[src] says [T]"
for(var/mob/Mushroom/M in oview(1))
if(M)
if(findtext(T,"Hello"||"hello")==0)
src<<"<font color = maroon><b><small>NPC: [M] says what a nice day."
else
src<<"<font color = maroon><b><small>NPC: [M] says hello there..."
In response to Liight
No. Don't try to help.
In response to Liight
Hi Liight,

It is nice to see you are helping other people out, however, when posting a snippet - please do try to use the <DM></DM> tags.

In addition, there were some syntax problems in the snippet you provided - such as the "Hello"||"hello" - that's not how you do it. Not to mention that findtext() is NOT case sensitive.

When making in interactive talk system, it is best to make a procedure that will parse through the text:
User/verb/Say(t as text)
var/NPC/N = locate(/NPC) in get_step(src, src.dir) // looking for /NPC type one step ahead
if(N && N.Listen(t, src)) // If an /NPC is there and the Listen() proc returns 1 then the message is not said out loud (as return will stop it)
return 1

oview(src, 5) << t // This message will be said around if there was no NPC or if the command was incorrect.


NPC
proc/Listen(var/msg, var/mob/Talking) // Defining the default Listen() procedure
var/general_hello = list("hi", "hello", "yo")
for(var/t in general_hello)
if(findtext(msg, t)) // if one of the words above was present, ex: higher = *hi*gher!
Talking << "[src.name]: Why, hello there..."
return 1
return 0


Mystery_Man
Listen(var/msg, var/mob/M)
if(..()) return 1 // This calls the default (which checks for 'hello' and will stop if hello is found)

else if(findtext(msg,"blood") && findtext(t,"hound")) // If hound and blood is in a sentence. Ex: Bloody hound!
M.Quest.Start(BLOOD_HOUND)

else if(findtext(msg,"banana"))
M.Quest.Start(BANANA_PHONE)

else if(lowertext(msg) == "secret_quest") // Who says you need to use findtext()? If the person said sEcReT_quesT, this would work as lowertext() makes everything lower text... however, if the person said "secret_quest " with a space after, it would not work
M.Quest.Start(SECRET_QUEST)

else return 0 // If none of the Listen() option messages were there, it returns 0 telling the person to send their Say() out loud.
return 1 // Note that else has return 0. The blood hound and banana quest options do not return, so it continues and this if the result - a return 1!


You could set it up so a response to a /NPC can hyperlinked which forces the person to Say() that specific message... but you would need to know how to use Topic(). The actual linking is simple:
Talking << {"Why hello there. Do you mind looking for my  <a href="?command=talk&msg=BANANA">phone</a>?"
which would appear as Why hello there. Do you mind looking for my phone?
ah well x.x sorry i guess
I'd like to waylay this conversation a bit for a brief game-design rant.

While yes, it's cool that you can choose what to say to an NPC, it's generally considered a failed gameplay mechanic. It fell out of use in the late 80s and early 90s RPGs. (Notably, the Ultima Avatar saga (4-6).

The competing means of communicating with an NPC were the western method of lists of conversation cues. The eastern method was rod-iron communication, in which conversation only has a single topic, which changes according to what part of the game the player is currently engaged in.

Obviously, the topic list method and contextual method have won out over the parsed method. This is not to say that you cannot, or should not attempt to use the parsed method, it merely means that players are going to be more familiar with the other two methods of communication with in-game NPCs.

Before you implement a feature into a videogame, it is important to ask yourself "Why would I want to?". Novice developers tend to work too hard to bloat their project with unnecessary "You can" features, but neglect to consider "Why would I?".

Consider the benefits of this system. The benefits are merely that players are going to be considerably less likely to find secret conversational cues. This can add to the mystery of your world.

However, the negatives are quite obvious, and outweigh the benefit. Players are likely to make mistakes. It's going to frustrate your players. It's less accessible to players, and that one negative is enough to really genuinely consider against implementing this feature.

Again, I've been around BYOND for going on 11 years now, and watched as developer after developer has bloated their project with unnecessary gameplay mechanics without stopping to consider why those gameplay mechanics are "unique". Being "unique" isn't nearly enough to justify a feature when you are talking about a videogame. One must also consider that "unique" is not always a good thing. Often, something is "unique" in the wrong way, "unique" because no other game developer would implement a feature because it would simply detract from the playability of said game.