wmud/old-codebase/doc/OLD-DOCS/socials.doc

91 lines
4.0 KiB
Plaintext
Raw Normal View History

2012-03-03 20:35:30 +00:00
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
HANDLING 'SOCIALS' IN CIRCLEMUD
A general system exists to handle the 'social' commands -- those which
generally have no game-related purpose other than to convey emotions
between players. Socials are also useful for creating advanced DikuMUD
adventures and quests through the use of speical procedures; for example,
you could add a 'detonate' social which, within your quest, is handled by
a special procedure to cause something to explode.
Socials are all handled through the generalized command do_action. The
text file lib/text/socials contains information on the game's socials.
New socials can be added by 1) adding the name and level of the social
to the master command list in interpreter.c (giving do_action as the
function pointer), and 2) adding information for the new social to the
lib/text/socials file.
In Circle 3.0, socials in the file are specified by name (instead of by
command number, as was true of the original Diku and versions of Circle
before 3.0.). In the standard Circle distribution, the socials appear
in alphabetical order in the file, but they can appear in any order and
can be rearranged if necessary.
The file is formatted as follows:
--------------------------------------------
<command name> <hide-flag> <minimum position of victim>
<messg to character if no argument>
<messg to others if no argument>
<messg to char if victim found> <---If this field is empty,
<messg to others if victim found> <-
<messg to victim> | then these fields must be
<messg to char if victim not found> | skipped, and the action will
<messg to char if vict is char> | ignore arguments.
<messg to others if vict is char> <-
<command name> <hide-flag> <minimum position of victim>
.
.
.
.
.
$~
-------------------------------------------------
Each social must contain either 1) only the first two messages (if the social
ignores arguments), or 2) all eight messages (if the social takes an argument).
Each message must be contained in one line.
The command-name indicates which social is being specified. The hide-flag
can be either 0 or 1; if 1, the social is hidden from OTHERS if they cannot
see the character performing the social. The action is not hidden from the
VICTIM, even if s/he cannot see the character performing the social, although
in such cases the character's name will, of course, be replaced with "someone".
Where it makes sense to do so, text fields may be left empty. This is done by
putting a '#' in the first column on the line. Doing so is legal in the
following fields:
a: messg to others if no arg
b: messg to others if victim found
c: messg to others if vict is char
Note again that if the field _messg to char if victim found_ is empty, then
the following fields must be omitted entirely (not even the '~'), and the
action will ignore any arguments supplied.
The procedure sends the text strings through act(), and they may contain
control codes (see the documentation for the act() function for details.)
Note that not all of act()'s control codes may be used; for example, codes
which refer to objects such as $p.
For the sake of efficiency, no tests or sanity checks are made on the
consistency or logic of the act() codes found in the social messages.
Hence, grave disorder may result if, say, the code '$N' occurs in a text
field that doesn't refer to a victim; like _messg to others if no arg_.
In previous versions of Circle, such grave disorder often manifested itself
in the form of crashes. However, the act() function itself in Circle 3.0
and above does sanity checks to make sure it's not dereferencing null
pointers, hopefully with the result of avoiding crashes. Nevertheless,
great care should be taken in making sure that the $ codes of socials are
used consistently and correctly.