[sldev] LSL initiated Prim metadata was Re: Plugin architecture
gigstaggart at gmail.com
Tue Feb 27 11:25:47 PST 2007
Argent Stonecutter wrote:
-snip bunch of irrelevant crap-
I think we need to go over how this works again, you are completely
missing the point. Please read carefully.
Suppose I want to implement the client side part web textures, so that
Linden Lab can easily pick up the patches and make minor server side
changes to support it and then it'll be done.
Right now, it's kinda hard to do that, because there's no way to
associate this new metadata with a prim, without using something hacky
like the description field, or having it OwnerSay the stuff over and
over. Either method means that it'll have to be rewritten later on when
the actual protocol is updated to take advantage of the feature. My
proposal eliminates that rewriting.
This system allows me to implement web textures in a way that can be
easily picked up by Linden Lab and transitioned into a real feature.
You notice this has *nothing* to do with plugins, not directly.
Here's how it would work.
1. I make up my mini API for web textures:
webtext, face<facenumber>, <url>
2. Then, on my testing prims I insert the LSL Script:
//inserts string into tag 0 for this prim.
3. Then, in the client I begin to make my modifications, which read tag
0 and use that data. I ensure that it's easy to change which tag number
that my feature is assigned to, for the day when it is accepted and
moved to a real tag number.
4. I test the feature, and encourage other *developers* (including
linden lab) to test it too, by applying my client side patches, and
using the LSL to set tag 0 on some test prims to the strings that my
feature is expecting.
5. Feedback is gotten from Linden Lab developers on the feature, and
the feature is patched/updated/further developed.
6. The feature is accepted by Linden Lab. Linden Lab can then assign
the feature a unique tag number, lets say 1001.
7. Linden Lab implements:
llSetWebTexture(string url, integer face); //Updates prim tag 1001 with
"webtext, face<facenum>, <url>"
Note that this uses my same API except it is now on a high tag that
can't be modified directly by users.
The client is updated by changing a single constant, that tells the web
texture feature to look for tag 1001 instead of tag 0.
You'll notice that this is entirely a development tool. It is not meant
to be used by end users, ever. There is no way for anyone except Linden
Lab to modify any tag other than tag 0. Tag 0 is solely for development
There is no chance for any "support for undocumented features" problem
like you mention.
More information about the SLDev