Your expected script behavior has never been a feature. It was originally implemented without consideration for the description of objects with multiple representations. It has been on a 'to consider' list here in the office, but actually implementing it is very expensive on central server resources.
What do you hope to accomplish? Is there another way? Why is this such a critical feature for you?
What do you hope to accomplish? Is there another way? Why is this such a critical feature for you?
First question... shouldn't we be able to post to an existing thread in this forum if we started the thread? It's going to make it a bit difficult to carry on a conversation. But anyway...
The ability to update descriptions on attachments used to work fine. I'm not sure exactly which update broke it, but it was around 2-3 months ago that I noticed it had stopped working (the bug report was sent on 8th Jan 2006).
I was using this as a method of storing an id which was used with XML-RPC, to reference a record in an off world database. AFAIK that's the only place I can store a value that won't get destroyed if all the scripts in the object are reset. If I just store the value in a script variable I have to make it so the users can't reset the scripts, then if a script ever crashes there's then no way to get it working again without completely replacing the object.
Unfortuntely it gets even more complicated at this point, because object permissions were changed some time ago which makes this whole method even worse. Because an object now has to be modify so that an owner can reset the scripts, even if I did store the value in the description, the user could change the value manually themselves anyway. What I really need is a way to store a value that isn't in a script, and for the user to be able to reset the scripts without being able to modify the object. Or maybe have llResetOtherScript work on crashed scripts.
All this just comes back to the fact I don't really trust an LSL script to run constantly without ever crashing. There's so many variables in SL that I don't think we could ever really trust them to that extent, but the current combination of how permissions work and the LSL commands we don't really have any way to allow a user to get scripts working again without the original creator just replacing the object. Unless we make the object fully mod for the new owner which then allows them to modify this value I don't want them to be able to.
Hope that all makes sense. I just seem to be stuck in a catch 22 on this one.