Making HUD attachments better..

.. how would the following proposed changes sound?

- When an object is detached, instead of always going to the owner's inventory, it should go to the inventory from which it was last rezzed. (This would be the inventory of the object that provided the HUD, which can then delete the copy from inventory, or reclaim it if it's no-copy.)

- Allow objects to attach other objects directly from inventory, and also to attach to avatars other than their owner, provided that a) doing so does not displace any of the avatar's existing attachments, b) permission is granted, and c) the avatar remains within a maximum range of the object that triggered the attachment, with the attached object automatically detached if the avatar leaves the range.

Your first proposition is brilliant !

Here's my own suggestions,

- Allow llAttachToAvatar to attach a prim to another AV other then the owner if permission is granted.

- Provide a llSetPrimitiveParams option that allows us to set whether a prim is dropped back into the user's inventory, just get droped to "/dev/null" (skip the Garbage folder), or even just let us drop it directly into the Garbage folder for the user. Kind of like the "Die at Edge" or "Sandbox" options, but instead "Destory on Die" or the likes. Or even a new function llPermaDie()

Reason why I like the Destroy all-together or drop to garbage option is for the fact that we don't need to worry about doing tons of inventory management in our objects (dealing with trigger a change event and figuring out what doesn't belong or the new renamed value). Even the straight to garbage is a nice option as it keeps malicious individuals from giving a peice of content and then destroying it on the user, thus them losing a copy if they should still keep a copy.

Overall thou, I do like your idea Yomi. Even if I had to do inventory management in an object, I'd still be a happy camper.

If vehicle developers can get together with a "standard vehicle HUD" tool.

Put a script like this in a HUD:

integer V2HUD = 1111; // Standardize on some number here

integer hud2vehicle = 0;

integer UCHAN = 1113; // This can be anything.

default()
{
    state_entry()
    {
        llListen(V2HUD, "", NULL_KEY, "");
        llListen(UCHAN, "", llGetOwner(), "");
    }

    listen(integer chan, string name, key id, string message)
    {
        if(chan == V2HUD)
        {
            hud2vehicle = (integer)message;
            llDialog(llGetOwner(), name+" wants to attach a HUD script to you, is this OK?", ["yes", "no"], UCHAN);
        }
        else if(chan == UCHAN)
        {
            if(hud2vehicle==0) return; // Someone's playing silly beggars
            integer pin = 0;
            if(message == "yes")
                pin = llFloor(llFrand(2000000000));

            llSetRemoteScriptAccessPin(pin); // Should already be 0 if "no", but better safe...

            llSay(hud2vehicle,(string)pin);
            hud2vehicle = 0; // Forget who it was so people can't play silly beggers
        }
    }

    changed(integer what)
    {
        if(what & CHANGED_INVENTORY) // Someone set us up the script;
            llSetRemoteScriptAccessPin(0); // Drop the pin so nobody can play silly beggers
    }
}

Now when a vehicle wants to set you up with a HUD control, it generates a random channel number, listens to it, and does "llSay(V2HUD, (string)channel)". When it gets a PIN back on that channel it pushes its script onto the hud with llRemoteLoadScriptPin(), which is responsible for llRemoveInventory()ing itself when it's done.