Soc File - torilmud/docs GitHub Wiki

Soc File

The *.soc file, or the social file, contains all the mob behaviors in your zone, from zone echoes, to paths and even response triggers.

Overview

Reply Triggers:

Reply Triggers are used to define an action, or list of actions, for a mob to perform, triggered by another action from either a player or another mob. These can be used for a variety of uses, and are very flexible.

Timed Actions:

Timed Actions are similar to Reply Triggers, except they use a specified mud-hour as the triggering event, as opposed to an inputted command. For example, these could be used to unlock city gates at a specified time, etc.

Periodic Actions:

Probably the most common of all area socials are the Periodic Actions, or actions taken at a regular user-defined interval. These are used most commonly for small things, like mobs that talk about cryptic things every few minutes, hookers pulling up their stockings every now and then, etc. Adding a good number of these little periodic actions can bring your mobs to life, giving them more personality than the average, silent-as-a-rock mobs.

Periodic Action Lists:

Periodic Action Lists are almost the same as above, except instead of defining one action, or set of actions, you can specify a list of possible actions for the mob to take when the social is called, and the code will choose one of the actions you specified. This is especially useful for zone echoes, and mobs with lots of personality. One would use periodic action lists to make mobs like the town fool, the town crier, or those especially talkative mobs in Ice Crag.

Paths:

Paths consist of a variety of methods in which to reliably move a mob along a series of rooms. Patrols are the most common use, but they can also be used within trigger sets for some interesting behavior. They are quite flexible and as reliable as is possible to make them.

Reply Triggers

The Trigger Command: the action that triggers the mob.
The Response Command: the action the mob performs when triggered.

Format:
MOB: vnum TRIGGER
FLAG: Flag Value
CHANCE: Chance
DELAY: Delay
TRIGGER: Cmd #
ACTION: Cmd #
Arguments/Parameters
~
DONE

Example:

;; Mob Consents when pcs bow at it
MOB: 57031 TRIGGER
FLAG: 36 ;; directed, use initiator
CHANCE: 0
DELAY: 0
TRIGGER: 98 ;; bow
ACTION: 232 ;; consent
~
DONE

Example:

;; Mob switches to whoever casts at it
MOB: 96807 TRIGGER ;; a magedoom
FLAG: 6 ;; combat only + use_initiator
CHANCE: 0 ;; 100%
DELAY: 0 ;; right away
TRIGGER: 26 ;; cast
ACTION: 70 ;; hit
~
DONE

Now we get a little fancier - in this next example of a multi-response trigger, the old drunk first rubs his belly, then he burps at the initiator, then says "That's some good ale!" 25% of the time, complete with ANSI colors.

Note the delays - it's important to set subsequent actions at a higher delay, otherwise they'll all go off at the same time. The delay in the subsequent commands is based from the moment the mob was triggered, NOT the time since the last command. In this case, the mob performs the chained commands two seconds apart. Also note that the TRIGGER field is left off of the chained commands - it only belongs on the first one. Also, DONE is not stated until the end of the whole chain. The "\n" at the end of the room echo signifies a line break...see Section 6 for details about those special commands.

Example:

MOB: 91404 TRIGGER
FLAG: 33 ;; NOT_IN_COMBAT + DIRECTED
CHANCE: 0 ;; 100% Chance
DELAY: 8 ;; Delay of 2 seconds (8 ticks)
TRIGGER: 94 ;; Poke
ACTION: 1003 ;; Room Echo
&cgThe drunk rubs his belly.&N\n
~
FLAG: 37 ;; NOT_IN_COMBAT + DIRECTED + USE_INITIATOR
CHANCE: 0 ;; 100% Chance
DELAY: 16 ;; Delay of 4 seconds (16 ticks)
ACTION: 106 ;; Burp
~
FLAG: 33 ;; NOT_IN_COMBAT + DIRECTED
CHANCE: 3 ;; 25% Chance
DELAY: 24 ;; Delay of 6 seconds (24 ticks)
ACTION: 17 ;; Say
&cGThat's some good ale!&N
~
DONE

Timed Actions

Timed Actions are setup identically to reply triggers, with one important distinction - instead of the TRIGGER: field, you use the HOUR: field to specify the mud hour at which the socials are triggered.

