# The Ways of the Power of MUDChat
Basic Chat.Dat Information ChatGroups Applying MUDChat Behaviors Grinder Method Create/Modify MOB Method Some MUDChat Power Tricks | The purpose of this document is to understand the MUDChat behavior and the richness it can add to a world. No programming is needed. ## Basic Chat.Dat Information If you've ever popped open the resources/chat.dat file and tried to read the instructions, you'll be familiar with this:
    #There are several "operators" available:
    # pattern matching: Which work only in ( string | string & (str ~ str))
    # | or
    # & and
    # ~ and-not
    # special pattern matching:
    # ^ match start This anchors the match to the beginning of the
    # input string.
    # = exact match This must match the input string entirely.
    # / beginning and end of a coffeemud specific zappermask
    # pass 1 scan operators:
    # ( beginning of a 'say' expression
    # [ beginning of a non-say expression targeted
    # { beginning of a non-say expression not targeted
    # * combat expression, must preceed (, [, or {
    # # remark
    # " output to stderr
    # ' output to stdout
    # > start of named database, there can be more than one name
    # to a database '> dragon red_dragon' The _ here is treated
    # as a space in the name.   You may also use the / operator.
    # % include another file inline Ex: %talk.data
    # @ adds a continue jump to link to the database. Ex: @dog
    # will make a continue link to the dog database. Use @default
    # to link to the default database. Only 1 @ per database.
    # @ cannot do forward links!!!
    # @ is more memory efficient than % but less flexible.
    # You must avoid circularities with @.
    # response operators:
    # 1-9 weights are the numerals. First column only. Mandatory.
    # " Issue response as "say". Muds and 2nd column only. Optional.
    # : Issue response as "emote". Muds and 2nd column only. Optional.
    # ! Issue response as command. Muds and 2nd column only. Optional.
    # Note, you do not need a space after an :,", or !
    #
    # $? Are variables where ? is a case sensitive letter.
    # $r is rest of sentence, $n is its name, $t is target's name.
    # They may appear anywhere in the response, multiple times.
    #
    #Some special notes:
    # #,',",weights, and the first (,[,or { must be in column one.
    #
    #Syntax of a simple pattern match:
    #
    #( A | B & C ~ ( D | E | F)) 'say command targeted at the mob
    #[ A | B & C ~ ( D | E | F)] 'another action targeted at the mob
    #{ A | B & C ~ ( D | E | F)} 'another action not targeted at mob
    #
    #The above would mean if A or B and C and-not D or E or F was in the
    #sentence then pick one of the responses.
    #
    #The responses take on the form:
    #
    #9this is most likely
    #4somewhat likely
    #1least likely
    #
    #Responses or pattern match strings may not span more than one line.
    #The guaranteed line length is a magic 80 characters (letters) wide.
    #
    #Please note the system will return the first match found. So
    #please put more ambiguous matches last!!
    #
Helpful and clear, eh? Here's a better breakdown. The chat.dat file is basically a giant text file that is used for pattern-matching, with a couple of extra features. What this means is that you enter 'trigger' text and when the MOB hears someone say it, they'll respond with whatever you set for them to say. An example is warranted: Bo decides he wants MOBs to praise CoffeeMud in a couple ways when it's mentioned. He opens up his chat.dat file. He would enter this:
    (coffeemud)
    9I've heard of CoffeeMud. Isn't that that slick Java MUD codebase?
    6CoffeeMud? What the heck is that?
    2:smiles warmly.
