log inhelp

 | 

  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

WP4 2D_3D content publishing component

Page history last edited by klaus 13 years, 3 months ago

 

 

Managing 3D-Objects of Second Life Simulations and

Development of a Stage Control System

 

Feasibility study, an implementation, and a practical example

Technical Report

 

  1. Introduction
    1. Disclaimer for using this document
  2. Managing 3D-Objects
    1. Basic Approach
    2. OpenMetaVerse Application
      1. Download, install, and usage of the LibOpenMetaverse project
      2. Login to Second Life
      3. Working with the OpenMetaverse shell
    3. Possibilities and Limitations
      1. Position and orientation of objects
      2. Linked objects
      3. Textures of objects
      4. Access rights and ownership
      5. Scripts and other objects in the content
    4. Export Process
      1. Identify the object with the Second Life client
      2. Move the avatar to a certain position with LibOpenMetaverse client
      3. Export objects in TestClient
      4. Exported objects
      5. Handling scripts
    5. Repository Structure
      1. Data Structure
      2. Example
      3. Scripts
      4. Description of the data format (XML specification) of objects exported from Second Life
      5. XSD Specification of exported objects
    6. Import Process
      1. Finding the import positions with the Second Life Client
      2. Moving the avatar to this position with the LibOpenMetaverse client
      3. Importing objects
      4. Arranging imported objects
      5. Handling scripts
  3. Stage Control System
    1. Requirements
      1. Description of a stage
      2. Creation and modification of stages
      3. Automatic setup and removal of stages
    2. Basic Approach
      1. Stage objects and background texture
      2. Rezzing and removing stages
      3. Common Interface
      4. Creating and modifying stages
    3. Objects and Scripts
      1. Rez Controller
      2. Surrounding Box
      3. Stage Objects (Furniture objects)
      4. Demo Stage Control Object
    4. Public interface design of the Stage Control System
      1. Putting an object on the stage
      2. Setting the Background Texture (cubus projection)
      3. Clearing the whole stage
      4. Removing an object from the stage
    5. Setup of Stage Control System and Stages
      1. Pre-requisites and initial setup of the Stage Control System
      2. Building a new stage
    6. Usage of the Stage Control System
      1. Rezzing stage
      2. Clearing the stage
      3. Adapting the created stage during usage
      4. Demo Stage Controller
    7. Limitations
  4. Conclusion and further Work
  5. Appendix
    1. Appendix 1: Images of Existing Stages
    2. Appendix 2: Repository of the Six Existing Stages
    3. Appendix 3: XML format examples of exported objects
    4. LL-Scripts
      1. stage controler script

 

This document is licensed under a „Creative Commons Noncommercial-Share Alike 3.0 Austria“ Licence (“Creative Commons Namensnennung-Keine kommerzielle Nutzung-Weitergabe unter gleichen Bedingungen 3.0 Österreich”). Further details see: http://creativecommons.org/licenses/by-nc-sa/3.0/at/

 

Autor: Alexander Nussbaumer, Volker Kieslinger

 

 

This project has been funded with support from the European Commission. This publication reflects the views only of the author, and the Commission cannot be held responsible for any use which may be made of the information contained therein.

 

Second Life is a registered trademark of LindenLab Corp., San Fransico other mentioned trademarks are the respected properties of their owners.

 

 

Introduction

 

This document is written for people experienced with SL (building objects and scripting).

 

In this report a feasibility study, an implementation, and a practical example is documented. The main topic is about managing objects in Second Life. This includes the export of objects to the local hard drive, the import of these objects back to Second Life, and the automatic creation of stages using such objects.

 

The report describes the solution to two problems in Second Life. First, objects can not be exported, saved and imported again. Backup of 3D objects is not possible with the Second Life client. Second, creating settings of objects (stages) is an exhausting task if this has to be done very often, since positioning and rotating of all objects has to be done manually.

 

It has been investigated how objects can be exported from Second Life and stored on the local hard drive. Since this functionality is not offered by the Second Life client, a different tool has been used and a clear methodology has been elaborated and written in this report. The data and the structure of the exported object have been described and explained. Furthermore, the methodology of how to import the exported objects has been investigated. In this report the results of these studies are described in detail. Some limitations have been encountered, which are also described.

 

Secondly, a system has been designed and implemented which allows for automatically rezzing a predefined stage. The developed system (Stage Control System) is able to manage the objects used in several stages. It also can rez and position these objects automatically according to a predefined list which is sent to this system from an external system.

 

Both parts have been used in an example with existing stages in order to demonstrate and prove the presented approaches. The objects of six existing stages have been exported and saved on the local hard drive. These objects have been imported again into Second Life. Then new stages have been created and used as predefined stages. The Stage Control System can now be used to automatically rez and remove these stages consisting of objects originally exported from other stages.

 

 

Disclaimer for using this document

 

The authors cannot be held liable for applying the knowledge enclosed in this document. There is NO WARRANTY that the use of the procedures described in this technical document satisfies the legal constraints in your jurisdiction at the time of application.

 

Generally speaking, for managing content, as discussed in this document, you need to own the intellectual property rights from the respected copyright holder. For the evaluation of this technical report the authors used only content which was originated by themselves on IT infrastructure owned by themselves, using the open source platform opensim which is Second Life compatible.

 

The purpose of this document is to create a classroom content management system, which will be used in a closed group, closed infrastructure environment satisfying the legal requirements addressed above. For applications different to that, or by accessing a public infrastructure (e.g. Second Life) seek legal council, especially the applying terms and conditions of the grid service provider (e.g. Linden Labs for Second Life) and copyright laws of the involved jurisdictions.

 

 

Managing 3D-Objects

 

 

Basic Approach

 

Basically 3D objects in Second Life should be exported to the local hard drive, stored there and re-imported to Second Life (of an OpenSim server).

 

Every time when the Second Life client is started, 3D objects are displayed in the client. To perform this operation, the objects have to be retrieved by the client from the Second Life server including all properties like textures. Consequently, it is possible to transfer 3D objects (including their properties) from the Second Life server to the local computer.

 

In order to perform this task outside of the Second Life client, an application is needed which has implemented the client-server protocol of Second Life and which allows for storing the 3D object on the local hard drive.

 

