Introduction
The scoreboard is a multi-purpose object or prim designed to display text on a prim surface using OpenSim's texture-drawing capabilities. The text to display is sent to a script inside the prim by means of llMessageObject() commands. A script sending data in this way is referred to here as a client script.
There may be several scoreboards in a build. These can either be duplicates (in which case they display the same information) or separate (each displaying text for a different client script). If separate, they can be displaying information for different instances of the same script, or completely different client scripts. Any or all of these may be mixed. Separation is achieved by the use of "channels".
Construction
It may be a prim linked into another object, or it might be a standalone object in its own right. The scoreboard script resides in a cube prim which has at least one face visible. The visible face should be precisely square in shape so as not to distort the text. Other prim(s) may be used to conceal the non-square sides of the cube for aesthetic reasons, since the script necessarily writes text an all sides of the prim.
Channels
The scoreboard needs to be in the same region as the sending script. In order that several scoreboards may coexist in a region, there is a concept of channels; a scoreboard listens to one channel only (see the Configuration section), and the associated script should send data on that channel (see the Communication section). This pairing prevents crosstalk between different scoreboards.
It is even possible for different instances of the same object to communicate with different scoreboard instances by setting their channels accordingly.
Channels are named by a case-sensitive string.
Configuration
The scripted prim should contain a configuration notecard called "Scoreboard config". This is an INI-style file which contains name/value pairs each separated by an = sign. Comments may be included by preceding them with "//".
Only one name is currently supported: Channel. This should be set to the channel string, enclosed in quotes.
Communication
The scoreboard issues a regular (1 second) ping on chat channel -6447330 consisting of the letter S followed by its channel string (derived from its configuration file). A client script should listen for this channel and record the UUID(s) of scoreboards broadcasting on the channel they are configured for. (For consistency, it is suggested that this channel be specified in a config file for the client script, in a value named "Scoreboard").
Because several different scoreboards might share the same channel, client scripts should record the UUIDs in a list, and cycle through them sending the data to all UUIDs. To prevent runtime errors, it is wise to check that the scoreboard exists before doing so each time (in case scoreboards are removed). This may be done by testing that the resulting list from llGetObjectDetails() (using any parameter to that function) is not null length.
The following functions together send data to scoreboards whose UUIDs are stored in a list named Scoreboards; the count of members of that list is ScoreboardsCount:
// Send Text to all scoreboards
SendToScoreboards(string Text) {
integer P;
for (P = 0; P < ScoreboardsCount; P++) {
MessageObject(llList2Key(Scoreboards, P), Text);
}
}
// Wrapper for osMessageObject() that checks to see if object exists
MessageObject(key Uuid, string Text) {
if (ObjectExists(Uuid)) {
osMessageObject(Uuid, Text);
}
}
// Return true if specified prim/object exists in same region (not so reliable for avatars)
integer ObjectExists(key Uuid) {
return (llGetObjectDetails(Uuid, [ OBJECT_POS ]) != []) ;
}
Messages sent to the scoreboards should be preceded by a two-character code denoting the type of message. The following messages are supported:
It is not necessary to include the channel in these messages because messages should only be sent to scoreboards previously identified as broadcasting on the appropriate channel.
Note that the DR, DH and DL commands will not cause a visible change to the scoreboard. When all the data is sent, the DD command should be used to update the display.
For smoothness of operation, it is recommended that changes are buffered, and the display only updated periodically. If DC/DD are issued too frequently, the display will be continually redrawing its texture and will be a frustrating user experience.
Possible future enhancements
The commands could be enhanced to allow changes in font, foreground and background colour, other drawing commands, etc. The scoreboard in its current state is a fairly bland implementation.