There's a few different things to understand there. Let's break it down by lines: (coffeemud)- This is the trigger text. Anyone saying "Hey - how do you feel about CoffeeMud?", "whats coffeemud", or anything else with (case insensitive) 'coffeemud' in it will trigger the following response lines. 9I've heard of... 2:smiles warmly.- These are the possible responses. This is where things get a little trickier. The system is looking for what's in the first two columns: The first column must be a number (the weight), from 1-9. It's not exactly a percentage type thing, but just understand that 9 means it's really likely and 1 means highly unlikely. You can have as many possible responses as you'd like at whatever weight you'd like. The second column optionally can be either ':' or '!'. If it's neither, the MOB will simply say the line. If it's ':', then the MOB will emote the line. If it's '!', the MOB will treat the line as a command. (Don't worry, examples of those are included as well.) The other thing to note here is that you don't need a space after either the 1st or 2nd columns. So, bearing that in mind, it's most likely the MOB, upon hearing 'coffeemud', will say 'I've heard of CoffeeMud. Isn't that that slick Java MUD codebase?', may say 'CoffeeMud? What the heck is that?', or (least likely, it will emote 'smiles warmly'). So, with those basics of responses clear, you can do some fancier things pattern matching that just one word patterns. There are and, or, and and-not characters you can use in the pattern matching. & - This is the obvious and character. So (java&mud) would trigger on anyone saying both 'java' and 'mud' in the same sentence. | - This is the or character. So (hello|hi) would trigger on anyone saying either 'hello' or 'hi' ~ - This is the and-not character. So, "c1">(kill~yourself) would trigger on anyone saying 'kill' but would if anyone said 'kill him yourself' etc.. / - This is the zapper mask character, so (coffeemud&/-GENDER +FEMALE/) would trigger only if a female says coffeemud. See help on ZAPPERMASK for more information. Note: You can also use all of the <S-HIS-HER> type codes that Bo setup. (See Programming Guide) ### ChatGroups There's some very unhelpful sentences in there about databases. This is a better explanation. There are several ChatGroups defined in the distribution copy of chat.dat. Some are pretty clear. Here's one (shortened a bit):
    ############################################################
    >healer cleric doctor

    (hi|hello)
    9hello $t, how may I help you?
    2I could heal you.

    (help & (healer|cleric|doctor) | hurt | pain | sick)
    7:prays for you
    2Please undress, so I can see your injuries.
    5You look great.

    (job|career)
    7I cure the pitiful
    1I am a healer

    @default
You'll find this pretty much at the end of the file. What this means, is the ChatGroup is named "healer", "cleric", and "doctor" (the line of #'s is just remark characters, marking it up a bit for readability - it's the '>' that marks a ChatGroup). So, any MOB set to the ChatGroups 'healer', 'cleric', or 'doctor' will respond with these patterns. Another trick you can use to narrow matches on a ChatGroup with the > command is to include a CoffeeMud Zapper Mask. In that case the zapper masks would be included in your set of matching words by surrounding it with '/' characters like so:
    >healer cleric doctor /-GENDER +female/
> Adding the mask at the end will give the additional requirement that the healer be a female before the chat group is matched. Check the Archon help files on ZAPPERMASK for more information on the kinds of values you can put in there. At the bottom of our original ChatGroup is a linking character, @, pointing to default. That means that this group will respond with the pattern you see here first, and if nothing matches, will then go on to check in the default for matches. The default ChatGroup is simply any patterns entered BEFORE any other ChatGroups are defined, hence why all the ChatGroups are, and should be, towards the bottom. There are some caveats to using @. You can only link to groups that were defined before the link. So, if you wanted a ChatGroup called 'clericforhire' that included some of its own patterns, plus the 'cleric' patterns, you would need to create >clericforhire in the file AFTER >healer cleric doctor, and put @cleric at the bottom of >clericforhire. (More tricks with ChatGroups are in the Power Tricks section). Important Note: The files are loaded as part of the startup process - changes made to chat.dat while the MUD is running are not applied until the next startup, or until the UNLOAD command is used against the chat RESOURCES (LIST RESOURCES command) ## Applying MUDChat Behaviors Applying the MUDChat Behavior to MOBs is super easy, and setting the MOB to use a particular ChatGroup is straight-forward as well. ### Grinder Method Edit/Create a MOB as usual. In the Behavior list, put MUDChat. If you leave the options box empty, the MOB will only use patterns in the @default ChatGroup. If you want to specify which ChatGroup, type its name in the options box. So, if you were setting up a cleric, you would put 'cleric' in the options text. ### Create/Modify MOB Method Edit/Create a MOB as usual. In the Behavior list, add MUDChat. It will ask you for any parameters. If you specifiy no parameters, the MOB will only use patterns in the @default ChatGroup. If you want to specify which ChatGroup, type its name in. ## Some MUDChat Power Tricks This is the original email posting about a clever use of the % feature (includes another file in-line): We have a city called Yares. In this city are various mobs - guards, shopkeepers, commoners, bankers, etc.. We setup groups in the chat.dat called guard, shopkeeper, banker, commoner, etc... Gave them each appropriate patterns and responses for their type. Then, we setup two more .DAT files, Yares and World. In Yares, we put a bunch of patterns in relevant to getting around in the city (like 'weapons' or 'inn' - both trigger directions to relevant shops). In World, we put more global geography (IE, 'avalon' gets 'avalon is west of yares'). Now, back in Chat.dat, we created more groups, called YaresGuard, YaresShopkeeper, etc... The only lines that went into each were:
>         %Yares.dat
>         %World.dat
>         @guard (or @banker or @default or whatever)
%filename includes the filename's contents in-line (as if it were typed in) This setup each type to know a little about their city, something about the world, and gave them some text for their profession. So, in our system, if a new player is walking around Yares, they can ask a cityguard where Market Street is or where they can find a healer and get useful answers (well, not if you want to code misinformation for a chuckle)