Lag: Notecard read vs. obscure listen?

Two questions:

I have a script for an AV attachment that needs to get a few items of setup info on rez. Right now it listens on an obscure channel ... would it be lower lag for it to do a notecard read onrez instead? There are no other listens in the script.

I see that notecard reading is rather a heavy task, and an AV would wear this, so it would execute along with all the rest the client is doing whenever the AV logs in or TPs. I have objects that do that, but actually I tend to detach them whenever I log out if possible (having just a wimpy laptop and prev issues with inventory loss). Is it unwise to add a task like notecard reading to AV rezzing, or am I just being superstitous?

From the standpoint of sim lag, this should be negligible either way, but I see the point: anything that occurs during AV rezzing adds to that agonizing process, I suppose. The listen wouldn't need to be much of a lag at all if it called llListenRemove() when it was done with setup (or moved to a state without a listen() handler). Or, if it would be acceptable to users, could just read a few settings with llGetObjectDesc().

Why does it have to be on rez? I thought that notecard settings typically only need to be reread if the notecard changes or the script is reset.

I use the name of the notecard as the setting and then get the list of inventory names to parse with one empty notecard per setting.

Example
C_Offset=<0.0,1.2,4.2>

The only problem is that anyone can see what the setting is so it would not be good for a chat channel or a script pin.

On a side note: You won't get an on_rez event when teleporting any more... that was changed a while back, so if you want to detect a teleport, you'll also need a changed() event handler.

If you do use a listen (obscure channel or not), be sure to remove it when you're done getting your info. Are you listening to another script, a linked prim, the agent wearing the object, or a separate object? You could use a link message in the first two cases.

As for how much this contributes to lag, I wouldn't worry too much about it, as it isn't going on continuously once you are rezzed. If 20 people rezzed at once wearing your object, it might lag slightly for a moment but wouldn't last.

Wow, great tips, thanks!

@boss: good to know about on_rez. I do see the script go thru the state_entry code when I TP, so I guess it just gets reset? Also, the script is listening to the agent wearing the object, so link_message not available.

@Qie: Well, the wearer would have to do or say something to indicate that they don't want to do anymore setup, then I could remove the listen. Tho of course no one would ever do that, lol ...

By using GetObjectDesc you mean, have the user edit the object description to encode settings? I don't think they would want to, but I will remember that very cute trick!

@grumble: Another really cute trick! More failsafe than people actually editing a notecard ...

Hmm, afaik script load is completely server side so should have no real impact on your client (unless the script is creating hundreds of prims?).

As for listeners, doesn't your script control when its done configuring? I maybe missed something but cant you just:
addListener
do config stuff
remove listener?

That would prevent any additional sim load during normal operation, and honestly the effort to read a few note cards is not that bad.

No, it's not.

The user will have to create essentially the same text. As far as I know, a script can't rename a notecard. So the problem with generating the text is essentially the same.

But at least with a notecard, it's all in one place. You can cut and paste it, copy it into a text editor and print it, easily give a copy to someone else to proofread.

If the user screws up the notecard name, where did it go? Will they still be able to find it easily enough? How can they share settings?

Presumably it's faster, but that's the only advantage I see. If I'm missing something about this, please let me know.

And to get back to my original question, which is related to Shadow's point, why are you viewing configuration as an ongoing operation? Configuration is done once. You shouldn't have to repeat this every time the object is attached.

It's a wearable object (less than 10 prims) which is configurable by the wearer to have a different look. The user is expected to occasionally change it, but not often (ie. not like colorable shoes). It currently listens, but because users won't often be reconfiguring, I'm inclined not to keep the listen active all the time.

It could be editable, and users COULD be asked to edit its notecard.

However, I'm now inclining to just keep the listen and add a timer that puts the object to sleep automatically if it hasn't received a command in a while. In sleep it would remove the listen, and you would have to reset it (detach/reattach usually) to configure it.

[Btw, I'm being a little cagey about exactly what this script is doing not because there's any great mystery, but because I don't want some helpful person to just hand me their version for what I'm sure is very common -- I'm learning by doing here!]

If by any lucky chance the setting is one or more selections from enumerated lists of possible values, I would think llDialogs triggered by touch_start (by the owner only) might be handiest--well, assuming the prim is "touchable." I gather there are multiple possible settings to adjust, because it's not straightforward to know when the user is done stating their settings, so probably a tree of llDialog menus would be needed.

If on the other hand there are just way too many possible values--the extreme case of which would be some arbitrary text they'd want to wear, a la a titler--then it seems unavoidable that they'll have to say it in chat on some channel. Still, though, the listen might be triggered by touch and the user prompted to enter their setting within some timeout interval.

Of course, if the prims are untouchable--perhaps full-alpha or buried inside the avatar, or just too small to touch--then hmmm... I guess that's what listens are for, and it's a very cheap one since it's only listening to the owner and not on channel 0, so I don't see any real pressing need to remove it.

Well, that's a different problem than the one you described in the base note.

For this particular problem, I've seen three different strategies:

1. The user clicks on the attachment and a dialog pops up for changing the appearance.
2. The user issues a command, preferably on an easy alternate channel, and a dialog pops up.
3. The user issues a command that effects the change, again preferably on an alternate channel. (Aside: yes, that's a proper use of 'effect' as a verb.)

The notecard approach is only appropriate if the user rarely or never changes it, or for complex configuration items. The obvious one that comes to mind is a certain well-known market leader in private body parts. They do both the notecard and the click on attachment (or hud) approaches.