Format:
MOB: vnum TIMED
FLAG: Flag Value
CHANCE: Chance
DELAY: Delay
HOUR: Hour # (0-23)
ACTION: Cmd #
Arguments/Parameters
~
DONE

Example:

;;at 11am, the mobile will announce the time.
MOB: 91394 TIMED
FLAG: 0 ;; no flags
CHANCE: 0 ;; 100%
DELAY: 0 ;; 0s
HOUR: 11 ;; 11am
ACTION: 17 ;; say
It is now 11 am!
~
DONE

Example: Chained Timed Command

At 5pm, the mobile will announce the commencement of his patrol, and then start on it.

MOB: 91394 TIMED
FLAG: 0 ;; no flag
CHANCE: 0 ;; 100%
DELAY: 0 ;; 0s
HOUR: 17 ;; 5pm
ACTION: 17 ;; say
Time to start my patrol of the Street of Wonders!
~
FLAG: 0 ;; no flag
CHANCE: 0 ;; 100%
DELAY: 20 ;; 5s
ACTION: 1004 ;; path init
1
~
DONE

Periodic Actions

Format:
MOB: vnum PERIODIC
FLAG: Flag Value
CHANCE: Chance
DELAY: Delay
ACTION: Cmd #
Arguments/Parameters
~
DONE

Example:

;;This example shows a child, who cries to herself 
;;approximately once every 30 seconds, while not 
;;in combat.
MOB: 91404 PERIODIC
FLAG: 9 ;; NOT_IN_COMBAT + USE_SELF
CHANCE: 2 ;; 33% Chance, or approx. once/30s
DELAY: 4 ;; Delay of 1 second (4 ticks)
ACTION: 53 ;; cry
~
DONE

This next example is of a multiple command periodic action. Same child, except this time, she picks her nose, smiles, then says "yummy".

Note the delays - it's important to set subsequent actions at a higher delay, otherwise they'll all go off at the same time. The delay in the subsequent commands is based from the moment the whole chain started, NOT the time since the last command. In this example, there's a half a second delay between each subsequent command. Also, the chance field is ignored for subsequent commands, as they are all dependent on the first action in the chain. In other words, if the first action goes off, so will all the other commands chained to it.

Example:

MOB: 91100 PERIODIC
FLAG: 9 ;; NOT_IN_COMBAT + USE_SELF
CHANCE: 2 ;; 33% Chance, or approx. once/30s
DELAY: 4 ;; Delay of 1 second (4 ticks)
ACTION: 337 ;; Nose
~
FLAG: 1 ;; NOT_IN_COMBAT
CHANCE: 0 ;; N/A
DELAY: 6 ;; Delay of 1.5 seconds (6 ticks)
ACTION: 23 ;; Smile
~
FLAG: 1 ;; NOT_IN_COMBAT
CHANCE: 0 ;; N/A
DELAY: 8 ;; Delay of 2 seconds (8 ticks)
ACTION: 17 ;; Say
Yummy!
~
DONE

Periodic Action Lists

Periodic lists are just like periodic actions, except you can define multiple actions and have the code pick randomly which one to execute. One would use this for a mob that does a lot of different things, and for zone echoes.

Format:
MOB: vnum LIST
FLAG: Flag Value
CHANCE: Chance
DELAY: Delay
ACTION: Cmd #
Arguments/Parameters
~
DONE
FLAG: Flag Value
CHANCE: Chance
DELAY: Delay
ACTION: Cmd #
Arguments/Parameters
~
DONE

Here's an example of a mob that does 1 of 3 things every 30 seconds. We'll use a wandering jester as an example, every 10 seconds, the list proc is called, at which point it rolls a random number and chooses ONE of the 3 actions. Then, the action has a 33% chance to be performed. Basically, approximately once every 30 seconds, ONE of these commands gets performed.

Example:

MOB: 91104 LIST
FLAG: 9 ;; NOT_IN_COMBAT + USE_SELF
CHANCE: 2 ;; 33% Chance, or approx. once/30s
DELAY: 0 ;; No Delay
ACTION: 264 ;; Jump
~
DONE
FLAG: 1 ;; NOT_IN_COMBAT
CHANCE: 2 ;; 33% Chance, or approx. once/30s
DELAY: 0 ;; No Delay
ACTION: 112 ;; Flip
~
DONE
FLAG: 1 ;; NOT_IN_COMBAT
CHANCE: 2 ;; 33% Chance, or approx. once/30s
DELAY: 0 ;; No Delay
ACTION: 289 ;; Twirl
~
LISTDONE

