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.
Second Life Phantom Collisions
I’ve been given the opportunity to do some coding for Second Life. Before I started, I was presented with a number of horror stories about the Linden Scripting Language (LSL). While it’s not as bad as a thought it might be, there are certainly some oddities, some due to the language itself and some due to seemingly arbitrary limitations of the environment.
The first major issue that I ran into involved the detection of collisions with phantom prims. The project was a guided transportation system in which a vehicle would be provided a direction (vector) based on hidden prims that it collided with in the environment. The hidden prims providing the direction are transparent, so they cannot be seen in the environment. They are also phantom, since we didn’t want avatars blocked by invisible objects and becoming confused. However, no collision events (collision nor collision_start) are triggered in the vehicle. In this case, I’m using a vehicle, but the same applies to any prim or set of linked prims. By default, collisions with phantom objects are not detected by either object. Collisions can be detected by the phantom object with the inclusion of this function.
llVolumeDetect(TRUE);
However, this only allows collisions to be detected by the phantom prim and not by the vehicle that needs the information. The non-phantom prim will not detect collisions with phantom prims under any conditions. This meant that the vehicle pulling the new direction from the phantom prim was out of the question. Since the phantom prim could detect the collision, it must be the one to act.
collision_start(integer total_number)
{
llWhisper(channelNumber, message);
}
At the start of the collision, the phantom prim broadcasts the message on a non-0 channel. Using a non-0 channels helps to cut down on chat spam. In this case, I also used llWhisper, since the listening vehicle is moving slowly and will certainly be within 10 meters. llSay sends the message 20 meters, where it might be picked up by more vehicles.
In order to keep the chat to a minimum and ensure that only the vehicle involved in the collision acted upon the message, there are a number of other techniques used as well. The colliding objects all have the same name, so I can use a collision filter to ensure that only collisions with specifically named prims are detected.
llCollisionFilter(vehiclePrimName, NULL_KEY, TRUE);
While the collision event is fired continuously during the collision between two prims, the collision_start event is supposedly only fired once at the beginning of the collision. That certainly doesn’t appear to be the case, since collision_start is being fired multiples times as well. In order to limit this to a single event, get the key of the colliding object and only fire the event of the key is different from the last key. I also set a timer to clear the last key, so that future collisions with the same object will be effective, after 15 seconds in this case.
collision_start(integer total_number)
{
currentKey = llDetectedKey(0);
if ( currentKey != lastKey )
{
llWhisper(chatChannel, (string)currentKey + ";" + message);
lastKey = currentKey;
llSetTimerEvent(15);
}
}
timer()
{
lastKey = NULL_KEY;
llSetTimerEvent(0);
}
On collision with a specifically named prim if there was no collision with that prim in the last 15 seconds, the message is whispered on a non-0 channel. Of course, you will need to ensure that the vehicle is listening for the message on the same channel. I also pass the key of the colliding object, so that any object receiving the message can validate the message was intended for it.
This solution is a bit of a kludge, but it produces the desired result.
ET:QW Widget v1.1
I have released an update to the Enemy Territory: Quake Wars widget.
Here are the updates:
- Fixed timer refresh
- Fixed rounding error on next predicted task percentage, tasks that were greater than 99.5% complete but less then 100% complete were displaying as 100% complete
- Simplified updated since display for times under 1 hour
My ET:QW Stats
