It’s an event…
November 19th, 2008 Posted in Purple Wyvern Designs | No Comments »Sometimes weird bugs creep into scripts especially those that have morphed and grown over time. I was having a problem with settings not getting stored by the object and getting reset to default or stuck on an old value. I was wondering if I had found a weird SL bug, but it turned out I had been unintentionally using a workaround that was no longer working in the latest server version and I had a basic script mistake that I was working around with some over complicated functionality.
My problems stemmed from the fact my scripts often contain the following statement:
default {
on_rez(integer start_param){
llResetScript()
}
I primarily do this in any script where I use llGetOwner() in order to ensure that any listeners or other functions depending on the users key are set up correctly. However, resetting the script means that it sets any variables used back to default values. My work around for this was to store the variables in the description field of a child primitive, a technique known as primitive parameter overloading.
If my objects were just rezzed on the ground, I would of been OK at that point. But they are not, they are worn attachments. Attachments don’t tend to easily let you edit there description fields when worn. If the description is blank, it seems to let you write it once or twice, but not always. Attachments will revert any object name changes on being un-worn, it looks like the description field gets reverted as well.
However, after a little advice from a friend who mentioned that I was probably doing something fundamentally wrong and I that shouldn’t be using llResetScript() in the on_rez event if I wanted to persist data, I decided to go back and revisit events and how they are triggered.