Paths

Unlike the other social types listed above, Paths use a nonstandard nomenclature and setup, so read this section carefully.

There are two ways to use Paths:

To create a patrol route for a particular mob vnum, that automatically activates itself and continues until the mob dies.
As an action in response to a trigger or periodic action using the Path Initiator Command

Format:
MOB: vnum PATH
ID: Path ID for this MOB
TYPE: Path TYPE for this MOB
ROOMS: Path ROOMS for this MOB
DIRS: Path DIRECTIONS for this MOB
DONE

Path Initiator Command

This is the special command used to activate a path from within a trigger or periodic action. It's cmd# is 1004. Specify this as the action, as well as the ID# of the path to be activated in the arguments field.

Example:

;;This is an example of a standard round-trip 
;;patrol path. This mob will patrol the set of rooms 
;;listed within automatically when it is loaded.
MOB: 91104 PATH
ID: 0 ;; Auto Path
TYPE: 2 ;; Roundtrip Path
DELAY: 10 ;; Move every 10 seconds
ROOMS: 91100 91101 91102 91103 91104 91105
DIRS: 2 2 2 2 1
DONE

Example:

;;This is an example of a one-way path that is 
;;intended for use with a trigger or periodic. When 
;;activated, the mob will move from to the last 
;;room in the path (91105) and stop.
MOB: 91105 PATH
ID: 1 ;; ID #1
TYPE: 1 ;; One-way Path
DELAY: 5 ;; Move every 5 seconds
ROOMS: 91100 91101 91102 91103 91104 91105
DIRS: 2 2 2 2 1
DONE

Finally, here is an example of calling a path from a trigger. In this instance, we will call the defined PATH by triggering on the 'salute' command. After the path is complete, we will follow it up by having the mob take a bow. For more information on triggers, see the appropriate section of this documentation.

Example:

MOB: 91105 PATH
ID: 1 ;; ID #1
TYPE: 1 ;; One-way Path
DELAY: 5 ;; Move every 5 seconds
ROOMS: 91100 91101 91102 91103 91104 91105
DIRS: 2 2 2 2 1
DONE
;;
MOB: 91105 TRIGGER
FLAG: 32 ;; DIRECTED
CHANCE: 0 ;; 100%
DELAY: 40 ;; 10 seconds
TRIGGER: 185 ;; salute
ACTION: 1004 ;; PATH
1
~
FLAG: 0 ;; None
CHANCE: 0 ;; 100%
DELAY: 60 ;; 10 seconds (after path)
ACTION: 389 ;; bow
~
DONE

