multiple listeners and rigging a script
Found another problem with the TouchMeObject script (wrote about it in last post). New, improved version is posted (same URL). The problem was of my own making, a result of trying to avoid having multiple listeners created. I hope this update finds anyone that might have used the earlier version.
A listener creates a significant load in a simulator, enough to warrant caution in their creation. So, it is best practice to avoid having static (persistent) listeners in a simulator if users are not interacting with the object.
In preparing the TouchMeObject, I hastily threw in a “BUSY” variable (BOOLEAN) to clamp down listener creation while the object attended to a user (make second, third users wait ’til first user is done). But, I FAILED to provide any response to the next user to touch the object.
(This could be tested by two users, or one user with an alt. Touch object with first avatar, then touch with second user before the first responds to their Dialog prompt. The object does not respond.)
The problem in the first TouchMeObject script is obvious now, one I should have noticed; had just never gone the “BUSY” route before. My old, lazy approach has typically been to create a listener, wait for X seconds of inactivity, and then remove the listener.
Not having looked at this “concurrency” issue in a while, at least as it relates to use of the llDialog function, I had a look around. Seems that how best to deal with multiple listeners is still a matter of discussion…and by much more advanced scripters*.
Still, the digging paid off: I noticed that the SL Wiki page for the llListen function states:
“…handles are assigned sequentially starting at 1”
Light bulb attachment flickers, and an old lazy approach is upgraded to a newer lazy approach. Now, we’ll create a listener only if we have ZERO stored as the EARS_OPEN handle (integer variable, now acting as BOOLEAN). (Just have to remember to set it to ZERO everywhere that counts.)
But wait! What if a user touches the object and gets the dialog prompt, then gets distracted by cute kitty pictures in a browser, and returns to the dialog prompt in (X + 1) seconds?
Answer: No joy.
It aint elegant. It’s not even satisfying; and, it has its problems. But…
It’s something I can live with.
*UPDATE* (added single line to clear any float text if not assigned)
if (DISPLAY_FLOATING_TEXT) llSetText( llGetObjectName(), FLOAT_TEXT_COLOR, 1.0 );
else llSetText( “”, FLOAT_TEXT_COLOR, 1.0 );
//SEE WHAT’S BEEN ADDED TO CONTENTS
* To read some of the various issues related to the use of listeners, see:
- Caveats section of this SL Wiki page
- The many comments regarding “Concurreny issue” [sic] and multiple dialogs in this llDialog talk page