[Weighted random number generator]

No clue how the odds would turn out, but generate two numbers and use the lower.

float a = llFrand(119.0);
float b = llFrand(119.0);
integer result;
 if (a < b) result = llCeil(a);else result = llCeil(b);

 Seems that would produce a bell curve of results targetted toward the lower end, instead of an even spread. Another option is to use a random number in the generator.

integer result = llCeil(llFrand(llFrand(118.0)));

 Seems that would produce a more linear spread, but no clue about the odds again.

[loop a sound while typing]

Run a timer that uses llGetAgentInfo() to test if you're typing.

timer() {   if (llGetAgentInfo() & AGENT_TYPING) llLoopSound("beatbox", 0.2);
   else llStopSound();}

[The KEY to Avatars]

Awesome, more new functions. Maybe once I finally finish Skyrim, SpaceChem and a few other games that Steam sucked me into, I'll head back to SL and play with all the fancy new functions... barring more Steam sales.

Ah, so the copilot sits on a vehicle seat, and you use whichever method works to send the copilot avatar UUID to an object attached to your avatar. That object needs to receive commands from both your HUD and the HUD worn by the copilot.

All that's left to do is test if the hud owner is equal to either you OR the copilot. Assuming you've stored the copilot's UUID in a global variable, try this in your listen event:

key hudOwner = llGetOwnerKey(id);

if ((hudOwner == llGetOwner()) || (hudOwner == copilot)) {

//process command

}

[The KEY to Avatars]

One way is to listen to the other seat and have it communicate its sitter.

Example:

1) The pilot's HUD has two listens, one with the KEY filtered to the pilot's UUID, and a second with the NAME filtered to the pilot's UUID.

2) Pilot sits. The pilot seat (named "pilot") grabs the pilot's UUID via llAvatarOnSitTarget(), whispers the UUID, then sends it to the co-pilot seat via llMessageLinked().

3) The co-pilot seat (named "co-pilot") receives the linked_message, renames itself with that UUID via llSetObjectName(), then whispers its own llAvatarOnSitTarget() ONLY if there is an avatar sitting there. At this point, the pilot's HUD is still listening to its owner and to the other seat.

4) The co-pilot sits with the same relative HUD listens.

5) The co-pilot seat (now named with the pilot's UUID) performs the exact same steps as the pilot seat. When the co-pilot seat whispers the UUID of the co-pilot, the pilot's HUD (listening to that seat) receives the co-pilot's UUID. It can then switch its second listen to the co-pilot's UUID.

6) At the same time, the pilot seat receives the link_message from the co-pilot seat, renames itself with that UUID and - because the seat is occupied - whispers the pilot's UUID. The co-pilot's HUD receives the new UUID and configures its secondary listen to that new KEY.

 

When an avatar unsits, the opposite seat should be re-named back to the generic "pilot" or "co-pilot" name. Also, you'll need a HUD button or command to reset the listens when that happens, so that the HUD can listen out for a new pilot or co-pilot. Alternatively, instead of swapping the secondary listen from seat to avatar, you could open a third listen to receive comms from the other avatar and maintain a listen to the seat. The seat could then communicate when the other avatar unsits, allowing the avatar listen to close.

[Can anyone give me a good example of using llRezAtRoot?]

Yes.

When you rez a linked object from your inventory, the rez position is based on the center of mass of the linked object. llRezObject() works the same way when rezzing from prim contents.

With llRezAtRoot() you specify the rez position of the root prim for the linked object, instead of the more ambiguous center of mass position. This is beneficial when rezzing non-symetrical objects.

Say you build a house and link it into several sections; north wing, south wing, east wing, west wing. You give each house section a root prim at the same x,y,z position as every other section's root prim. Using llRezAtRoot(), you can rez all four sections at the same position and the house will be assembled properly. If you only use the llRezObject() function to build your house, you would need to calculate offsets to make each section rez in the correct position.

[Ways to take attendance with llSensor()]

Yes, this is possible.

First, you need everyone to activate the same group tag. Then, assign that group tag to an object with a script running a llSensorRepeat() that scans only for agents (avatars). Test each avatar found to see if they're a member of your group with llDetectedGroup(). If they're a member, add them to a list (if not already found within the list). At the end of the fire alarm event, send the list to your off-world database.

 

float SCAN_RANGE = 96.0;float SCAN_RATE = 60.0; // once per minutelist responders;default {   state_entry() {      llSensorRepeat("", "", AGENT, SCAN_RANGE, PI, SCAN_RATE);   }   sensor(integer num) {      while (num-- > 0) {         if (llDetectedGroup(num)) {            string name = llDetectedName(num);            if (~llListFindList(responders, [name]) {               responders += [name];            }         }      }   }}

 You could get fancy and add an "Alarm Event" ID number to each list in order to keep logs for different fire events. When you initialize the script at the scene, have the ID generated and added to the list first.

You could even add a "Time On Scene" component. This could be done by storing a llGetUnixTime() with each entry into the list along with placeholder for a "seconds" counter in the list. Then, if a name already exists in the list, instead of ignoring it, calculate the time difference between the current llGetUnixTime() and the initial time stored in the list. Replace the list item for "seconds" with the difference.

 

 

[How can a script tell the difference between a login rez and an attach rez]