On the Web site of the Open Metaverse Foundation (http://openmetaverse.org/) there is an application (LibOpenMetaverse) which exactly offers this functionality. The Open Metaverse Foundation is a non-profit organisation founded with the mandate of developing open technologies and open-source software related to the metaverse and virtual worlds.

 

With the help of this application the 3D objects can be downloaded (exported) to the hard drive, where the objects includes the common properties of 3D objects and textures are downloaded as extra image files. The same objects can be re-imported into Second Life or another OpenSim server (also together with the texture files).

 

In the following sub-sections details are provided and explained as to how this application has to be used and how objects can be downloaded and re-imported.

 

 

OpenMetaVerse Application

 

The LibOpenMetaverse project can be downloaded from the Web page http://openmetaverse.org/. Basically this is a software libraryenabling someone to build a Second Life client application. It provides the infrastructure and protocol implementation needed to connect and interact with the Second Life server.

 

A test client is included in this library, which is a simple command line tool implementation. This tool offers several commands and actions (in the command line), such as: login an avatar, move the avatar, or chat with other avatars. Important for the project, this tool also allows for exporting and importing objects from and to the local hard drive (instead of displaying them).

 

Objects are stored as XML files and textures are stored as separate image files. This application does not download scripts or other objects from the content of the downlaoded object. These have to be downloaded manually.

 

 

Download, install, and usage of the LibOpenMetaverse project

 

The LibOpenMetaverse project can be download from the OpenMetaVerse Web site (http://openmetaverse.org/). The version used in this project is: version 0.6.3

(version 0.7.0 released on 21 July 2009 does not work properly for unknown reasons)

 

Unpack the zip file to a location of your choice. The command line tool "TestClient" is located in the 'bin' folder. This application is a test application which uses the libOpenMetavere library. A new application could have been developed based on the LibOpenMetaverse project, but this was not necessary for this project. The whole download (export) and upload (import) process is done in the command line prompt of the "TestClient" command.

 

To try out this client, open a DOS shell and move to the 'bin' folder. Then type in:

 

C:\Programme\LibOpenMetavers> TestClient --help

 

This gives you a list of available parameters.

 

TestClient.exe --first firstname --last lastname --pass password [--loginuri="uri"] [--startpos "sim/x/y/z"] [--master "master name"] [--masterkey "master uuid"] [--gettextures] [--scriptfile "filename"]

 

 

Login to Second Life

 

Before logging in to Second Life, a new folder should be created where the exported objects will be stored. Then change to this folder in the DOS shell (cd <path-to-newfolder>). The TestClient can be started now by prepending the path to the installation directory of LibOpenMetaverse. For example:

 

C:\slobjects:> c:\Programme\LibOpenMetavers\bin\TestClient

 

In order to login to Second Life, use the TestClient and use parameters to indicate avatar name and password. Synopsis and example:

 

TestClient.exe --first firstname --last lastname --pass password TestClient.exe --first Donald --last Duck --pass 12345

 

The TestClient application responds with the prompt:

 

1 avatars online>

 

Other avatars can now see this avatar in world (most likely as a ghost).

 

In order to logout, type in the quit command

 

1 avatars online> quit

 

 

Working with the OpenMetaverse shell

 

Once an avatar is logged in into the shell, then several command can be used to control the actions of the avatar. Tying in the "help" command lists all available commands. Tying in "help <command>" gives details on the respective command.

 

1 avatars online> help

1 avatars online> help <command>

 

The most important commands which are needed to import and export objects are:

 

moveto

 

help moveto:

Moves the avatar to the specified global position using simulator autopilot. Usage: moveto x y z

 

This command moves the avatar to the absolute position x/y/z inside a region.

The coordinates can be determined on the map tool of the Second Life client.

 

goto

 

help goto:

Teleport to a location (e.g. "goto Hooper/100/100/30")

 

This command teleports the avatar to specific region on a specific location given with absolute coordinates In the example above the avatar is teleported to the region "Hooper" on the position <100, 100, 30>.

 

findobjects

 

help findobjects:

Finds all objects, whose name contains search-string. Usage: findobjects [radius] <search-string>

 

This command detects objects which are close to the avatar and lists them where both name and UUID of the objects are listed. For example to list all objects which are not more than 10 meters away:

 

1 avatars online> findobjects 10

 

Object 'Mug of Coffee': 2bf79ab6-4459-415d-3471-826ea93ecc68

Object 'executive chair black leather 2.1': 547c6329-37bd-6bf3-c77d-0e5558e91b8b

Object 'LectureConfigurator': 5f6037c6-9c22-6550-7255-634c55764823

Object 'Object': 667da58b-4b94-dcae-4b9a-6c9061335c15

Object 'Object': 07ae3911-3688-e5d0-f028-2a3556622ee8

Object 'desk lamp 1.1 touch on/off': 05584905-78a3-b98f-3cfc-42d795a8cf5e

 

The search can be restricted by adding a search string as parameter. For example:

 

1 avatars online> findobjects 10 Mug

 

Object 'Mug of Coffee': 2bf79ab6-4459-415d-3471-826ea93ecc68

 

export

 

help export:

Exports an object to an xml file. Usage: export uuid outputfile.xml

 

In order to export an object to the hard drive, the export function has to be called with the parameters <uuid> and <outputfile.xml>. <uuid> is the UUID of the object to be exported, this can be retrieved from the findobjects command (see example above). The outputfile.xml is the filename under which the object should be stored

 

Textures of the object are also stored in the same directory. All objects in the content of this object are not exported.

 

import

 

help import:

Import prims from an exported xml file. Usage: import inputfile.xml [usegroup]

 

In order to import an object, the import function has to be called with the parameter inputfile.xml. inputfile.xml is the filename under which the object has been stored.

 

The textures of this object are automatically imported together with this object.

 

 

Possibilities and Limitations

 

Position and orientation of objects

 

The position and orientation of exported objects is saved in the XML content of the exported objects. However, this information is not used when the object is imported. The imported objects are positioned in front of the avatar that imports the object. Rotation is set to default rotation.

 

If there are complex collection of objects to be exported (stages, houses) which are exported and imported, then is can be an time-consuming, since all objects have to be positioned and rotated anew.

 

Linked objects

 

If objects consist of many prims (linked objects) than only this object has to be exported and imported. All included prims are exported and imported automatically with this object. Position and rotation of the prims is kept correctly in this case.

 

A possible solution is tosave time on this task is to link all objects of a complex setting together to one object and to export and import this linked object. After the object has been imported, then this linked object can be split up to single objects or prims.

 

 

Textures of objects

 

Textures are automatically exported with the object and imported with the object.

 

 

Access rights and ownership

 

From a technical point of view all objects can be exported although if the exporting avatar has no access rights on the respective objects. However, this may be an illegal action. If objects are imported, the ownership and creator is the avatar who has imported the object. Original owner and creator are removed.

 

 

Scripts and other objects in the content

 

Each object has a content section (inventory of an object) where scripts and other objects (e.g. notecards can be placed). If objects are exported, none of these objects can be exported together with this object.

 

Scripts have to be exported manually (open the script, copy it to the clipbloard and paste it in a text editor, save the file to the location where the exported objects are stored). In this case the exporting avatar needs to have access rights to the script.

 

Export Process

 

In order to export an object, several things have to be done. Ideally two avatars should be used, one to login with the Second Life client and the second won to login with the LibOpenMetaverse client.

 

Identify the object with the Second Life client

 

The object to be exported has to be identified (which means that name and UUID has to be found out). This can be done by using the Second Life client:

 

1) The avatar should be logged in with the Second Life client and moved close to the object to be exported.

 

2) Then click on the object to be exported with the right mouse button and in the context menu on "Edit".

 

3) In the Edit dialogue the name of the object is displayed.

 

 

Move the avatar to a certain position with LibOpenMetaverse client

 

4) Get the position of the avatar in the Second Life client: this can be retrieved by opening the Map tool in the Second Life client - there you find region and absolute coordinates where the avatar is located in this region.

 

5) Use the TestClient and teleport the (second) avatar to the location of the (first) avatar in the Second Life client. This can be done by using the command:

 

1 avatars online> moveto RegionName/X/Y/Z

 

This command teleports the (second) avatar to the same position as the (fisrt) avatar in the Second Life client. If the (first) avatar in the Second Life client is sill active, the (second) avatar in the TestClient is visualised most likely as a ghost (cloud).

 

 

Export objects in TestClient

 

6) Use the command to find objects in the TestClient (see description above). Either list all objects not to far away and manually identify the object to be exported by its name (see step 3) or search for the object to be exported

 

1 avatars online> findobjects 10

1 avatars online> findobjects 10 objectname

 

