[sldev] LSL initiated Prim metadata was Re: Plugin architecture

Argent Stonecutter secret.argent at gmail.com
Tue Feb 27 16:16:01 PST 2007


A useful scheme, one that wouldn't be intended just for testing,  
*also* sounds like a good idea.

> - from LSL: `llGetAttribute(string label)' and `llSetAttribute(string
> label, string data)' would seem to be all that is needed. Maybe later,
> functions which accept a list of [label, data, label, data, ...] to
> get/set multiple attributes at once, for efficiency. Perhaps also a
> separate `llDeleteAttribute(string label)' function to delete the
> attribute entirely (instead of just making its data blank).

Good so far. Making the data a list rather than a string (so you can  
have an attribute similar to llParticleSystem without having to trust  
the script properly encoding it) would be good, but not essential.

To reduce network traffic, the sim wouldn't broadcast the attributes,  
it would broadcast a list of attribute names, so the client could  
only fetch the attributes it's interested in.

Also:

llGetAttributeKey(key id, string label)

This would let you implement code that could handle attributes on  
nearby objects, so if you're standing in front of a vendor using  
llHTMLtexture your HUD could alert you.

llSetAttributeKey(key id, string label, string data);

For building tools, and to set attributes on avatars. Eg:

change(integer what)
{
   if((what & CHANGED_LINK) && llGetAttached()) {
     llSetAttributeKey(llGetOwner(),"extended-skeleton","centaur");
     llSetAttribute("attach-point","hind-leg");
   }
}

llGetAttributeLink(integer link, string label)
llSetAttributeLink(integer link, string label, string data)

To head off the people who might otherwise create 300 prim wings with  
a script in each prim.

> - from the UI: assuming that you have permission to modify a prim, I
> see no reason why you shouldn't be able to edit its arbitrary
> attributes from the UI, like you edit its name, description, and other
> parameters.

This would tend to work against the idea of making the attributes a  
list, but it's definitely a worthwhile tradeoff.

> Perhaps it would also be useful to have "hidden" attributes, which are
> not visible to clients.  (This would be quite handy as persistent data
> storage for LSL scripts!)

Start the attribute name with a "." and it wouldn't be sent to the  
client in the list?

(half-smiley)


More information about the SLDev mailing list