Help Request - Storing properties

I'm in a bind and annoyed...

I have several items I've written that have color and channel controllers, all through non-0 channel listeners.

I planned on selling these at some time, so I added the on_rez resetting of the script.

Unfortunately, it turns out that resetting the script resets the channel the item listens on to the default, and resets all variables to default (makes sense).

Is there a way I can store, update, and read properties into a script? Via a notecard or some other thing?

notecard no;
store yes
you can use the objects...
Name
Description
texture keys
texture offset
texture scale
color

just to name a few.

Are you sure you need to reset the script in your on_rez event handler?

If you don't reset the script, the variables will retain their values.

I discovered if I don't reset on_rez, when I give the item to a new owner, it still thinks I own it.

And I know its possible to store props in a notecard, the freaking genitals do it that way.

I'm just trying to figure out how to read/write to them

You can't write to a notecard. Period.

Hacks that write data to name, description, and other properties are ugly hacks.

Instead, what you need to do is however it is you check to see who the owner is, just reset THAT variable only when you rez the object, rather than resetting the script as a whole.

Do you mean that it listens to your commands instead of the new owner's? All you need to do is call llListen again in your on_rez handler; be sure to call llGetOwner and use that key, and not a key stored from an earlier call to llGetOwner.

But remember to remove your old Listens, or else you'll eventually end up with a crashing script, if it gets handed around enough (or you have 33 listens set).

I've heard you frequently disparage methods of storing data using prim parameters, descriptions, etc as being ugly hacks. Considering the ease with which these methods are implemented, and considering that they are the BEST non-volatile method of storing data (until the (hopefully impending) advent of a notecard write function), I think you're doing a disservice to new coders by telling them not to bother without providing any justification.

If you think these methods are flawed, please demonstrate/explain the flaws so that new coders will understand why they should or shouldn't use these methods. If you merely think they're inelegant, then I think you should explain as much. Differentiate between personal bias and professional wisdom, please. You need to keep in mind that there are three different types of coders in SL: newbies, engineers, and scientists. While scientists may disparage approximate solutions, engineers are more than willing to resort to "ugly hacks" if it solves the problem without sacrificing safety, usability, &c. (And newbies, under this overly-simplified, stupid worldview, will do whatever seems the easiest.)

To sum up these disparate points: Please explain why I, a simple-minded engineer, shouldn't use these methods of storing data until better methods are implemented?

Because they're ugly, and they're hacks. What part of that didn't you understand? I don't want to mouse-over an object to see what it is and see XYRBELKWWNEWBUH in the description. And someone ESPECIALLY shouldn't use them when a more precise method of resetting Owner controls exists beyond the sledgehammer llResetScript() is.

Sending data to yourself in the form of an email over and over is also a potential way of storing information, but one that contains risks (like losing the email somehow). And it's also a hack, albeit non-ugly.

If someone is a new coder, it's best that they learn the functions involved in script making OTHER THAN resetting the script. It makes for better code.

Ah ha... I didnt think of the original listener not resetting as being the problem... I thought it was still getting me as the owner.

However, I'm still going to use description for the channel being listened on, because I discovered one very nice thing about it.... you can look at your item and find out what channel it listens on if you forgot.

Thanks for the help gents and ladies. Oh for a simple text file and read/write.

And, on the topic of the hacks...

I'm a software engineer myself... quite simply, if your language doesn't do what I want, I'm either going to change to a language that does (impossible here), or force it to work the way it should.

Ugliness doesn't really matter to me.... if I want something done, it will be done.

Thats the attitude

If the square peg doesn't fig take a chisel to the hole to make it fit.

In what sense, a hack, Mol? The description field of an object is data, and we have functions to read and write to this... that's not a hack, that's a function of LSL. It's silly not to use resources available to you, if they do what you need them to do. Besides, does anybody ACTUALLY use the description field for anything else? I never have.

This is all IMO, of course.

Can I flame you? Pleeeeeeeeease? I've never started a flamewar before! Pretty-please??

too bad we can't store values into the desc fields of object in the invitory of a primitive.

It's because A) The description field was not intended to store data for scripts and B) It's a highly visible variable.

Not if you are using the description (or name) field for a child prim in a linked set. WHich is the only case where I have used those hacks.

Now see, no one has ever EVER mentioned that possibility, ANYWHERE on these forums before (that I've read, and I read a LOT on here). Doing -that- would just make it a hack. Not an ugly hack.

*giggle* What if I'm an exhibitionistic scripter?

I wouldn't call it a hack, either... it's more a 'creative application of existing functionality'.

I remember reading that suggestion before. It was a while ago, and would have been lost in the forum reorg.

EDIT: I'm mistaken. It was a suggestion about using texture offsets, not the description field, on child prims. Sorry.