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 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.
-
My ET:QW Stats