In both cases the UUID of the object to be exported has to be identified (written beside the object name).

 

Object 'Mug of Coffee': 2bf79ab6-4459-415d-3471-826ea93ecc68

 

7) Use the export command together with the respective UUID and a filename to download the object.

 

1 avatars online> export 2bf79ab6-4459-415d-3471-826ea93ecc68 mug_of_coffee.xml

 

 

Exported objects

 

8) After the export command has been processed, in the directory where the TestClient application is running, an XML file has been created with the name given in the export command as parameter. Additionally some image files are stored at the same place. These image files are the textures of the exported object. Their filenames are the UUIDs which are used in the XML file of the exported object to refer to them.

 

 

Handling scripts

 

9) Scripts and other objects in the content of the exported object are not exported. This has to be done manually. A text file with the same filename as the exported object should be created and opened with a text editor. Then the script of the object has to be opened and the content has to be copied into the clipboard. The this script can be pasted into the text editor and the file can be saved.

 

 

Repository Structure

 

Data Structure

 

All objects are stored as XML files and all textures are stored as jpeg2000 and TGA files.

 

An XML object file contains at least the following information:

- general information of the object (name, description);

- the 3D structure of the object;

- the position and roation of the object;

- the primitive objects of this object (if it is a linked object);

- the textures reference of the object (UUIDs of the textures).

 

Textures are saved separately under the filename 'uuid'. Textures are saved in both JPEG2000 and TGA format.

 

filename.xml

uuid1.jp2

uuid1.tga

uuid2.jp2

uuid2.tga

 

 

Example

 

For example the export command

 

export cefdc2db-48bb-2f60-1916-b8d8e1662617 stage-floor.xml

 

may create the following files in the directory where the TestClient is running:

 

C:\temp> dir

stage-floor.xml

4159ad65-d368-113e-5b7c-2069e44dff4f.jp2

4159ad65-d368-113e-5b7c-2069e44dff4f.tga

89556747-24cb-43ed-920b-47caed15465f.jp2

89556747-24cb-43ed-920b-47caed15465f.tga

 

One object (stage-floor.xml) has been exported together with two textures.

 

 

Scripts

 

It is recommended that scripts are manually downloaded and saved at the same place. This can be done by opening the script of an object and copy the content of the script to the clipboard. Then a text file should be created which has the same name as the object file, but with the extension ".script". This file can be opened with a text editor and the script content can be pasted into it from the clipboard.

 

C:\temp> dir

stage-floor.xml

stage-floor.script

4159ad65-d368-113e-5b7c-2069e44dff4f.jp2

4159ad65-d368-113e-5b7c-2069e44dff4f.tga

89556747-24cb-43ed-920b-47caed15465f.jp2

89556747-24cb-43ed-920b-47caed15465f.tga

 

 

Description of the data format (XML specification) of objects exported from Second Life

 

Basically, objects exported from Second Life are represented in XML format. Linden Lab has defined Linden Lab Structured Data (LLSD) which offers a flexible way to express data. It is easy to understand and to process and supports the exchange between loosely-coupled systems. Detailed information can be found under: http://wiki.secondlife.com/wiki/LLSD

 

The basic approach of LLSD is that data are serialised in XML by sequencing key-value pairs. Keys are string within "key" XML elements and values are the values of the keys within XML elements according to the value type. There are eight value types defined

 

  • Boolean - true or false;

  • Integer - a 32 bit signed integer;

  • Real - a 64 bit IEEE 754 floating point value;

  • UUID - a 128 bit unique value;

  • String - a sequence of zero or more Unicode chracters;

  • Date - an absolute point in time, UTC, with resolution to the second;

  • URI - a String that is a URI;

  • Binary - a sequence of zero or more octets (unsigned bytes).

 

For example, the name of an object can be specified by:

<key>name</key>

<string>Cube</string>

 

The construct of an "array" is a collection of more than one value. For example if the key is position, then the value is a vector consisting of three Real values. Furthermore the construct of a map is the container in which the key-value pairs are seen as dictionary and the keys are unique inside of a map.

 

For example, the position can be specified by

<key>position</key>

<array>

<real>83.084358215332031</real>

<real>152</real>

<real>107.68852996826172</real>

</array>

 

Second Life Objects are structured according to LLSD. All the properties of an object are sequenced as key-value pairs.

 

  • At the beginning of an object general properties are given: name, description, phantom, physical, position, rotation, scale, material, and shadow;

  • Then the texture is defined, whereby the properties are specified in a separate map: colors, scales, scalet, offset, imagerot, bump, shiny, fullbright, media_flags, mapping, glow, imageid. The last one (imageid) is the unique id of the image file used as texture. This file is exported together with the object and saved under the filenem uuid.tga an uuid.jp2;

  • Then the volume is defined (which defined the "physical" form of the object). The prim type is defined, then curve, end, radius offset, revolutions, scale, shear, skew, taper, twist_begin.

 

An example of such an object expressed in XML format can be seen in the Appendix (Example One).

 

In the case of interlinked objects (objects with more then one prim), the specifications of the several objects are just sequenced as it is done for key-value pairs. An example for an interlinked object (object with two prims) is given in the Appendix (Example Two).

 

The formal specification of the XML format can be expressed as XML Schema (XSD). The schema specification is defined if the structure of an XML object is valid. However, it does not explain the data given in the XML data. Anyway, the XML schema for Second Life Object is listed below. Document Type Definitions (DTD) use the same approach as XML Schema and also lack of not explaining the XML data.

 

 

XSD Specification of exported objects

 

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

<xs:element name="llsd">

<xs:complexType>

<xs:sequence>

<xs:element ref="map"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="map">

<xs:complexType>

<xs:sequence>

<xs:choice minOccurs="0" maxOccurs="unbounded">

<xs:element ref="map"/>

<xs:element ref="real"/>

<xs:element ref="array"/>

<xs:element ref="boolean"/>

<xs:element ref="integer"/>

<xs:element ref="key"/>

<xs:element ref="string"/>

</xs:choice>

<xs:element minOccurs="0" ref="uuid"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="array">

<xs:complexType>

<xs:sequence>

<xs:element minOccurs="0" ref="map"/>

<xs:element minOccurs="0" maxOccurs="unbounded" ref="real"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="boolean" type="xs:integer"/>

<xs:element name="integer" type="xs:integer"/>

<xs:element name="key" type="xs:NMTOKEN"/>

<xs:element name="string" type="xs:string"/>

<xs:element name="uuid" type="xs:string"/>

<xs:element name="real" type="xs:decimal"/>

</xs:schema>

 

 

Import Process

 

The import process is similar to the export process

 

Finding the import positions with the Second Life Client

 

1) Login the (fist) avatar with the Second Life client and move to the position where the objects should be imported.

 

Moving the avatar to this position with the LibOpenMetaverse client

 

2) Get the position of the avatar in the Second Life client: this can be retrieved by opening the Map tool in the Second Life client - there you find region and absolute coordinates where the avatar is located in this region.

 

3) Use the TestClient teleport the (second) avatar to the location of the (first) avatar in the Second Life client. This can be done by using the command:

 

1 avatars online> moveto RegionName/X/Y/Z

 

This command teleports the (second) avatar to the same position as the (fisrt) avatar in the Second Life client. If the (first) avatar in the Second Life client is sill active, the (second) avatar in the TestClient is visualised most likely as a ghost (cloud).

 

 

Importing objects

 

