special exit program. tells player something, asks a question, and depending on the answer, charge an amount, move the player, notifies the exit owner, logs person/time. Setup.... Set a _confirmer-room: property on the program, containing the dbref of the confirmer room. The confirmer room should have a parent that overrides any globals and builtins that should be unavailable to players in the confirmer room; the overriding actions must be linked to this program and have a *-special-exit-action:overrider property. The exit that triggers the special action should be linked to this program and should have no properties beginning with "*-special-exit". Properties on the trigger exit control the behavior of the program: _premsg-1:, _premsg-2:, ..., _premsg-N: These collectively give a message to tell the player when the exit is triggered, before the player has to respond to the question. These should list the allowable choices. _opremsg-1:, _opremsg-2:, ..., _opremsg-N: These collectively give a message to tell to other players in the room the player is in when the exit is triggered. _choice-1:, _choice-2:, ..., _choice-N: These list the responses the user can make. If none are given, the program behaves as if they were _choice-1:yes;y _choice-2:no;n Note that they may contain alterate names, separated by ;s, just like exit names. If an alternative appears in more than one _choice- property, no error is generated, but which choice that alternative will choose is not specified (beyond saying that it will choose one of the choices it appears in). If all of the choices it appears in are disabled (for lock or cost reasons), the alternative will be disabled; but if some but not all are disabled, it is not specified whether the alternative will be disabled or not. _lock-: This specifies a lock on choice . If the player does not pass the specified lock, the choice is disabled. If the string is not a valid lock expression, the program will crash; there is unfortunately no real way around this, as MUF errors can't be trapped from within MUF. _cost-: The amount to charge the player if choice is chosen. If the player doesn't have enough money, the choice will be disabled. The money, if any, is transferred to the player who owns the triggering exit. _move-: A place to move the player to if choice is chosen. If none is specified for a choice, the default is to return the player to the room the initial trigger action was triggered from. _postmsg--1:, _postmsg--2:, ..., _postmsg--N: These collectively give a message to tell the player if choice is chosen. _osucc--1:, _osucc--2:, ..., _osucc--N: These collectively give a message to tell to other players in the original source room when choice is chosen. _odrop--1:, _odrop--2:, ..., _odrop--N: These collectively give a message to tell to other players in the destination room when choice is chosen. Note that if _move- is not specified or is the same as the source room, this is the same place that the _osucc-- messages will be reported to. _postmsg-force--:, _osucc-force--:, _odrop-force--: These are used instead of the similar properties without the -force-, when choice is chosen because all other choices are disabled for one reason or another. If the -force- properties do not exist, the non-force- properties are used instead. If you want to override the non-force- properties, but want no messages, provide a ...-force--0: property (the value is irrelevant). _fail-:, _ofail-: These messages are sent (_fail- to the player, _ofail- to others in the room) when all available choices are disabled. In this case nothing else happens: the _premsg and _opremsg messages are not sent, the player does not enter the confirmer room, etc. By default no messages are sent in this case. _notify-: If choice is chosen, emit this message to the owner of the trigger action. If no message is specified, nothing is sent. (Note that if the player is not connected, the message will probably be lost.) _log-: =: If choice is chosen, make a log entry. specifies the dbref of the object to hold the log properties. is a prefix string used to set up the log properties as described below. is the message to be put in the log. If the property value does not conform to the syntax (missing = or :, for example), it is as if the property were not present. The log object must be owned by the owner of the trigger action, or else have a _special-exit-log-ok: property (whose value is irrelevant). All messages (_premsg, _osucc, _notify, _log, etc) will have %t replaced with the current time, and will then be pronoun-substituted with the triggering player as the controlling dbref. The program has to be set wizard and owned by a wizard, and probably should be setuid as well. Everything the program sets up on the confirmer room and exits from it should not be touched. The exits are created and relinked on the fly. The program keeps track of state with properties on the player; these properties all begin with "*-special-exit", and they must never be touched by anything else; besides, when the player is not in the confirmer room, the presence of any of them indicates a bug. The log is kept in one property per entry, with the current number of entries kept in another property. Given the string from the _log- property on the trigger exit, the number of log entries is kept in -# and log entry number is kept in -. For example, if the trigger exit has a property _log-3: 1234=somelog:%n chose 3 at %t then property somelog-# on object #1234 contains the number of log entries, and the log entries themselves are somelog-1, somelog-2, etc, on #1234. An example set of log properties generated by the above _log-3 property might be somelog-#: 4 somelog-1: Fred chose 3 at Sat Apr 18 10:11:06 1992 somelog-2: Edward chose 3 at Sat Apr 18 18:00:51 1992 somelog-3: Joe chose 3 at Sun Apr 19 01:52:47 1992 somelog-4: Fred chose 3 at Sun Apr 19 01:52:47 1992 It works correctly for multiple _log- properties to share a given dbref and prefix string. At the moment, there is a very slight danger of losing a log entry due to a race condition if one program is temporarily suspended for being a cycle hog partway through updating the log. If this matters it could probably be fixed.