In the above example, first we defined a path, with an ID of 1. Because the path has a non-zero ID, it will not activate until triggered. In the trigger command, we activate the path by using the special path initiator command (#1004), and put the ID# we want to activate for that MOB in the arguments. After the path is complete, the final bow command will be processed. Note that it does not matter where you specify the PATH to be called - it does not have to be right above the trigger that uses it. Also, remember that the ID you call relates to the MOB with the trigger only - if the trigger mob does not have a path defined for it, nothing will happen.

Path Notes & Tips

You can have as many paths per mob as you desire, at least in theory, in reality we have a max number of paths defined, so make all the paths you need to make, but don't go overboard giving every single mob in your zone a path.
The path definitions can go anywhere within the social file, the order is not important. I would suggest putting all of your paths in one place within the file, to make it easier to view. Ex: at the bottom.
The mob must be loaded somewhere within the path for it to work. Also, it does NOT need to be loaded in the first room of the path - you can load mobs anywhere on the path and they will automatically move along it in the correct order. This is useful for staggering patrolling mobs in an area. This does not apply to SEEK paths however - those will activate regardless of location.
You do not need to flag pathing mobs as SENTINEL, though it is recommended, just to be safe.
Path mobs are extremely resourceful. If they come into combat along their path, they will stop, and then resume the path where they left off when the combat is over. If the mob gets lost - from tracking a player, for instance - it will return to it's last place on the path and continue along it. If for some reason the mob can't get back, it will keep trying several times before eventually giving up. A path mob should only give up on it's path if it becomes isolated from it and cannot get back, or dies.
Path mobs will open doors along their way, and close them behind them. They will also unlock and re-lock doors for which they have the proper key.
Use the SEEK paths wisely - they are very efficient, but difficult to control. These should be used only when you quickly need to move a mob from one room to the other (to call for help, flee to safety, etc.).

Zone Echoes

Zone echoes are done primarily with Periodic Lists (although you can also use timed actions and even reply triggers in certain cases). Basically, you define as many different echoes as you want in one periodic list, then let the proc randomly pick which one to display.

Of course, we need a mob to attach the list to. Ideally, make a special sentinel mob, and stick it in a distro room where players can't get to it. Call it something like "the echo machine" so other gods can tell what it is.

There are four special command numbers used for zone echoes:

Cmd#	Description
1000	Echo in every room flagged INSIDE in the zone (Room Flag INDOORS. Sector indoors does not count)
1001	Echo in every room flagged OUTSIDE in the zone (Room Flag INDOORS. Sector indoors does not count)
1002	Echo in every room in the zone
1003	Echo in the ROOM the mob is in
1005	Echo to a specific TARGETED room only (put vnum of room at start of echo string, e.g. "3001 The wind goes whoosh")

Use one of these as the command number, and define the echo in the arguments field. ANSI color is allowed (and encouraged) in zone echoes. End the echo with "\n", which signifies a line break. Without it, the lines get all crunched together, it's not a pretty sight.

Note: Placing an item with the name "noecho" in a room will suppress all generalized echoes sent to the zone, although targeted echoes will still be heard. Item #873 has been created as a noshow echo suppressor, and feel free to use it with a high maxload (e.g. 999) so as not to mess up anyone else's load.

Here's a sampling of the Baldur's Gate zone echoes. I only included three of them for brevity's sake, but keep in mind that the number of echoes in a list is unlimited.

Example:

MOB: 91401 LIST
FLAG: 0 ;; NONE
CHANCE: 2 ;; 33% Chance, or approx. once/30s
DELAY: 0 ;; No Delay
ACTION: 1001 ;; Zone Echo-Outside
&+cA loud horn blows shrilly from somewhere in the harbor.&N\n
~
DONE
FLAG: 0 ;; NONE
CHANCE: 2 ;; 33% Chance, or approx. once/30s
DELAY: 0 ;; No Delay
ACTION: 1001 ;; Zone Echo-Outside
&+LSomeone raises a &N&+rbloodcurdling&N&+L scream from a nearby building.
&N\n
~
DONE
FLAG: 0 ;; NONE
CHANCE: 2 ;; 33% Chance, or approx. once/30s
DELAY: 0 ;; No Delay
ACTION: 1001 ;; Zone Echo-Outside
The loud shouts of peddlers hawking their wares can be heard coming from &+BThe Wide&N.\n
~
LISTDONE

Once every thirty seconds, one of these echoes will be sent to all the outside rooms in Baldur's Gate.

Notes

Tempting as it is, please do NOT make a lot of mobs that cast high level quest spells (i.e. Doom, swarm, etc.). Most of these spells can wipe out a PC group with just one or two castings, so please limit these spells to VERY difficult mobs in high level zones. Also, set a low chance, or high delay, for these castings, so the mob doesn't cast it 10 times in a minute or something.
Try to limit your use of triggers, as in, don't put a trigger on a mob that loads 40 times in high traffic areas. This is because the proc works by evaluating EACH and EVERY action performed in the room, to determine if it's the trigger command. Excessive use like this can slow the mud down, so use your triggers wisely. Try and limit triggers to unique mobs in low-traffic areas.
Please don't go overboard with your periodic actions and zone echoes. Put a low chance, or a long delay between them to space them out. The objective of these is to add atmosphere to your zone, NOT to spam the player off the screen.
The .Soc file has a tremendous amount of possibilities! Don't be afraid to experiment and try to do new things with it. For example, I've made a mob that runs and fetches help when it's attacked, another mob that plane shifts, then relocates to a player that attacks it, etc. Use your imagination!
Always try to keep your socials organized, first by mob vnum, then sort them in order, for example: LIST, PATH, PERIODIC, TIMED, TRIGGER. Further organize your triggers in order by the smaller number in the flags field, otherwise you might run into hard to detect triggers that do not work due to their being out of order.