4) Use the TestClient to import objects. The command together with the respective filename of the downloaded object will import this object. For example:

 

1 avatars online> import mug_of_coffee.xml

 

The objcet "Mug of Coffee" is positioned in front of the avatar and rotation is set to default.

 

Make sure that the importing avatar in the TestClient has permission to build (create objects) on the land where it is located.

 

Arranging imported objects

 

5) Use the Second Life client to position and rotate the imported object. If several objects of a complex setting (stage) have been imported, then the stage has to be created anew by moving and rotating the imported objects

 

6) The imported objects can be copied into the inventory of the avatar and given to another avatar.

 

 

Handling scripts

 

7) In order to manually import scripts, new scripts have to be created in the content of the objects. Then the manually downloaded scripts have to be opened with a text editor and copied to the clipboard. Then the a new script has to be created in the content of the object and the script can be pasted into this newly created script.

 

Stage Control System

 

In this section the implementation and usage of the Stage Control System is described. This system allows for automatically setting up and removing stages. It is controlled by the user or other systems.

 

 

Requirements

 

Description of a stage

 

Basically, a stage consists of several stage (furniture) objects, such as chairs, tables, or whiteboards. The stage is a collection of single furniture objects, it is not one linked object consisting of all the single furniture objects. This is important, because interaction with the single objects must be possible (for example sitting on a chair or turning on and off a lamp).

 

Furthermore there is a surrounding box where textures can make illusions?? of environments (for example a mountain area or a certain city). The objects of a stage are placed inside this surrounding box and the avatars also moved inside this surrounding box. A cubus?? project increases the degree of illusion of an environment.

 

Therefore the formal description of a stage consists of a set of stage objects and background textures. For each stage object their position and rotation has to be defined. For example:

 

object name1 <posx, posy, posz> <rotx, roty, rotz>

object name2 <posx, posy, posz> <rotx, roty, rotz>

object name3 <posx, posy, posz> <rotx, roty, rotz>

texture name of surrounding box

 

 

Creation and modification of stages

 

A content author should have the possibility to create new stages and to modify existing stages. A procedure should be possible for the creation and modification of stages that can be performed by people with "normal" technical skills.

 

 

Automatic setup and removal of stages

 

The basic requirement is to dynamically set up and remove stages (or change stages). An external control system should have the possibility to set up or remove complete states. Since a stage consists of single stage objects, the Stage Control System has to be able to accept commands to rez and remove single stage objects. An external ?? sends a sequence of stage objects and the Stage Control System rezzes the respective objects sequentially. The same goes for removing.

 

 

Basic Approach

 

Basically the Stage Control System consists of several objects and scripts. Together they implement the required functionality. Figure 1 gives an overview on the Stage Control System, its objects, the interface, and their relations to each other.

 

 

 

 

Figure 1: Basic Approach of the Stage Control System

 

 

 

Stage objects and background texture

 

The Stage Control System contains a set of stage (furniture) objects with which a stage can be made up. Furthermore, it contains the surrounding box with different background textures. Both stage objects and textures can be added and removed by a content author. The stage objects are included in the content of the Rez Controller object, the textures are contained in the content of the surrounding box.

 

Stage objects are automatically rezzed by the Rez controller if it gets the 'rezOnStage' command. Stage objects are removed by themselves if they get the 'removeFromStage' command. For this reason stage objects have to contain a script which deletes the stage object if it receives deleteFromStage command. This script is part of the Stage Control System and has to be added by the Administrator before the object is added to the Rez Controller.

 

The texture of the surrounding box is automatically set by the surrounding box script if it receives the command 'setBackgroundTexture'.

 

 

Rezzing and removing stages

 

In order to rez an entire stage the single objects have to be rezzed and the background texture has to be set. To rez single objects, object name, position and rotation has to be sent to the Rez Controller. To set a background texture, the texture name has to be sent to the surrounding box.

 

The Stage Control System has no information about entire stage settings, but it just performs elementary operations (rezzing single objects and setting a background texture). So rezzing a stage is a sequence of rezOnStage commands, which is controlled by a system outside. This outside system has to have the knowledge how a stage is to be built (coordinates and rotations vectors of all involved objects).

 

Removing an entire stage can be done by sending the 'clearStage' command. All stage objects receive this command and delete themselves.

 

Common Interface

 

A common interface is provided though the chat channel. A list of commands which are understood by the Stage Control System and their syntax is described below. These commands have to be used to perform the elementary operations. The commands are not all executed by one object / script, but there are several objects and scripts which listen to the commands.

 

 

Creating and modifying stages

 

In order to create a new stage, the stage objects have to be positioned as they should be. Then the script has to be included in each object, which allows each object to delete itself. Then a script for distance measuring has to be added to each object, which allows for measuring the distance between stage object and rez controller. By clicking on an object the distance is automatically measured and the command to rez this object is printed out.

 

All these printed out commands have to be collected and put to the outside control system. The collection of these commands define the stage, together with the setBackgroundTexture command. At this point the stage has been defined in the outside control system, which now can rez the entire stage.

 

 

Objects and Scripts

 

The Stage Control System consists of the following elements (objects and scripts):

 

Rez Controller

 

Description

The Rez Controller is a small object in the middle of a stage which can rez single objects on the stage. All stage objects are in the content of the Rez Controller. This is necessary because they have to be rezzed by the Rez Controller.

 

In order to rez objects, the Rez controller listens to channel 47, where it gets the command to rez an object. The command has to include position and rotation of the object to be rezzed. The Rez controller interprets this command and rezzes the object accordingly.

 

Furthermore, the Rez Controller listens to the Measuring command. A stage object can send its position and rotation, then the Rez Controller calculates the distance and prints out a command how this stage object can be rezzed.

 

Included Scripts:

1) Rez Controller Script

 

Listens To:

1) rezOnStage <object name> <position> <rotation>

2) GetMyPosition : ObjectName : <X, Y, Z> : <Rx, Ry, Rz, Rs> (this is an internal message)

 

 

Surrounding Box

 

Description

The surrounding box is a big box which contains all furniture objects and which creates the environment. It can change its textures in order to create an illusion of an environment

 

Included Scripts:

1) Background Texture Setting Script

 

Listens To:

1) setBackgroundTexture <object name>

 

 

Stage Objects (Furniture objects)

 

Description:

The stage objects are the furniture objects of the stage.

 

Included Scripts:

1) Delete Object Script

2) Measuring Script (temporarily; deletes itself after usage)

 

Listens To:

1) removeFromStage: is performed by each stage object itself (using the delete script), if the object name is the same as the name in the command

2) clearStage: each object which receives this command deletes itself

 

 

Demo Stage Control Object

 

Description:

The Demo Stage Control Object is a controller to set up and remove entire stages. It has the same functionality as an external control object and simulates the task of an external control object.

 

Scripts:

(1) Demo Stage Control Script

 

Listens To:

none

 

 

Public interface design of the Stage Control System

 

The Stage Control System accepts commands provided through the chat channel. Currently the channel number is 47. However, this can easily be changed in the several scripts. According to the command, the Stage Control System performs an action like rezzing an stage object or clearing the stage. Please note, that the Stage Control System consists of several objects and scripts.

 

The following commands are consumed by different objects and scripts. However, they have in common, that together they provide the interface to other objects or systems (such as the Moodle controller).

 

In general, a command (which has to be typed into the chat channel) has the structure:

/47 command [list of parameters]

 

 

Putting an object on the stage

 