One way is to take advantage of the fact that on_rez() always triggers first. Plus, depending on your script, you may execute a quick line of code when the object gets detached. So, set a variable to FALSE first line in the attach() event (you'll set it TRUE later in the event after you've tested that the obect is indeed attached). Inside on_rez(), check to see if that variable is TRUE. TRUE should indicate a login rez.

When the user attaches the object, on_rez() triggers and the variable test indicates FALSE followed by attach() which immediately sets the variable to FALSE anyway. Then, still inside attach(), do your llGetAttached() and != NULL_KEY tests and set the variable to TRUE if the object is indeed attached.

When the user detaches the object, the variable should get set to FALSE. Therefore, theoretically, the on_rez() event should only see the variable as TRUE when the object is already attached at login.

[Is this possible in lsl?]

While it's not possible to modify an object inside contents or inventory, technically it's possible to do something like you describe - with some limitations and communications methods.

 

If you'll give the object to inventory (even to another avatar), you could send the preset configuration to a server database which the new object reads when rezzed in order to configure itself.

For instance, if you sell custom teddy bears with more variations than you can possibly store in contents... maybe you offer a HUD which the customer uses to precisely customize their bear. When the order is placed, send all the variables to a database along with the customer UUID. Then, give the customer a generic bear. When the customer rezzes the bear, its script reads the database, matches the owner UUID to the customer UUID, applies the configuration, then clears that line from the DB.

 

For simple things like setting the color of a single prim in the object when rezzed, you could use the integer variable of the on_rez() event. In the HUD, encode the desired color vector as an integer and send that with the llRezObject() "param". When the new object is rezzed, it could read the param from on_rez(), decode it back to a vector and apply the color.

You could also use chat/listen to send configuration info to a newly rezzed object.

 

Of course, these require the object to be rezzed in a script-enabled area.

[Quaternary rotation]

I use a simple utility script when all I need is a hardcode rotation. Set a prim the way I want, drop it in, copy/paste results.

default {   state_entry() {      llOwnerSay("Rot: " + (string)llGetRot() + " / Local Rot: " + (string)llGetLocalRot());   }}

 

[Quaternary rotation]

A function you can use is llEuler2Rot(). There are good explanations on the old wiki.

Rotations: http://lslwiki.net/lslwiki/wakka.php?wakka=rotation

Quaternions: http://lslwiki.net/lslwiki/wakka.php?wakka=quaternions

[Preventing a backlog of touch commands]

Yes, there is a delay function called llMinEventDelay().

I think it's an overlooked but very useful function.

[Help: Dropbox that IMs and/or Give Item(s) to avatar that drops a notecard (without touching box)]

With most dropbox solutions, a problem will occur if more than one avatar tries to drop at the same time. The script can't control who is allowed to drop, so it will be possible for one avatar to initiate the process, while another drops an item into the box. You also need to clean the box to keep the contents from filling to a limit.

Since you're requesting notecards, I assume the notecard can be named by the user. When an avatar interacts, either by touch, scan, chat, or collision, send the avatar an IM with a random code and brief instructions. The user renames the notecard by copy/pasting the code. At that point, you have a list of users in your script with associated codes. When an item is dropped, you can call for it by name and process with minimal effort. Clear the name and code from the list. You can also crosscheck the list in case an avatar is detected or touches multiple times before dropping a notecard.

[Help: Dropbox that IMs and/or Give Item(s) to avatar that drops a notecard (without touching box)]

There's no reliable way to do either. Once an item is dropped into another avatar's "dropbox" object, it immediately becomes owned by the owner of the dropbox. The best you can do is "llGetInventoryCreator()", but it can be difficult even to know which inventory item was most recently added... and the creator isn't always the person doing the dropping.

[Msg cut]

Maybe something else in your script causes the message to be cut at a different point when worn as a HUD. I ran a quick test and my llOwnerSay() message was cut at the same point both on the ground and as a HUD.

[llMoveToTarget (randome ocation)]

If the land is square or rectangular you can use a fairly simple formula to randomly choose any point within your land:

default {
    touch_start(integer num) {
        vector C = <50.0,50.0,50.0>; // parcel SW corner
        float  W = 200.0;
        float  H = 100.0;
        vector p = <llFrand(W) + C.x, llFrand(H) + C.y, C.z>;
        if (llVecDist(llGetPos(), p) > 65.0) {
            llSay(0, "Too far, shortening...");
            p = llVecNorm(p) * 65.0;
            p.z = C.z;
        }
        llSay(0, (string)p);
    }
}

Since the move distance limit is 65.0m, there is a check to see if the new position is too far. In that case, the vector is normalized, then stretched out to 65m

[How do I clear the Mute List?]

Ok, the "Mute List" should look something like this:

When there are names in that list, you can select a name and the "Unmute" button becomes available.  If that's not the case, maybe there's something different on your particular veiewer/version of the SL client.

Another way to unmute is to find that resident/object in person, right-click their avatar and choose unmute if it was a person.... if it was an object, you need to search through the pie-menu for the mute/unmute choices.

[How do I clear the Mute List?]

Under the "View" menu, click "Mute List".  That shows a list of all residents and objects that are muted.  Select one, then click the "Unmute" button.