4 CONFIGURATION OPTIONS

Section 4.1 - Script Option Parameters

The configuration options for the scripts running in the simulator are defined in notecards associated with the scripts. Apart from the database username and apsswords, the configuration options for the teleport.php script held in the web server are contained in the script itself.

Parameters are in the format "OPTION = value" where "OPTION" is the configuration option and is case-insensitive and "value" is the value to which the option will be set.

CAUTION: Some of the configuration information can make your system susceptible to attack by malicious actors and in production systems, any object holding this sort of information should not be readable by the general users.

Section 4.2 - OS Options brigadoon_teleporter.config

The following configuration options are available:

DATABASE_INTERFACE
This parameter sets the address of the php script that controls the database being used to manage the teleporters and would be in the format "DATABASE_INTERFACE = https://www.whatever.com/directory/teleport_script_name.php". In the production version of this script, that address would be placed in the script and the script made unreadable. In this experimental model, it allows for an easy change between different versions of the script.

LOCATION_NAME
This parameter set the name that will be displayed for this teleporter when it is available for selection on other teleporters and has the format"LOCATION_NAME = Brigadoon Landing Location".

LANDING_OFFSET
This parameter sets how far the avatar should land away from the Teleporter device to prevent the avatar from overlapping the teleporter at the destination. If the number is positive, the landing point will be away from the front display of the teleporter. If it is negative will be away from the back of the teleporter. It has the format "LANDING_OFFSET = 3" where the the numeric value is the distance in metres from the teleport's location.

LOCATION_TYPE
Because the number teleporter destinations can become large when using an automatic inclusion system, the location type can be use to limit the number of teleport locations that will be known to a teleporter. There are four types of destination recognised. They can be used separately or inconjunction with each other.

• GROUP If this is the only type stipulated, it will only list other teleporters that are set to GROUP and have the same LOCALITY_GROUP. This can be useful if you are looking for a specific type of teleporter such as a lift of similar, although the more specific teleporter.osl project can interact with lift doors.

• REGION If this is the only type stipulated, it will only be listed on other teleporters in the same region that are also use the "REGION" option.

• WORLD If this option is listed, this will list all teleports in this simulation that use the "WORLD" option.

• METAVERSE This option is onoly useful if there multiple simulations using this teleporter system as it will only list teleporters that are not on this simulator and use the "METAVERSE" option.

The strength and weakness of this option is that the owner of the teleporter decides which groups this teleporter will be included in. Users can taylor where their teleports are displayed, but some egotistical users may want their teleports to show up everywhere, rather than targetting them appropriately. Addressing this is taken to be a management issue, not a technological one.

LOCALITY_GROUP This option is used to identify with which group this teleporter will be associated. Teleporters with the same "LOCALITY_GROUP" will be included when the LOCATION_TYPE includes the "GROUP" flag. NOTE: Any users can agree to have a "LOCALITY_GROUP" that they choose and form private teleport groups.

HEARTBEAT_PERIOD This option sets the time in hours between hearbeat signals being sent to the "teleport.php" script. It should be noted that the script monitoring of heartbeat periods is not affected by this setting. If this value is set too high, the teleporter will be removed between heartbeats if the period exceeds the "LIFE_TIME" define in that process.

Section 4.2 - OS Options teleport_destination_monitor.conf

The following configuration options are available:

• DATABASE_INTERFACE
  This parameter sets the address of the php script that controls the database being used to manage the teleporters and would be in the format "DATABASE_INTERFACE = https://www.whatever.com/directory/teleport_script_name.php". In the production version of this script, that address would be placed in the script and the script made unreadable. In this experimental model, it allows for an easy change between different versions of the script.

• MONITOR INTERVAL
  The MONITOR_INTERVAL is the number of hours between each time the destination datafile is swept to remove teleporter that have not had a heartbeat. Assuming that you simulator runs all the time, and the teleporters have a 1 hour heartbeat, sweeping the database four (4) times a day (that is, every six (6) hours) seems reasonable. Times periods where teleporters are being changed frequently, might benefit from a fast update rate, 0.5 hours (30 minutes).

• LIFE_TIME
  The LIFE_TIME is the length of time in hours since the last heartbeat from a teleporter that indicates that the teleporter is no longer functioning. If the simulator runs continuously, just a few hours would be enough to conclude that a teleporter is no longer functioning. However, if the simulator does not operate continuously, the time between heartbeats will be longer that the time that the simulator is off-line. If the idle time is exceeded, the program will remove that teleporter and hence its destination will be removed from the database storing all of the information about the teleporter and its location. This is not catastrophic because if the teleporter is restarted, it will autoimatrically be re-registered when it is detected. The exception to this rule is for destinations that reside outside of the simulator, because these destinations mostly likely not have a heartbeat. In these instances, the owner of the monitor will just be notified about the external destinations that are not being monitored.

• SCAN_ONLY
  The SCAN_ONLY Flag wg=heb set to TRUE, scans the database and identifies the destinations that have exceeded their LIFE_TIME, but does not delete tjhem from the database. This option is primarily used during development.