Second Life: A Guide to Your Virtual World
When I started my first SL project, my wife grabbed a couple SL books from the library where she works. The first was Second Life For Dummies
The second was Second Life: A Guide to Your Virtual World
SL Persistent Data Storage
The storage of persistent data appears to be quite a hot topic in the Second Life scripting community. I can certainly understand why. There are three options for storing data persistently in SL and each has a significant limitation.
- Object names and descriptions offer a location to read and write dynamic values, so long as they are short. Names are limited to 63 characters and descriptions to 127 characters. I’ve used the description field to store single values as well as short lists of values to parse in script.
- Notecards are a popular way to store configuration values for scripts. Packaging a no modify script with a modifiable notecard, allows sellers to offer scripts that are configurable without giving the source code away. However, notecards are read-only.
- Scripts can pass data to each other, allowing for scripts designed solely to store data while other scripts are reset. However, even these scripts will loose data when the sim is restarted.
Linden Labs has indicated that they are not pursuing a solution, at least not before the release of Mono, the upcoming scripting language for SL with increased speed and stability. There are third-party solutions, but privacy and reliability would be big concerns. There are scripts available to setup your own external storage via PHP. This requires a hosting solutions outside of SL, an additional cost for many SL residents.
In the mean time, it seems like the best compromise would be an API that utilizes a reliable third party provider of storage. For example, an open source API created with Google App Engine would allow each scripter to easily setup their own private storage. hmmm
SL Teleport
The lack of a sound teleport function in Second Life has become a major frustration. I wrote a basic teleport script using the llSitTarget() hack. This worked well for short range distances, say anything under about 50 meters. However, when I implemented this over longer ranges of about 100m, some strange side-effects started to appear. The teleporting avatar would appear underground by more than 70m or off the sim by more than 100m. After 3-5 seconds, the avatar would snap to the correct position. This would certainly be confusing the many users.
On some teleports, the camera would start moving from the source to the destination, but stop mid-way, even though the avatar completed the trip. Using the moving keys would snap the camera to the correct position behind the avatar, but still not a good user experience.
Don’t even get me started on dealing with rotations in the llSitTarget() function. I could certainly be implementing them wrong, I’ve gotten some to work properly, but most do not. It seems to depend a great deal on the local rotation of the object. I’ve even had some chairs where two of the vector floats controlled the same axis! This limited me to rotating a sit target in two dimensions. I could rotate left-to-right and side-to-side, but not front-to-back.
I also tried implementing the popular warpPos function, which sits the avatar on a prim, moves the prim in 10m increments to the destination and then unsits the avatar. This worked, but exhibited the same unusual side-effects.
I also tested a number of commercial teleport solutions and they all exhibit the same side-effects.
Of course, llMapDestination() is the official method for teleporting. However, this simply brings up the full map with the target destination highlighted. The user is required to click the Teleport button among a sea of options. The map is a powerful tool, but completely overkill when you simply want to teleport to a specified destination.
A simple function would address all of these issues:
llTeleportAgent(vector targetLocation, float targetCompassFacingInDegrees, integer showMap)
I know there are security concerns that need to be addressed, but it’s hard to imagine creating mass-appeal for this environment when such basic issues persist.
SL LSL Wish List
The lack of any type of error handling in Linden Scripting Language (lsl) is a bit frustrating. This could be addressed with the addition of a try/catch or an error event.
Type checking would also be nice. This could either be done with individual functions, such as llIsInteger(), llIsVector(), etc. Or a single function could return the type of a variable, such as llGetVariableType(string variableName).
SL Updating Scripts
When I started scripting in Second Life, I quickly realized that I would have many dozens of objects that used the same script. This script would need to be updated in all of those objects repeatedly, not something I was looking forward to doing manually. While it would be ideal if multiple objects could reference the same script from a single location, that option is not available.
The next best option was to push the updated script from a central script server object to the client objects. A single script could handle serving the script using llRemoteLoadScriptPin(). This function pushes the specified script to an object with a specified key. If all of the objects that needed the script had the same name, then the central script could query those objects by name and create a list of their keys.
Not so fast. There is no function to return a list of object keys based on name or any other criteria aside from linkage. Due to the distances involved, linking was not an option. I certainly didn’t want to maintain a list of keys for the objects manually. And of course, the client object getting the script would need to have a matching pin number set for llRemoteLoadScriptPin() to work. Both of these issues meant that a client script was also required.
It’s easy enough to set the pin in the client script using llSetRemoteAccessPin(). However, how would the server script get the key of the client object? The client script needs to provide it. Not unlike an HTTP or FTP request, the client would need to request the script via chat and the server object, listening for the request, could provide the requested script back to the requesting object.
This created another issue: How is the client request initiated for each of dozens of objects? I added a listener to the client script that would listen for a specific chat command from my avatar on a private channel. This way, I could update objects within 20 meters via chat or objects up to 100 meters away via shout. This system has worked fairly well and only requires about 3 shouts to update the client scripts scattered across an entire region.
I also considered creating a single point of activation at the server. This could be done by adding another listener to the server which would broadcast an update request region-wide, prompting all of the clients in the region to request an update.
- Avatar to Server: hey server, broadcast update request to region
- Server to Region: if you can hear me, it’s time to update
- Client to Server: hey server, please send me this script
- Server to Client: sends script
I didn’t have the need to implement this by the end of this project, but may do so right at the beginning of my next SL project.
I have also added code to each script that queries the object name and prevents of the script from running if it’s located on the script server. This will avoid potentially wacky behavior that might result from various scripts running on the server.
SL Rotations
I recently completed the construction of a transportation system within an island of Second Life. This included a vehicle which needed to operate along a generally fixed but not exact path. Instead of putting the vehicle on some type of an rail, I placed the vehicle in the space, pointed it in a particular direction and let it go. I lined the space with invisible bumpers. When the vehicle collides with the invisible bumpers, it changes direction. This would allow the vehicle paths to vary slightly on each pass. I discussed the communication issues in Second Life Phantom Collisions.
I encountered a very complex subject in SL: rotations. Since the vehicles needed to point in a particular compass direction at start and on collision, I would need to know the direction for each of these cases. This required determining the compass direction in an easy to read number from 0 to 359 degrees. This number was then converted to a vector (<x, y, z>), where x and y are both 0 and the degrees assume the z value (<0.0, 0.0, direction>). This vector was then converted from degrees to radians and then to a rotation. This was fairly easy to piece together using examples from the various LSL wikis (lslwiki.net and wiki.secondlife.com). However, as is with SL, there are always a few undocumented catches.
First, the degrees value is not what you might think. I would expect 0 degrees to represent North and proceed clockwise around the compass. I could also see the values starting at East and progressing clockwise. Neither was the case, 0 starts at East and proceeds counter-clockwise around the compass: 90 degrees is North, 180 degrees is West, 270 degrees is South, etc.
It was much too inaccurate to guess the degree values based on the compass headings in the mini-map, so I built a HUD to display an exact value based on the facing of my avatar. This way, I could point my avatar, read the value and plug it into the object needing a direction. After a series of tests, it became clear that the HUD was inaccurate anywhere between 1 and 9 degrees. After some trial and error, I switched from the rotation of the avatar with llGetRootRotation() to the rotation of the camera with llGetCameraRot(). This produced an accurate result.
To summarize, the HUD would convert the rotation of the camera to a human-friendly direction in degrees and the objects could convert that direction back to a SL-friendly rotation.
The HUD simply consisted of floating text on an invisible prim. I had originally attached this to my head, which worked but lead to my fellow developers wondering why I had text floating above my head all the time. n00b! Instead, I attached the prim directly to my HUD, so that only I would see it. My first HUD attachment.
I’ve also been attempting to convert local rotations to global rotations and then modify those further based on a particular direction, but this has proved extremely challenging and beyond the scope of any SL rotation documentation that I have found. According to the documentation, it should be possible, I just haven’t figured it out yet.
Second Life Sound Issues
I’ve encountered an interesting limitation with sound in Second Life. You can only play a single sound from each script at any given time. If you have a script where you’d like to play a looping background sound and then play separate sounds based on events, you can’t. You are limited to a single sound playing at one time for each script. You can define whether additional sounds should cut-off and replace the current sound or should be queued to play after the current sound, but it’s only one at a time.Why the limitation? I could see limiting to 16, 8, or even 4 simultaneous sounds per script. If the concern is flooding the client with sounds, then that could be addressed by defining an overall limitation in the client, which I would hope exists already. This limitation simply forces anyone wishing to create a sound rich environment to create additional scripts for each sound. Inefficient.
Also, why are their separate functions for llPlaySound() and llLoopSound()? These should be a single function with an addition boolean parameter to define whether the clip loops. The same applies to llTriggerSound(). A boolean parameter defines whether the sound follows the prim it’s attached to or remains at the location it was created at. The new function could look like this, with the two new parameters (loop and follow) being optional and defaulting to false for backward compatibility.
llPlaySound(string sound, float volume, integer loop, integer follow)
Second Life Simple Data Storage
In creating scripts for Second Life, I’ve tried to keep the scripts as portable and re-usable as possible. At the most basic level, this means creating a separation of code and data. For scripts that are used in a limited number of prims, this can be as simple as setting customizable variables at the top of the script. For scripts that are going to be used in many prims, this system requires maintaining a unique copy of each script in each prim. If your base script is updated to fix a bug or add a feature, you’ll need to update each script by hand or overwrite the script in prim and reset the custom variables. Both options are prone to error.
For scripts used in many prims, storing the data for those variables in the prim’s description field can be an effective solution. This allows you to replace the script without impacting the custom data in each prim. The description field is limited to 127 characters, so this method is only useful with short length data. Also, since the description field can be publicly viewed in prim properties, this method should not be used to store private or sensitive data. On the plus side, this data can be updated dynamically using llSetObjectDesc().
When storing the value of a single variable in the description field, use this code to retrieve the value. If the type is anything other than a string, simply prefix the function with the data type. In this case, the variable type is a vector.
vector myVector; //declare variable type
myVector = (vector)llGetObjectDesc(); //read the description, a string by default, and convert to a vector
If you need to store multiple values, format the data in the description field as a list, such as “Someplace;<72,89,25>”, read the data and parse it. This example uses the semi-colon as a delimiter.
list description;
string locationName;
vector locationTarget;
description = llParseString2List(llGetObjectDesc(), [";"], [""] );
locationName = llList2String(description, 0);
locationTarget = (vector)llList2String(description, 1);
I have found this method to be very effective and efficient for scripts that contain a limited amount of custom data. To store larger amounts of data, you’ll need to use a notecard or data store external to the prim.
-
My ET:QW Stats
