My last post was all about Second Life's Linden Scriptng Language (LSL) and how to add LSL scripts to our objects. We built a simple elevating platform that moved along the z-axis when touched by an avatar. This week I will continue building on this example, introducing new LSL concepts along the way.
Inter-Object Communication
Currently, our elevator starts moving after being touched by an avatar but this is not very realistic. Most elevators move when someone presses a call button and I want to replicate this behavior on my virtual counterpart. The first thing I need is a call button. Since the aim of this blog is to demonstrate LSL rather than creating beautifully crafted objects a simple prim will do as a call button. I need to add a script to my call button to notify my elevator that it should start moving. One way of doing this is to broadcast a message over a specific channel and set the elevator to listen to messages coming from that channel. Here's the button's script:
default { state_entry() { } touch_start(integer total_number) { llSay (1360, "elev-mov"); } }
Pretty simple. All the script does is broadcast the "elev-mov" message over channel 1360 whenever the object is touched. We now need to configure our elevator to listen for this message:
default { state_entry() { llListen(1360, "es1",NULL_KEY, ""); ... ... ... } listen(integer channel, string name, key id, string message) { if (channel == 1360 && name="es1" && message == "elev-mov") { state moving; } }
The first line in the state_entry script for the default state sets the object to listen to any messages coming in on channel 1360 from an object named "es1" ("es1" is the name I gave the call button). I could also configure the object to listen for messages coming from another object that has a specific Universally Unique Identifier (UUID)but I must admit I haven't yet found a way to do this reliably. Our elevator is now set to listen for messages coming from the call button. We now need to take action on those messages. To do this we add a 'listen' event to our default state script and add the required code. In this case the elevator checks the channel (1360), source (call button) and message and starts moving. You might notice that using this technique, your object could be configured to listen for messaged from multiple objects over multiple channels and react accordingly. I'm not too sure about performance though.
Linking Objects
So now we have a platform that moves when the call button is 'pressed', but it's only a platform. What if we wanted to add 'walls' to this platform to make it look more like an actual elevator. Simply placing these walls on top of the platform will not make them move with it when the call button is pressed! Here's where linking objects comes in handy. To link the walls to the floor hold down the shift key and click on the walls and floor in succession to select all the objects. It is important to select the floor last and I will explain why in a minute. After selecting all the objects click the 'Link' button in the "Build Toolbox" to link the objects together. Now when the call button is pressed, the walls will move together with the platform for a more realistic looking elevator. This will not work unless the floor was selected last when linking the objects because the floor's script would not be set as the parent script of the group.