Configuration

The configuration of TinyMUX involves modifying one or more configuration parameters. The parameter set includes a diverse, substantial number of options. As many new wizards can attest, the array of configuration parameters seems vast and the help listed with each is limited. Various groups of related parameters are discussed below but some defy categorization so the miscellanous section will contain those not found elsewhere.

Applying Configuration Changes

MUX provides two mechanisms for modifying the configuration options available: permanent file based configuration and run-time, temporary configuration. The former requires access to the host machine to modify the netmux.conf or GAMENAME.conf file. The latter utilizes the @admin command. In most cases, #1 is the only person who can modify configuration options via @admin but exceptions do exist.

Modifying the configuration file will result in permanent changes to the configuration of the game but does not take effect until the game is restarted. On the other hand, @admin will make the change immediately but will only last until the game is restarted. These differences are very important and will lessen confusion later. If you intend to make a permanent change and want it to take effect immediately, you must either modify the configuration file AND restart the game (via @restart or @shutdown and then Startmux) or you must modify the configuration file AND apply the change with the @admin command.

Syntax of the two differ in a significant way. Within the configuration file, options are used without using an = after the option. @admin, however, requires you use the = to seperate the configuration option from the change. For example, consider changing the name of money.

At runtime, the change might be:

@admin money_name_singular=Coin

@admin money_name_plural=Coins

In the configuration file, the change is:

money_name_singular Coin

money_name_plural Coins

Again, be sure to note the difference. Mixing it up will result in @admin not finding the proper configuration directive or the server issuing various complaints into the log file.

Configuration Subsections ToDo

• Attributes, Access and Aliases
  • Explains the mechanisms for modifying the default permissions for functions, commands and attributes.

• File Control
  • Details the various file configuration parameters within TinyMUSH / MUX as well as the usage for each file.

• Limits
  • An alpha list of limitations configurable by game administrators.

• Site Control
  • Covers the use of the site control configuration parameters to control registration, site blocking and other features.

Default Object Flags

Default flags are applied on an object type basis when the object is created. When an object is created, the game automatically appends the flags listed for that object. The current configuration is available through the use of '@list default_flags'.

The configuration parameters available for default flag implementation are exit_flags, player_flags, robot_flags, room_flags, and thing_flags. Any flag within the game may be applied to any type. However, not all flags are appropriate for specific types.

As an example, suppose the administrators decide that all players when initially created should be set with the ansi flag and also be set uninspected until they have been approved. This can be accomplished by adding the following line to the configuration file:

player_flags ansi uninspected

Furthermore, the game is mostly an outdoor setting and the admins have decided nearly all exits should be set transparent so players can see from one room into the next. They decide during the building process to add the transparent flag by default to exits. Once building is completed, they will remove the option.

exit_flags transparent

Similar entries could be made to thing_flags and robot_flags to setup defaults for those object types.

Log File Configuration

The MUX server writes a continual stream of information to a log file which game administrators can use for a variety of purposes. The control of the information placed into the log file is controlled by the configuration parameters log_options and log.

The log_options directive dictates what information is to be included with each line written in the log file no matter what type of log entry is being written. There are four possible parameters to the log_options directive:

* flags: includes flags for players/objects/rooms listed

* location: includes location information for players, objects and rooms when noted in the logfile.

* owner: includes the owner of the player, object or room being noted.

* timestamp: prefixes each log entry with a timestamp.

Admins may turn these options on or off via @admin or an entry in the configuration file. To turn an entry off, prefix the name with an exclamation point (e.g. !flags). A few configuration file examples:

log_options flags location owner timestamp

log_options !flags location !owner timestamp

log_options !flags !location !owner timestamp

The first turns all the options on, the second only includes location and timestamp information and the last only does timestamps for each entry.

Game admins may also modify what information is logged as an event. These options are controlled by the log configuration parameter which has 17 options that can be turned on or off. The options, quoted from the wizhelp file, are listed below.

accounting	Write an accounting record to the log for each player who disconnects.
all_commands	Record all commands executed.
bad_commands	Record commands entered that did not match anything.
buffer_alloc	Record buffer allocates and frees.
bugs	Record internal inconsistencies found.
checkpoints	Record automatic database dumps.
config_changes	Record uses of the @admin command.
create	Record creation of new players.
killing	Record use of the kill and slay commands
logins	Record connects to characters.
network	Record new and broken net connections.
problems	Record problems found with the database.
security	Record security-related events.
shouts	Record uses of the @wall command.
startup	Record information about game startup.
suspect	Record commands entered by SUSPECT players.
wizard	Record uses of dangerous commands like @toad.

