Section 3.1 - Software Description

The software for this project is divided into scripts written using the Open Simulator variant of the Linden Scripting Language (LSL) and a script written in php which runs under the web server associated with the simulation.

The simulator scripts deal with the interface to the user in the simulator. This includes providing the menu for the selection of simulator destinations, providing inforamtion about the state of the teleporters liked to this system; and sending heartbeat signals to the php program.

Section 3.2 - SQL Teleporter Database Tables

The information about the teleporter desitinations and authorisation information is held in a couple of database tables using MariaDB. The MariaDB database is controlled by the teleport.php PHP script running on the web server.

There are three (3) SQL tables associated with the teleporter project. The first table is the UserAccounts table in the opensim database used by the simulator. This table is used to determine if the owner of the teleporter attempting to communicate with the teleporter software has an account on the simulation running the teleporter software.

If a wider range of access is desired, the ls_os_teleport_allowed table in the ls_os_support database can be used to check the heartbeat is coming from a teleporter in a known simulator and owned by a know person.

The ls_os_teleport table is used to store information about each teleporter that communications with this system. The software allows the landong site for ethe teleporter to be automatically offset from the teleporter object. If the teleporter is moved or reorientated, the landing spot automatically moves to match.

Section 3.3 - OS Script brigadoon_teleporter.osl

The Open Simulator (OS) script brigadoon_teleporter.osl is used to read information from a notecard that contains alist of the destinations that this teleportr can use. This is essentially very similar to many versions of a stansard notecard based teleporter. The difference is in this case, the notecard is preiodically generated by the teleporter_heartbeat.osl script using information from the ls_os_teleport table based on the teleporter's configuration.

Section 3.4 - OS Script teleporter_heartbeat.osl

The teleporter_heartbeat.osl script provides a variety of functions. THe first of which is to send a heartbeat message to the teleport.php script which will either update inforamtion about this teleporter, or insert a new teleporter. The hearbeat signal will trigger the teleport.php script to slect a set of destinations for this teleport and send it to them. The <teleporter_heartbeat.osl script delete the old teleport_destinations.config file and replace it with a new one holding hte current selection of destinations for this transporter.

Section 3.5 - PHP Script teleport.php

The teleport.php script accepts a heartbeat message from a teleporter and if it is from a known teleporter, it will update its informattion in the ls_os_teleport table. If it is a new teleporter and it is owned by a user known to program either by finding an entry in the UserAccounts table or in the ls_os_teleport_allowed table. It should be noted that to use th UserAccounts table the teleport.php script must have read access to that table in the opemsim database.

If the script cannot access the UserAccounts table, this check can be disabled by setting the $use_sim_db variable in the script to "FALSE". In that case, the only access check will be the check of the ls_os_teleport_allowed table to confirm that the teleport's owner and simulator world match an entry in the table. This restrictiomn requires that this table is maintained to add or remove users who are allowed to make their own instances of the teleporter.

The teleport.php script can also scan the list of teleports and check that heartbeat messages are still being received from each teleporter. Depending on what was requested, the script will either just identify that it does not appear to be working, or it can automatically delete the telporter entry from the table. In either case, the script will send a response back to the teleport_destination_monitor.osl script identifying the teleporters that were deleted or simply identified as possibly dead.

NOTE: In a production system, the name of this script should be altered to a name that is not easily guessed and the configuration and scripts in the teleports should be made unreadable to the general public, for increased security. In the experimental system, these changes are not implemented as there are regular backups. The database passwords for the script are kept in a directory that is not accessible to the general public.

Section 3.6 - OS Script teleport_destination_monitor.osl

Because the system is designed to allow approved users to create teleports that are automatically incorporated into the database tables, there must also be a way to automatically ensure that database does not get clogged up with teleporter entries that are no longer valid. To ensure that this does not happen, the teleport_destination_monitor runs periodically to sweep the ls_os_teleport tables for defective or removed teleporters. This is done by requesting the requesting that the teleport.php script checks "teleport_heartbeat" field in the table to see if it is out of date.

The request can either select just to scan and identify possibly dead teleporters, or to automatically delete those teleporters. It is not a big deal if a dead teleporter is removed just before it is restarted as it will automatically generate a new entry when the teleport.php script receives the first heartbeat message from the telporter.