Synopsis: /47 rezzOnStage <object name> <X, Y, Z> <Rx, Ry, Rz, Rs>

 

Description:

This command puts an object from the inventory into the world according to the position and rotation parameters. The rotation has four values because it is expressed as quaternion.

 

Parameters:

object name: the name of the object in the inventory of the Rezz Controller

X: X position of the object

Y: Y position of the object

Z: Z position of the object

Rx: rotation regarding x-axis of the object

Ry: rotation regarding y-axis of the object

Rz: rotation regarding z-axis of the object

 

Example:

/47 rezzOnStage <mug of coffee> <0.82581, 0.78145, -0.05260> <0.00000, 0.70711, 0.00000, 0.70711>

 

Please make sure, that the brackets "<" and ">" are also part of the command line.

 

 

Setting the Background Texture (cubus projection)

 

Synopsis: /47 setBackgroundTexture <object name>

 

 

Description:

This command sets the background texture of the surrounding box

 

Parameters:

<object name> the name of the texture (include backets).

 

Example:

/47 setBackgroundTexture <Sky>

 

Please make sure, that the brackets "<" and ">" are also part of the command line.

 

 

Clearing the whole stage

 

Synopsis: /47 clearStage

 

Description:

All objects are removed from the stage and the background texture is set to a default.

 

Parameters:

none

 

 

Removing an object from the stage

 

Synopsis: /47 removeFromStage <Objektname>

 

Description:

A single object is removed from the stage.

 

Parameters:

<object name> the name of the object to be removed. The brackets need to be there along with the object name.

 

Example:

/47 removeFromStage <mug of coffee>

 

Please make sure, that the brackets "<" and ">" are also part of the command line.

 

 

Setup of Stage Control System and Stages

 

This section is a tutorial for the system administrator (or content designer) and describes how the Stage Control System is setup and the stages are created and modified.

 

Pre-requisites and initial setup of the Stage Control System

 

In order to setup the Stage Control System, the following steps have to be conducted. The objects and scripts describe in a previous section have to be available.

 

  • Second Life space is needed where the control objects can be placed stages can be built automatically;

  • surrounding box (background) has to be placed in this space. The surrounding box includes a script (which sets the texture);.

  • stage objects have to be available in world (in SL). They can be newly created, come from an object repository or the inventory of the avatar or from some other source;

  • the rez controller (including rez controller scripts) has to be put into space where the stages should be created;

  • a generic stage object script for position and rotation measuring has to be available in inventory;

  • a generic stage object script for deletion of itself has to be available in inventory.

 

 

Building a new stage

 

  • put stage objects to stage space and place and rotate them accordingly to form a stage of them;

  • put the two stage object scripts into content of each stage object:

    • the script for measuring;

    • the script for self-deletion.

  • click on each object: this will print the "rez command line" to the chat ("rez command line" is the command which rezzes the object to the right position with the correct rotation);

  • copy each 'rez command line' into a text file;

  • take all objects into the folder of the own (avatar) inventory;

  • put these object from the inventory into the content of rez controller:

    • same object have to be put only once into the rez controller, but the several command line have put multiple into the text file;

    • all object which are put into the content of the stage controller need to have 'copy' permissions.

  • put a texture into the content of the surrounding box;

  • click on surrounding box, this prints several commands (one for each texture) to the chat;

  • take the command with the texture you want to have for this stage and put it to the text file (below the rez commands);

  • now the text file contains a sequence of command lines, which defines the stage;

  • the command lines in the text file can be used by outer control systems.

 

example of a stage definition (text file)

  • rezOnStage <object name 1> <pos1> <rot1>

  • rezOnStage <object name 2> <pos2> <rot2>

  • rezOnStage <object name 3> <pos3> <rot3>

  • rezOnStage <object name 4> <pos4> <rot4>

  • rezOnStage …

  • setBackgroundTexture <texture name>

 

 

 

Usage of the Stage Control System

 

This section is a tutorial how the Stage Control System can be used by an outer control system. This would be the everyday use of the control functions.

 

Rezzing stage

 

  • if there is already a stage rezzed, this stage has to be cleared before -- for this purpose, the command 'clearStage' will remove all stage objects;

 

  • a stage is defined as set of "rez command lines":

    • rez command line of each object;

    • setBackground command.

  • to create the stage, the 'rez command lines' have to be sent to the rez controller in sequence -- these commands performs the creation of a stage.

 

 

Clearing the stage

 

  • a stage can be cleared with the command 'clearStage'

 

Adapting the created stage during usage

 

If a stage has been rezzed and is used by a tutor and learners, it still can be modified and adjusted. Stage objects can be moved, modified, or deleted, in order to adjust the stage to a lesson if necessary. There are two approaches fir how the modifications can be made:

  • the stage is modified by the tutor or by students. They can manually make changes. (Important: permissions have to be configured accordingly);

  • the stage is modified by the Moodle control system. If a lesson requires adjustments, then these modifications can be done automatically. The two commands 'deleteFromStage' and 'rezOnStage' are sufficient for this task. If an object should be moved, it has to be deleted and rezzed again at a different position.

 

All these adaptations are not persistent. If this stage is created anew then these changes are intentionally lost, because the stage definition is stored as fixed list in the external control system. The Stage Control System does not keep such information.

 

Demo Stage Controller

 

The demo stage controller is an external control object which rezzes and removes entire stages. This object is used to test the Stage Control System. It can also be used to demonstrate the functionality of the Stage Control System. It simulates the behaviour of the Moodle control object.

 

Limitations

 

The rotation of the rez controller is not taken into account when positions of stage objects are measured relatively to the rez controller. The consequence is that the created stages can not be rotated when the rez controller is rotated. The stages always have the same rotation.

 

The centre of stage objects must not be further away from the centre of the rez controller than 10m. If a stage object is further away then the position and rotation measuring script silently fails. In this case this script does not print out the rez command line, which it usually does.

 

If more than one rez system is used on one SL simulation then a messaging conflict will arise. In this case the channels or command lines of the communicating objects (stage objects and rez controller) have to be adapted accordingly.

 

The rez controller does not print out a list of command (help function) intentionally, because this could empower griefers to manipulate the stages and courses.

 

 

Conclusion and further Work

 

In the first part of this report it has been shown how objects of Second Life can be exported and stored on the local hard drive. These objects can also be re-imported and are available for further usage in Second Life.

 

In the second part the implementation of the Stage Control System has been described. With this system it is possible to automatically create and remove stages. This system can be controlled from outside, which makes it possible that it can be connected with a lesson management system.

 

In a practical example, the objects of six existing stages have been exported and stored on the local hard drive. The used stages and a list of all objects is given in the Appendix. Then these objects have been imported and the stages have been rebuilt with these objects (however slightly modified). According to the tutorial for creating stages (described above) these stages are put into the Stage Control System and the description file (the list of rez commands) are put into the Demo Stage Controller. Now the Stage Control System can be used now by the external Moodle controller.

 

As outlined in the two sections about the limitations there is some room for further work and improvements. Managing exported objects on local hard drive can be done more systematically. Using a versioning system would support to use the export mechanism as backup strategy.

 

Appendix

 

In this appendix a practical example is documented. The objects of six existing stages (Appendix 1) have been exported and stored on the local hard drive (Appendix 2). Then these objects have been imported and the stages (slightly modified) have been rebuilt. Then these stages are put into the Stage Control System and can be used now by the external Moodle controller.

 

Appendix 1: Images of Existing Stages

 

Stage 01

 

 

 

 