These options are controlled in the same manner as the log_options parameter above. Choosing which ones you want enabled depends on the detail you desire to be placed in the logfile. Remember the more options you enable, the larger your logfile becomes especially if you do not reboot frequently. A popular game logging every command will have a massive logfile in a very short amount of time. It is best to enable only the information you need frequently and turn on other options on as needed.

A couple of examples:

log accounting !all_commands !bad_commands bugs killing security !shouts

log !all_commands buffer_alloc checkpoints

The entire list of options to be enabled and/or disable should appear within the configuration file. I typically make it a single line though it need not be. However, if a parameter is listed on multiple lines, the last occurance will be the one put in effect.

Finally, you can see which options are currently being logged and the information being provided with each entry by using @list logging. Note: @list logging is available only for #1 by default. For each event it will indicate if logging is enable or disable. The final line of the output lists the parameters for log_options.

Money Configuration

This section covers the configuration options related to money and costs. The configuration parameters discussed below include:

create_max_cost, create_min_cost, clone_copies_cost, dig_cost, earn_limit, find_money_chance, kill_guarantee_cost, kill_max_cost, kill_min_cost, link_cost, machine_command_cost, money_name_singular, money_name_plural, open_cost, page_cost, paycheck, robot_cost, search_cost, starting_money, and wait_cost

Common Money Configuration

Most game administrators are primarly concerned about what the money is called within their game, how much money each player starts with, how much they earn each day they connect, and the maximum amount of money that player can have.

To name money, the money_name_singular and money_name_plural configuration parameters are used. Consider a modern day game set in the United States, the administrator chooses to use the U.S. Dollar as the baseline. To do so, she inserts the following options into the game configuration file:

money_name_singular dollar

money_name_plural dollars

Next, the adminstrator decides to give each person 5000 dollars when the character is created. To do so, the starting_money parameter is applied.

starting_money 5000

It is also decided that each character will receive a stipend of 250 dollars each day they are connected with a maximum amount of money of 100000. These changes are applied with the paycheck and earn_limit options, respectively.

paycheck 250

earn_limit 100000

Finally, the administrator decides that no money will be randomly found as the character moves about the game. To be consistent, the administrator decides to append the option into the configuration file even though the default of 0 is being used. If a value of greater than zero had been used, a 1/X chance of finding money would be used each time a player entered a new room. E.g., if find_money_chance were set to 2, there would be a 50% chance of finding cash each time a new room was entered.

find_money_chance 0

Building Cost Configuration

Prior to the introduction of quotas and powers, building activity on games was controlled through the use money. Each activity was assigned a cost, which limited how much a player could add onto the game. Games rarely choose to employ cost based building limits but it is still possible using the following options:

dig_cost, open_cost, create_min_cost, create_max_cost, link_cost, clone_copies_cost, robot_cost

For dig_cost, open_cost, link_cost, and robot_cost, the number supplied is charged to the person utilizing the @dig, @open, @link or @robot command. The cost is deducted from current money total of the player if the command can be completed successfully.

Objects (things) created via the @create command can actually have a range of cost rather than a single set value. The value specified during the @create commmand or the minimum value if not specified, is charged to the creator. This specified cost is then stored on thing until it is refunded when the object is destroyed. The parameters create_min_cost and create_max_cost set the range of values a thing can have. Additionally, create_min_cost sets the default cost of @create command.

Finally, the clone_copies_cost parameter is a yes/no option. This parameter, when set to yes will charge to enactor of the @clone command the cost associated with the original object. If set to no, the cost of the cloned object is the default value of @create, which is the create_min_cost value.

For our example game, clones will cost as much as the original object so clone_copies_cost will be enabled. All other costs will be left at the default values so no entries will be placed in the configuration file.

clone_copies_cost yes

Other Costs

The final money/cost parameters apply to command based costs. The final parameters are:

machine_commmand_cost, search_cost, wait_cost, page_cost, kill_guarantee_cost, kill_min_cost, and kill_max_cost.

The search and page cost parameters set the amount charged to use the @search and page commands, respectively. Since @searching can be expensive, the default value of 100 will be left in place while our game will not charge to use the page command.

search_cost 100

page_cost 0

The wait_cost value is charged when a command is placed on the queue for delayed execution. The cost is refunded to the player when the command is executed or the command is removed from the queue due to being halted.

The machine_command_cost is the 1 in X chance of a command costing 1 money unit each time a command is run from a machine rather than interactively. This value is rarely modified from the default value of 64.

The final cost parameters are all related to the kill command. On most games, the kill is restricted via the access configuration option. However, if killing is allowed, one can set kill_min_cost to the minimum amount of money required to attempt to kill someone. Likewise, the kill_max_cost sets the maximum cost that can be used during the kill command. If kill_max_cost is set to a value less than kill_guarantee cost, automatic kills will be disabled and every attempt will have a chance of failing. Finally, kill_guarantee_cost sets the amount of money required to ensure that the kill command succeeds.

