[sldev] [LSL] Extensible Prim Attributes (was Re: New Scripting Functions (Iridium Linden))

Andre Roche roamingryozu at gmail.com
Sat Sep 29 14:41:25 PDT 2007


192 bits? Bits or Bytes?  If bits, I'd be pretty disappointed.
Without some extra effort, you couldn't quite store a UUID in that.
I'd rather just have a second 256 byte "Description" field.  A 256
byte description field would suffice for all kinds of client hacks,
could store a UUID and a small tag defining it's purpose, and if this
was sent along with the rest of the prim attributes, would only add
3.6mb to a sim of 15,000 prims.

Iridium, can we get a little better idea of just what was meant by
this feature suggestion?

On 9/28/07, John Hurliman <jhurliman at wsu.edu> wrote:
> The "scratchpad" in the prims would be something like 192 bits (?
> someone correct me here please) I think. Enough to store a header byte
> holding the type of extension, plus a small amount of flags/data and a
> UUID or just a decent amount of flags/data. A client could access lots
> of data by storing a UUID here and doing asset downloads, but I don't
> know if that power would be accessible through LSL. The actual 192ish
> bits would be read/write from LSL though (I'm told).
>
> John Hurliman
>
> Lulworth Beaumont wrote:
> > Please excuse my ignorance on this, but does the bullet point 'Scratch
> > area' in 'Extensible Prim Attributes' mean that prim attributes would
> > become a generic bag of attributes that one could also 'hijack' to
> > store any kind of data (thus removing the need to have another script
> > or some other mechanism to store this once the 16k limit on a single
> > script is reached), or does it mean something quite different?
> >
> > Lulworth
> >> From: Iridium Linden <iridium at lindenlab.com
> >> Extensible Prim Attributes
> >>
> >>     * Scratch area
> >>
> >>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>


More information about the SLDev mailing list