Stage 02

 

 

 

 

Stage 03

 

 

 

Stage 04

 

 

 

 

 

Stage 05

 

 

 

Stage 06

 

 

 

 

 

 

 

Appendix 2: Repository of the Six Existing Stages

 

 

Stage 01

 

Object 'executive chair black leather 2.1': 547c6329-37bd-6bf3-c77d-0e5558e91b8b

chair_black_leather_2.1.xml

 

Object 'desk lamp 1.1 touch on/off': 05584905-78a3-b98f-3cfc-42d795a8cf5e

desk-lamp.xml

 

Object 'Object': 667da58b-4b94-dcae-4b9a-6c9061335c15

object-desk.xml

 

Object 'Mug of Coffee': 2bf79ab6-4459-415d-3471-826ea93ecc68

mug-of-coffee.xml

 

Object 'Object': 07ae3911-3688-e5d0-f028-2a3556622ee8

object-box.xml

 

Object 'midibox': 50abe2a1-e555-2118-38aa-6a8a4f3a7941

midibox1.xml

 

Object 'midibox': 91debe03-c19b-faae-5e20-2d90b599343b

midibox2.xml

 

Object 'ObjecBillboardt': d654c0b6-8e75-671c-62e0-e829ed229d17

objectbillboard.xml

 

Object 'stage floor': 070e330e-48e2-aa18-8f61-f5487e826979

stage-floor.xml

 

 

Stage 02

 

Object 'BijoCam Interface Dispenser One Prim v1.2': 661b75d4-625f-e531-f85a-e201e0ad9a99

bijocam-interface-despenser.xml

 

Object 'Object': a8ffba46-db8f-0c78-eebe-75f88f147ebd

object1.xml (halbrunde plattform)

 

Object 'Object': c29d44dd-52e9-bc76-817b-b428c80c4e18

object2.xml (keil)

 

Object 'Object': 51b018fe-dae3-4405-9c3c-09814cee1371

object3.xml (walls)

 

Object 'Object': 03ce3642-8dde-ec2f-8bb0-9b81fdeca47a

object4.xml (laengere keil)

 

Object 'Object': e3c6cc51-aac6-6a1f-f650-488cfbae3418

object5.xml (blaue platte)

 

Object 'Hand Show Chair': abdef15a-4930-7511-bfc5-0ca96de08bbb

hand-show-chair.xml

 

Object '[Ali] Cassiopeia Grandfather Clock': 6ee6d94d-a28b-05a2-35ad-031510bce670

ali-cassiopaeia-grandfather-clock.xml

 

Object 'GF Clock Pend': c69f9a4c-cd81-9c99-c52b-263908337a40

gf-clock-pend.xml (1 texture)

 

Object 'GF Clock Pend': 3f283bb1-93a2-d69b-9ea6-3c880281bb53

gf-pend-clock2.xml (0 texture)

 

Object 'ddddddd': 44df65b7-e4b7-a6aa-f466-98ea8689fdc3

desk.xml

 

Object 'Library Chair': d668f640-8132-38a3-6d3e-61b9eec0a389

library-chair.xml

 

Object 'BijoCam Camera v1.0': 269c0d9e-5a2f-bdce-f3fa-835bd0e8f2c8

bijocam-camera.xml (0 textures)

 

Object 'midibox': 9a501ec8-eca1-f875-6197-ad9f69887a2e

midibox.xml

 

Object 'stage floor': d781b81a-7f4d-fab5-1053-cf7ca68e7cbb

stage-floor.xml

 

Object 'WhiteBoard (e)': 53702474-7bf1-9b32-62b7-4d474672868d

whiteboard.xml (11 textures)

 

Object 'GL - aloevera': f10a7ab2-ff44-5fdd-2ad7-4085196d9643

gl-aloevera.xml (5 textures)

 

 

Stage 03

 

Object 'WhiteBoard (e)': 10d0fd51-196b-0ea7-5abb-7f90f70546c5

white-board.xml

 

Object 'Event Timer': 75ab8740-1db4-023f-315a-3b3abc88419f

event-timer.xml

 

Object 'Party Spotlight': a3136ff2-345a-e326-e506-37dcc7ebd746

party-spotlight.xml

 

Object 'Party Spotlight Control Panel': fc02a5d1-49c1-44ec-548c-8add62810bca

party-spotlight-control-panel.xml

 

Object 'Cafe': 01987e7d-dddb-22a7-851c-ff1e22833414

cafe.xml (stage floor)

 

Object 'Podium': 4f407137-6b17-0f91-b695-630e6d360c0f

podium1.xml

 

Object 'podium': 7025f297-313b-77de-b5cb-490216c4290a

podium2.xml

 

Object 'bande': 8e261382-cd70-5d61-03b7-4479194b72aa

bande1.xml

 

Object 'bande': 7fbd481a-e687-4312-669c-9e48d3a25740

bande2.xml

 

Object 'bande': e9ac0d48-5123-5a6b-4fe7-5acef78c029c

bande3.xml

 

Object 'Pointer': bd3bade1-7cec-74ab-be6a-55ddf5ac4ffb

pointer.xml

 

Object 'roman chair': 9473cc1d-fe34-5860-4213-436110e291d1

roman-chair.xml

 

Object 'Hand Show Chair': 75416543-ae3d-9853-f857-b8924122e2e8

hand-show-chair.xml

 

? Object 'midibox': 1cc7c30f-577f-1067-7fcf-b203e2c7d73b

midibox1.xml

 

? Object 'midibox': 796f3fc0-91a1-6b55-b030-cdbcfee477bb

midibox2.xml

 

? Object 'Lobby Entree': 22b1929a-e1b3-a10f-9914-b6c35070382d

lobby-entree.xml

 

 

Stage 04

 

Object 'Super Comfy Sofa by Homestylers': e2c04398-9be9-4d9c-1923-611d0852ae47

super-comfy-sofa.xml

 

Object 'Super Comfy Armchair by Homestylers': 644e6ee1-ce1d-17c9-8705-fa76e2905b5b

super-comfy-armchair.xml

 

Object 'podium': 85ad3a2b-e926-c37c-ac0f-5db22ac34c87

podium.xml

 

Object 'HD - Red Walnut Office Chair - OFF7': da551ef2-7093-eb28-2431-66df21f6f799

red-walnut-office-chair.xml

 

Object 'Stone Fireplace': 3c071c30-1352-76b0-035c-761253d0e767

stone-fireplace.xml

 

Object 'stage floor': a63b65b1-a0c7-8286-fdc7-a9f1fb11cf52

stage-floor.xml

 

Object 'Video Wall': b8077147-f01b-d857-ec09-606b347f375e

video-wall.xml

 

Object 'midibox': 32a53e3e-2a35-7fa2-8d85-0cfd9235511a

midi-box.xml

 

Object 'Pink/Purple Flower Arrangement': b0deefa1-067d-1d0c-cb69-51f07076ec6b

pink-purple-flower-arrangement.xml

 

Object 'arabic tray table': 665ea3c7-847a-0d4d-a6ed-07132b4c916a

arabic-tray-table.xml

 

? Object 'midibox': 43f21320-aea2-2bae-8093-1517bbe9bf83

? Object 'midibox': 102e4b74-8bb4-96be-62f1-1ef4589c51f4

? Object 'midibox': 895edbe3-de21-9c90-b3de-46c2e182bc04

 

 

Stage 05

 

Object 'office desk black, shadow left': a4a8e941-201b-97b6-b3ce-ee296a34d36c