For example purposes, the following options to can be applied to make killing expensive and disable automatic kills. In this example, players must spend a minimum of 2500 to use the kill command and can apply up to 10000. Kills are guaranteed at 15000 units, well above the max level, so every kill attempt has a chance of failure.

kill_min_cost 2500

kill_max_cost 10000

kill_guarantee_cost 15000

Player Name Control

Administrators can control the name choices of players by modifying the player_name_spaces, bad_name and good_name configuration options. This allows admins to restrict name choices to those fitting their game or to restrict certain names.

The first option, player_name_spaces, specifies whether or not player names are permitted to contain spaces. By default, names with spaces are allowed. If no spaces are desired, administrators can set the option to no.

player_name_spaces no

The bad_name and good_name options are used to restrict name choices. The bad_name option accepts wild cards and multiple entries within a configuration file are accepted. Attempts to create a player with a disallowed name (or to rename to a disallowed name) will be rejected. Normally, words that lead off messages from MUX are disallowed, some sites may wish to disallow some obscene names as well. Some examples:

bad_name Fuc*

bad_name Gandalf

bad_name Frodo

The opposite of bad_name, good_name will allow a specific name. It does not perform wild-card matching. Typically, good_name is used with the @admin command to allow a previously forbidden name. For example, at some point the administration decides to allow a character to play a guy named Frodo. Using the following line would let the name be used.

@admin good_name=Frodo

Options of 'good_name' are useful when a bad_name wildcard matches a name that is allowable. The good_name entry should be inserted in the configuraiton after the bad_name entry that it overrides.

Quota Configuration

Quota configuration is a mechanism for limiting the amount of objects a player can own. Quotas can be applied with or without associated command cost (See Money Configuration). By default, quota control is disabled. To enable quotas, add an entry to the configuration file.

quotas yes

If quotas are enabled, the administrator can then adjust the starting amount of quota each player receives and determine how much quota each type of object costs. Setting the initial quota is applied by the option starting_quota. Individual quota costs can then be applied using room_quota, exit_quota, player_quota, and thing_quota.

For example purposes, our game will set the starting quota of all players to 50. Rooms, exits, and things will each cost 1 quota when created. Robots (players) will have a cost of 25. The following entries in the configuration file will apply this change:

starting_quota 50

room_quota 1

exit_quota 1

thing_quota 1

player_quota 25

The configuration options will affect all players created after the configuration options are inserted in the config file and the game has been restarted. Players who existed prior to the modifications may need to have quotas adjusted manually. The game administrators can utilize the @quota command to make adjustments as needed. @quota can also be used to adjust quotas on individual players above or below the default setting.

Quotas can aid administrators in restricting the size of the database and controlling how many objects individual players can own. Administrators can also utilize specific powers such as free_quota on builder characters to avoid quota limits on a case by case basis.

TinyMUSH also provides typed_quotas which can constrain the quota available on individual object types in addition to a general total object limit.

Timers & Periodic Processes

Timers and periodic processes cover two broad issues: timeouts and periodic processes such as database dumps and consistency checking that occur on a periodic basis.

Timeouts are handled by two configuration parameters: conn_timeout and idle_timeout. The first, conn_timeout defines how many seconds a network connection remains open without being logged into a character. This defaults to 60 seconds but is often increased for sites experiencing delays (lag). The second, idle_timeout, controls how long characters can be idle before being automatically disconnected from the game. Both parameters except an integer value specifying a number of seconds for the timeout limit.

For illustration, the following lines in a configuration file will allow a connection timeout to be set at 3 minutes (180 seconds) and the idle timeout to be 4 hours (14400 seconds).

conn_timeout 180

idle_timeout 14400

Periodic processes occur on fixed intervals while the game is operational. These processess including the writing of the game data base (dumps), database consistency checking, and checks for idle players. The configuration options used to control these processes are dump_interval, check_interval, and idle_interval. The time between when the server starts and the first occurance of the consistency check can be set with check_offset. Similarly, dump_offset can modify the first occurence of the database dump.

For illustration, assume a game is just being created and a lot of changes are occuring. The administrator decides to increase the frequency of database writes and consistency checks. He decides dumps should occur every 30 minutes and database checks every 5 minutes. The following configuration file lines make that change:

dump_interval 1800

check_interval 300

The idle_interval, dump_offset, and check_offset values are left at the default values.

The @timewarp command can be used to adjust timers interactively if single instance changes are desired.

Related Topics: config parameters, @admin, @list, Security mechanisms