Script "Property Sheets"

Someone brought up an issue with script permissions how they wanted a configurable but not redistributable script. The current permission system for scripts basically means full view of source or no view, nothing in between.

Current solutions for configuration include:
1. Script commands to set different options. Lost when script resets, otherwise they stick around. Great for runtime configuration.
2. Notecards. Expensive to parse, but persistant across script resets. Good for startup configuration, read once type stuff.
3. Script variables. Can be combined with script commands for run time config, stores across resets, but requires opening the source to make them available. Not always an acceptable option.

I propose adding a way to separate certain variables that the scripter registers into a simple key/value pair property sheet, perhaps as a second tab in the script edit window. This would always be available for editing whether the script has its source code viewable or not. The user could then edit values here (such as elevator heights, door orientation, colors, and more) and they would be stored between resets and copies, etc. Of course it would be required to link these in some way to the internal script workings. For simplicity's sake I would have them be string only, but one potential would be having various UI controls for the config sheets such as check boxes, list boxes, radio buttons, etc.

So as an example, I'll use my Primcrafters glasses, which have two parameters: color and tint

The property sheet on the script window would just be labels and text boxes:

Tint:  _____
Color: _____

These would be manipulated with a few new LSL functions.

integer llRegisterProperty(string name, string value)
Registers a new property key with a default value of value if it does not exist. Return value indicates whether new value was created or value already exists. Because these would be stored across script resets, you would not want to reset them to default each time. It would defeat the entire purpose.

string llGetProperty(string name)
Simply retrieves the named property

llSetProperty(string name, string value)
Sets the named property to value

integer llUnregisterProperty(string name)
Removes a registered property at runtime.

The persistance of the properties would only be cross-reset, they would be cleared on actual modification and saving of the script. This clears up any headaches with having old properties registered when you are editing it, but does not impede the use of them as configuration to the end user.

Phew. Comments?

I endorse this feature, rant, beef sandwich, and/or service!

Event notification of changed values. Not sure whether it should be done in bulk (with an OK/Cancel/Apply) or as they change. Discuss!

Oooo, VB!

Excellent idea =)

I support this idea/feature.

I would maybe suggest different input types or values, such as you could have an input box, check boxes, drop down, etc. maybe.

Anything that helps us increase scripted object usability is a good idea.

What about


list llDialogBox(list properties)

Properties is a combination of items such as:
[DB_TEXTBOX,X,Y,CHARWIDTH,DB_OK,X,Y]

It would return the values of the items in the order they were given, for instance, the above would produce a textbox with an OK button, so it would return

[Hello World,DB_CLICK]
(Hello world was entered in the box, and the button was clicked)

This would probably solve a lot of the problems, other than permenent variable storage.

As someone pointed out, you could put variable information in a notecard and read that via the script.

Notecard - full edit
Script - no mod

Meaning no offense but I doubt you'll see much progress for your idea, simply because you can already do it via a notecard. Given, your idea is definitely nice and perhaps more user-friendly than a notecard. I just don't think Lindens will give this much thought. I could, however, be wrong. :)

Boso

Yes, I was the one that pointed out notecards. The problem with notecards is the expense in reading them (dataserver hits), as well as the opprotunity for user error, in which Joe Avatar completely screws it up by deleting half the important lines. Harder to screw up when all you can delete are your settings.