office-desk-black.xml

 

Object 'desk lamp 1.1 touch on/off': 4da78f89-bdc5-614c-4692-98d49b2a6f5a

desk-lamp.xml

 

Object 'guest chair': 405b5bbf-c678-0d40-eeac-0d66bd789245

guest-chair.xml

 

Object 'cabinet dark': 9e2ddb7b-b87a-e08b-56cd-06eefe30aaf4

cabinet-dark.xml

 

Object 'ring binder/Ordner': d3120ff6-8683-5354-e6ee-15e8c2ee5a4b

ring-binder-ordner.xml

 

Object 'AC-POTBWFlowerPLT': eeb9c072-2b75-b7d0-d34f-45562ef59d7f

ac-potbwflower.xml

 

Object 'Object': e8eeb948-7a7f-1431-7a20-a491cdb75140

object1.xml (chair)

 

Object 'Object': ee5ad01a-7a48-5302-760f-ad967f2ef38c

object2.xml (wall; 23 prim, 1 texture)

 

Object 'Focus drawer unit dark': b9279e4a-d7ae-08a0-f151-9d5402098d84

focus-drawer.xml

 

Object 'midibox': ba375fb7-f7fa-f14a-8ab2-596ff2d16205

midi-box.xml

 

Object 'midibox': a44b81d3-8cd8-1beb-28cb-7545e5349aef

midibox2.xml

 

Object 'midibox': ab789ce4-1ddd-983e-5dba-545bd8d10483

midibox3.xml

 

Object 'midibox': 92941864-d01c-415a-732f-96cad622990b

midibox4.xml

 

Object 'stage floor': 485b6a1f-6e08-1319-b4aa-a731de53f5dd

stage-floor.xml

 

 

Stage 06

 

empty

 

 

Appendix 3: XML format examples of exported objects

 

Example One

 

Object: a single cube with a texture

Number of prims: 1

Number of textures: 1

Size: 0.5 x 0.5 x 0.5

 

 

 

 

XML Code:

 

<?xml version="1.0" encoding="UTF-8"?>

<llsd>

<map>

<key>189593013</key>

<map>

<key>name</key>

<string>Cube</string>

<key>description</key>

<string/>

<key>phantom</key>

<boolean>0</boolean>

<key>physical</key>

<boolean>0</boolean>

<key>position</key>

<array>

<real>83.084358215332031</real>

<real>152</real>

<real>107.68852996826172</real>

</array>

<key>rotation</key>

<array>

<real>0</real>

<real>0</real>

<real>0</real>

<real>1</real>

</array>

<key>scale</key>

<array>

<real>0.5</real>

<real>0.5</real>

<real>0.5</real>

</array>

<key>material</key>

<integer>3</integer>

<key>shadows</key>

<boolean>0</boolean>

<key>textures</key>

<array>

<map>

<key>colors</key>

<array>

<real>1</real>

<real>1</real>

<real>1</real>

<real>1</real>

</array>

<key>scales</key>

<real>1</real>

<key>scalet</key>

<real>1</real>

<key>offsets</key>

<real>0</real>

<key>offsett</key>

<real>0</real>

<key>imagerot</key>

<real>0</real>

<key>bump</key>

<integer>0</integer>

<key>shiny</key>

<integer>0</integer>

<key>fullbright</key>

<boolean>0</boolean>

<key>media_flags</key>

<integer>0</integer>

<key>mapping</key>

<integer>0</integer>

<key>glow</key>

<real>0</real>

<key>imageid</key>

<uuid>46f8901a-d9f8-9c80-9037-d08434ac0c37</uuid>

</map>

</array>

<key>volume</key>

<map>

<key>path</key>

<map>

<key>begin</key>

<real>0</real>

<key>curve</key>

<integer>16</integer>

<key>end</key>

<real>1</real>

<key>radius_offset</key>

<real>0</real>

<key>revolutions</key>

<real>1</real>

<key>scale_x</key>

<real>1</real>

<key>scale_y</key>

<real>1</real>

<key>shear_x</key>

<real>0</real>

<key>shear_y</key>

<real>0</real>

<key>skew</key>

<real>0</real>

<key>taper_x</key>

<real>0</real>

<key>taper_y</key>

<real>0</real>

<key>twist</key>

<real>0</real>

<key>twist_begin</key>

<real>0</real>

</map>

<key>profile</key>

<map>

<key>begin</key>

<real>0</real>

<key>curve</key>

<integer>1</integer>

<key>hole</key>

<integer>0</integer>

<key>end</key>

<real>1</real>

<key>hollow</key>

<real>0</real>

</map>

</map>

</map>

</map>

</llsd>

 

Example Two

 

Object: a cylinder with a hemisphere on the top, both have the same texture

Number of prims: 2

Number of textures: 1

Size: 0.5 x 0.5 x 0.75

 

 

 

 

XML Code:

 

<?xml version="1.0" encoding="UTF-8"?>

<llsd>

<map>

<key>189594468</key>

<map>

<key>name</key>

<string>cylinder-hemisphere</string>

<key>description</key>

<string/>

<key>phantom</key>

<boolean>0</boolean>

<key>physical</key>

<boolean>0</boolean>

<key>position</key>

<array>

<real>81.816207885742188</real>

<real>151.30220031738281</real>

<real>107.76540374755859</real>

</array>

<key>rotation</key>

<array>

<real>0</real>

<real>0</real>

<real>0</real>

<real>1</real>

</array>

<key>scale</key>

<array>

<real>0.5</real>

<real>0.5</real>

<real>0.2496337890625</real>

</array>

<key>material</key>

<integer>3</integer>

<key>shadows</key>

<boolean>0</boolean>

<key>textures</key>

<array>

<map>

<key>colors</key>

<array>

<real>1</real>

<real>1</real>

<real>1</real>

<real>1</real>

</array>

<key>scales</key>

<real>1</real>

<key>scalet</key>

<real>1</real>

<key>offsets</key>

<real>0</real>

<key>offsett</key>

<real>0</real>

<key>imagerot</key>

<real>0</real>

<key>bump</key>

<integer>0</integer>

<key>shiny</key>

<integer>0</integer>

<key>fullbright</key>

<boolean>0</boolean>

<key>media_flags</key>

<integer>0</integer>

<key>mapping</key>

<integer>0</integer>

<key>glow</key>

<real>0</real>

<key>imageid</key>

<uuid>ad05b4f7-9bf9-f363-e48e-87484aea97ea</uuid>

</map>

</array>

<key>volume</key>

<map>

<key>path</key>

<map>

<key>begin</key>

<real>0</real>

<key>curve</key>

<integer>16</integer>

<key>end</key>

<real>1</real>

<key>radius_offset</key>

<real>0</real>

<key>revolutions</key>

<real>1</real>

<key>scale_x</key>

<real>1</real>

<key>scale_y</key>

<real>1</real>

<key>shear_x</key>

<real>0</real>

<key>shear_y</key>

<real>0</real>

<key>skew</key>

<real>0</real>

<key>taper_x</key>

<real>0</real>

<key>taper_y</key>

<real>0</real>

<key>twist</key>

<real>0</real>

<key>twist_begin</key>

<real>0</real>

</map>

<key>profile</key>

<map>

<key>begin</key>

<real>0</real>

<key>curve</key>

<integer>0</integer>

<key>hole</key>

<integer>0</integer>

<key>end</key>

<real>1</real>

<key>hollow</key>

