This last week has seen me busy commencing the MA Education in Virtual Worlds so very little time to spare for posting. In fact a little over-whelmed by what I have taken on though I will no doubt settle into the flow of things as the weeks progress. Posts will be fewer and farther between during this time but my goal is to get one out a fortnight if I can manage. We’ll see.
This particular post comes from the workshop where I have been fiddling of late with the new llTeleportAgent function (see Linden Labs’ post). This function can teleport a user to a destination within a sim, using either a landmark or a location defined by a vector position on the sim grid, i.e. <X, Y, Z>. The user is turned to face in a particular direction at the destination, i.e. looking towards a spot, again defined by a vector. The function parameters are as follows:
llTeleportAgent(key avatar, string landmark, vector position, vector look_at)
I had seen examples of its use in sim navigation HUDs and decided to play with the function a little to investigate its possibilities. In the process I ended up creating a simple tour guide. The following video shows the result and the commentary after gives a general overview of how it is put together.
The HUD uses one large texture of 1024 x 1024 pixels (shown below) and is scripted with 0.25 horizontal and vertical repeats and various horizontal and vertical offsets to display each 256 x 256 scene.
Currently there are four different beginning images, eleven destination scenes and one image for the minimised display. I had considered using individual images but decided that the user would more than likely scroll through almost all the scenes in a session so the one download means each scene image change will be instant once the initial download has occurred. The beginning image is selected at random from the four available when the HUD is first worn to add variety to the inital rezzing of the HUD. Three of these however, could be changed to destination scenes if more need to be added.
When touching the HUD the current region is checked first up, using an IF statement containing the function llGetRegionName. If the user is in the correct sim the touch_start event will instead trigger the llRequestPermissions function, requesting the permission PERMISSION_TELEPORT which the user must accept if the HUD is to teleport them. This user agreement to the teleporting helps prevents misuse of the llTeleportAgent function. The user must also own the object the function is scripted into, this being another level of security to prevent misuse.
From the point that the permission is given, the touch_start event then uses the llDetectedTouchST function to determine where a user has touched the HUD, allowing different points of touch to exhibit different behaviour, i.e. the arrows to move through the destination scenes, the minimise icon to minimise the HUD and anywhere else to teleport the user to the currently shown destination. Even though there is only one prim involved I have used the function llSetLinkPrimitiveParamsFast to change the scenes rather than llSetPrimitiveParams, which has a 0.2 second built in sleep script. The prim is targeted using the link number 0 when the prim is unlinked.
In its design I wanted the HUD to be as strong aesthetically as the sim it portrays and to well display the destinations. The sim in many ways has been designed with vignettes that capture moments of the Second Life day and night there, so it was important to use the HUD to portray some of those moments. The images are bevelled and shadowed to produce a 3D effect, which I think lends it a softer and more natural feel, also in keeping with the sim.
In testing the llTeleportAgent function I found the use of a landmark to be quicker than a position vector in terms of the visual change of the surroundings to the new destination. This is possibly because the function checks for the landmark parameter first then if there is none moves to the position, so it just takes longer.
I use lists to hold the landmarks and the concurrent look_at positions and use llList2String and llList2Vector respectively to provide those parameter values to the llTeleportAgent function. It could prove faster to use variables and have those two list functions find the values when the destination scene is changed rather than waiting for the touch that triggers the teleport. I also find at times, usually on the first teleport after the HUD is worn, that the look_at isn’t well enacted. It just may be that holding the values in a variable will fix that issue too.
A copy of the HUD can be found at this destination. Have a wee play with it and enjoy!
Note: osTeleportOwner should be capable of performing the teleport in OpenSim but I haven’t tested it and I’m unsure of the levels of permissions offered in using this function in OpenSim.