Sometimes it works...

[Anna Nova]

I wrote a script to use RLVa to add clothes to my avi using a dialog to choose the folder.  The script sits in a higher-level folder, and puts up a dialog of all the sub-folder names, when you choose one, it RLVa attaches the contents of that folder.

It used to work well, but over the last year has got progressively unreliable.   Sometimes it works fine, other times it doesn't do the dialog at all.

Has something changed in SL or LSL that I've missed?  Do I need a bigger delay somewhere because of asynchronisity?  Or am I just a scrap programmer....

https://pastebin.com/iyChwp4H

[Quistess Alpha]

I might feel like debugging that for you later because it's neat, the only thing I see at a glance is that you should wrap everything in your attach event with an if(ID) test. Attach fires both when you attach something, and (counterintuitively) when you detach it.

attach(key ID)
{  if(ID)
   {  // was attached: add all the stuff in your event here.
   }else
   { // was detached.
   }
}

Also, instead of adding and removing a listen on different channels, I would keep the listen always open, and set a global variable (integer gExpect) based on what kind of reply you're expecting to receive. That would make it more resilient to receiving a reply before the listener has been set up.

[Coffee Pancake]

1 hour ago, Quistess Alpha said:

Also, instead of adding and removing a listen on different channels, I would keep the listen always open

especially as the listen is only listening for your specific avatar, there isn't really any need to tidy it away when done, it's not going to cause lag or problems.

[Fluffy Sharkfin]

1 hour ago, Coffee Pancake said:

especially as the listen is only listening for your specific avatar, there isn't really any need to tidy it away when done, it's not going to cause lag or problems.

After reading Kelly Lindens explanation of listen events in the notes on the llListen wiki page my understanding of listen events has always been that, even though the event may not fire, any script with an active listen will still query the simulators chat history during its slice of runtime, so it will cause some additional cpu load (I wouldn't know how much exactly but I'd assume that on a heavily loaded sim where script time is already suffering none is always preferable to some).

[Coffee Pancake]

2 hours ago, Fluffy Sharkfin said:

After reading Kelly Lindens explanation of listen events in the notes on the llListen wiki page my understanding of listen events has always been that, even though the event may not fire, any script with an active listen will still query the simulators chat history during its slice of runtime, so it will cause some additional cpu load (I wouldn't know how much exactly but I'd assume that on a heavily loaded sim where script time is already suffering none is always preferable to some).

Yes, it's not free, it's inexpensive, If there is no spare time on a region then this isn't helping any .. but removing it isn't going to solve the problem at that point.

 

[Mollymews]

On 4/8/2022 at 8:29 PM, Anna Nova said:

 Sometimes it works fine, other times it doesn't do the dialog at all.

the script is not removing the listeners created

listen_handle == llListen( ... );

results in listen_handle being 0

should be

listen_handle = llListen( ... );

which results in a unique handle not equal to 0

 

[Anna Nova]

21 hours ago, Mollymews said:

the script is not removing the listeners created

listen_handle == llListen( ... );

results in listen_handle being 0

should be

listen_handle = llListen( ... );

which results in a unique handle not equal to 0

 

that'll learn me.  I copied that bit from a script by someone else...   

Thanks everyone, but @Mollymews does seem to have fixed my issue.