<real>0</real>

</map>

</map>

</map>

<key>189594676</key>

<map>

<key>name</key>

<string>Object</string>

<key>description</key>

<string/>

<key>phantom</key>

<boolean>0</boolean>

<key>physical</key>

<boolean>0</boolean>

<key>position</key>

<array>

<real>0</real>

<real>0</real>

<real>0.1227569580078125</real>

</array>

<key>rotation</key>

<array>

<real>0</real>

<real>0</real>

<real>0</real>

<real>1</real>

</array>

<key>scale</key>

<array>

<real>0.5</real>

<real>0.5</real>

<real>0.5</real>

</array>

<key>material</key>

<integer>3</integer>

<key>shadows</key>

<boolean>0</boolean>

<key>textures</key>

<array>

<map>

<key>colors</key>

<array>

<real>1</real>

<real>1</real>

<real>1</real>

<real>1</real>

</array>

<key>scales</key>

<real>1</real>

<key>scalet</key>

<real>1</real>

<key>offsets</key>

<real>0</real>

<key>offsett</key>

<real>0</real>

<key>imagerot</key>

<real>0</real>

<key>bump</key>

<integer>0</integer>

<key>shiny</key>

<integer>0</integer>

<key>fullbright</key>

<boolean>0</boolean>

<key>media_flags</key>

<integer>0</integer>

<key>mapping</key>

<integer>0</integer>

<key>glow</key>

<real>0</real>

<key>imageid</key>

<uuid>ad05b4f7-9bf9-f363-e48e-87484aea97ea</uuid>

</map>

</array>

<key>volume</key>

<map>

<key>path</key>

<map>

<key>begin</key>

<real>0</real>

<key>curve</key>

<integer>32</integer>

<key>end</key>

<real>0.5</real>

<key>radius_offset</key>

<real>0</real>

<key>revolutions</key>

<real>1</real>

<key>scale_x</key>

<real>1</real>

<key>scale_y</key>

<real>1</real>

<key>shear_x</key>

<real>0</real>

<key>shear_y</key>

<real>0</real>

<key>skew</key>

<real>0</real>

<key>taper_x</key>

<real>0</real>

<key>taper_y</key>

<real>0</real>

<key>twist</key>

<real>0</real>

<key>twist_begin</key>

<real>0</real>

</map>

<key>profile</key>

<map>

<key>begin</key>

<real>0</real>

<key>curve</key>

<integer>5</integer>

<key>hole</key>

<integer>0</integer>

<key>end</key>

<real>1</real>

<key>hollow</key>

<real>0</real>

</map>

</map>

<key>parentid</key>

<integer>189594468</integer>

</map>

</map>

</llsd>

 

 

LL-Scripts

 

stage controler script

 

/////////////////////////////////////////////////////////////////

//// Stage Controller for Demonstration c  by Trigit Amat ///////

/////             Workshop                    ///////////////////

/////////////////////////////////////////////////////////////////

string Button1 = "button 1"; // change the names of the buttons by changing the name between quotation marks

string Button2 = "button 2";

string Button3 = "button 3";

string Button4 = "button 4";

string Button5 = "button 5";

string Button6 = "button 6";

string Button7 = "button 7";

string Button8 = "button 8";

string Button9 = "button 9";

string Button10 = "button 10";

string Button11 = "button 11";

string Button12 = "button 12";

 

 

//////////////// variable für timer Time

integer g_TimerTime;

integer g_TIMERTIME = 1800; //timerTime for non DiscoTime

 

integer CHANNEL = 42; // dialog channel

list MENU_MAIN = [Button1 , Button2, Button3 , Button4, Button5, Button6 , Button7 , Button8 , Button9 , Button10 , Button11  ,"Clear Stage" ]; // the main menu

list MENU_SCENARIOS = ["Transparent", "Sky" , "Green Golf"];

default {

    state_entry() {

        llSetText ("Stage Controller" ,<1,1,1>,1);

        llListen(CHANNEL, "", NULL_KEY, ""); // listen for dialog answers (from multiple users)

    }

 

    touch_start(integer total_number)

    {

        llDialog(llDetectedKey(0), "What do you want to do?", MENU_MAIN, CHANNEL); //

    }

 

    listen(integer channel, string name, key id, string message)

    {

        if (llListFindList(MENU_MAIN + MENU_SCENARIOS, [message]) != -1)  // verify dialog choice

        {

            llSay(0, name + " picked  '" + message + "'."); // output the answer

            if (message == ">SCENARIOS<")

                llDialog(id, "Pick an option!",MENU_SCENARIOS, CHANNEL); // present submenu on request

            else if (message == "...Back")

                llDialog(id, "What do you want to do?", MENU_MAIN, CHANNEL);

 

////////////////////////////////    add your scenarios here ///////////////////////

/// your line should look like this: llSay (47 , "rezzOnStage <At the beach bodengelaender>  <5.20830, 5.10938, 1.01517> <0.00000, 0.00000, -0.70711, 0.70711>");

 

            if (message == Button1 )

             {

                llSay (47, "clearStage");

 

                llSleep (1);

                // add your rez lines for the specified button here

                // example : llSay (47 , "rezzOnStage <Medical Practice>  <1.82724, -1.31761, 0.21074> <0.00000, 0.00000, 0.70711, 0.70711>");

 

            }

             if (message == Button2)

             {

                llSay (47, "clearStage");

 

                llSleep (1);

                // add your rez lines for the specified button here

                // example : llSay (47 , "rezzOnStage <Medical Practice>  <1.82724, -1.31761, 0.21074> <0.00000, 0.00000, 0.70711, 0.70711>");

 

              }

              if (message == Button3)

              {

                  llSay (47, "clearStage");

                  llSleep (1);

                  // add your rez lines for the specified button here

              }

              if (message == Button4)

              {

                  llSay (47, "clearStage");

                  llSleep (1);

                  // add your rez lines for the specified button here

              }

              if (message == Button5)

              {

                  llSay (47, "clearStage");

                  llSleep (1);

                  // add your rez lines for the specified button here

              }

              if (message == Button6)

              {

                  llSay (47, "clearStage");

                  llSleep (1);

                  // add your rez lines for the specified button here

              }

              if (message == Button7)

              {

                  llSay (47, "clearStage");

                  llSleep (1);

                  // add your rez lines for the specified button here

              }

              if (message == Button8)

              {

                  llSay (47, "clearStage");

                  llSleep (1);

                  // add your rez lines for the specified button here

              }

              if (message == Button9)

              {

                  llSay (47, "clearStage");

                  llSleep (1);

                  // add your rez lines for the specified button here

              }

              if (message == Button10)

              {

                  llSay (47, "clearStage");

                  llSleep (1);

                  // add your rez lines for the specified button here

              }

              if (message == Button11)

              {

                  llSay (47, "clearStage");

                  llSleep (1);

                  // add your rez lines for the specified button here

              }

 

 

              if (message == "Clear Stage")

                {

                    llShout (102938 , "Clear all 102938");

                    llSay (47, "clearStage");

 

                }

 

        }

 

     }

 

}

 

 

 

Comments (2)

klaus said

at 1:15 pm on Nov 2, 2010

This document is complete and a release candidate
Spellcheck and QA is appreciated

klaus said

at 12:19 pm on Jan 7, 2011

I have put this deliverable as a PDF in the repository and linked it to our official homepage, if there are final adjustments, please notify me that I can update the release.

You don't have permission to comment on this page.

Printable version