Object loses its "touch" attribute

[Laurent Vesta]

I've been working on an object that monitor a region. At 10 seconds intervals, the object checks the region's FPS and other stats. To see those information, I added a touch feature which trigger a dialog.

The problem I see is that after a while (few hours), the object will suddenly not react to touches anymore. Right-clicking on it has the "Touch" item from the pie menu disabled.

What could cause this?

[Rolig Loon]

If your script switches states, there's a good chance that you didn't provide a way to guarantee that it can get back to state default under all conditions, so it's stuck.

[Laurent Vesta]

Thanks @Rolig Loon!

I have a case of a state_teleport but in its state_entry(), I call state default. Is it not sufficient?

[Rolig Loon]

I'd have to see the script to tell, but that doesn't sound like a reasonable place to put it.  You should script some sort of trigger to force execution back to state default. If your object is a teleporter, you might decide to put a state default; command in the timer event for state_teleport so that it jumps back to state default after a fixed number of seconds.  Or maybe you put it in the changed event, so that the script returns to state default when the traveler stands up.  Or maybe in both places.  In any case, without a trigger of some kind, there's a chance that the script will sometimes get stuck in state_teleport and unable to get back.  Follow the logic.  You'll find a way.   

Edited September 6, 2021 by Rolig Loon

[Laurent Vesta]

Thanks, I'll try a few things. The script is fairly long, so not sure about posting it here...

[Rolig Loon]

That's OK.  I think you ought to be able to follow its logic well enough to see where it gets stuck.

[NeoBokrug Elytis]

One trick I've learned is to just put an empty touch_end() event in the other states.

 

[Innula Zenovka]

If the script is adding data to a list every ten seconds, I wonder if that might not cause a stack heap collision after a few hours if the script isn't properly monitoring script memory and pruning old list items when necessary.

That's the first thing I'd look at, anyway, based on the bare fact that something that collects and stores data seems to become unresponsive every few hours.

Edited September 7, 2021 by Innula Zenovka

[Quistess Alpha]

31 minutes ago, Innula Zenovka said:

If the script is adding data to a list every ten seconds, I wonder if that might not cause a stack heap collision after a few hours if the script isn't properly monitoring script memory and pruning old list items when necessary.

Agreed, that would also be my guess. Perhaps I'm a bit lazy, but instead of monitoring memory, I'd default to using something like a fixed-length rolling buffer:

buffer = llList2List(buffer,-(buffer_maximum-1),-1)+new_item;
// prunes oldest item if the buffer would grow beyond buffer_maximum

I'm not sure how inefficient it is to always use llList2List though.

[Laurent Vesta]

On 9/6/2021 at 4:54 PM, Rolig Loon said:

I'd have to see the script to tell, but that doesn't sound like a reasonable place to put it.  You should script some sort of trigger to force execution back to state default. If your object is a teleporter, you might decide to put a state default command in the timer event for state_teleport so that it jumps back to state default after a fixed number of seconds.  Or maybe you put it in the changed event, so that the script returns to state default when the traveler stands up.  Or maybe in both places.  In any case, without a trigger of some kind, there's a chance that the script will sometimes get stuck in state_teleport and unable to get back.  Follow the logic.  You'll find a way.   

Thanks @Innula Zenovka. I didn't think of that. I'm going to check memory usage.

[Laurent Vesta]

On 9/7/2021 at 3:52 PM, Quistess Alpha said:

Agreed, that would also be my guess. Perhaps I'm a bit lazy, but instead of monitoring memory, I'd default to using something like a fixed-length rolling buffer:

buffer = llList2List(buffer,-(buffer_maximum-1),-1)+new_item;
// prunes oldest item if the buffer would grow beyond buffer_maximum

I'm not sure how inefficient it is to always use llList2List though.

Thanks @Quistess Alpha. What's the maximum you're using?

[Laurent Vesta]

Seems you can't delete double posts here, hmmm...

I've been monitoring the free memory to my script. When compiled with Mono, it has less than 1K and after a few iterations of the counter, I get heap collision. My script collects various data about the region and save those stats in lists. Since I can't find any way of dumping these stats somewhere, I have to keep them in memory.

I'm guessing its those stats in lists that are using memory. Are there any way to reduce memory footprint? My script runs a timer every 10 seconds to collect data. It also servers as a web server receiving HTTP requests and posting responses.

In the mean time, I recompiled the script under LVL (?). The script has now more free memory but I know that's not a long term solution.

Any idea what I could do?

[Quistess Alpha]

1 minute ago, Laurent Vesta said:

Thanks @Quistess Alpha. What's the maximum you're using?

It totally depends on your application, and what kinds of things you're storing, but as a rule of thumb, 100 keys or strings, maybe upwards of 200 vectors, but if I need to hold more than 100 of something, I'd run a little test in state_entry, filling everything and constantly spewing out memory usage and number of items held until it breaks. although, for strings, you need to randomize the string, (the new function llChar() is great for it) as LSL actually seems to efficiently store multiple copies of the same exact string in a list.

[Laurent Vesta]

I have 3 lists: one that stores the stats collected during the day and has 1 date and 7 integers. This list add an entry each time the date changes, so once a day.

The other list keeps the list of visitors. It collects a key, 3 strings and a date. This one can add more than one entry per day, depending on the visitors in the region.

The third list collects the region restarts. It logs 4 strings to reconstruct a date but it doesn't add much data since restarts are infrequent.

That's pretty much it. Some string and integer globals.

[Laurent Vesta]

After my script starts running, there is less than 5K available. That's not a lot. I'm software engineer, so I know a thing or two about programming but relatively new with LSL...

[Quistess Alpha]

16 minutes ago, Laurent Vesta said:

In the mean time, I recompiled the script under LVL (?). The script has now more free memory but I know that's not a long term solution.

Any idea what I could do?

Mono should have 64k of memory vs LSO's 16. Long-term storage of data is a problem most scripters come across eventually, and there are a few solutions, but none of them 100% ideal.

some options:

1) Increase script memory by adding more scripts. You could have a data-storage script, or even a sepparate data-storage script for each type of data you're collecting, that simply saves and sends back data when asked via llMessageLinked().

2) Email yourself the data periodically. Since you're storing the data and not like using it again in your script much it seems, this might be an ok solution. you could even set up a special email just for that purpose. ( Check out llEmail() or LlTargetedEmail())

3) Experience Keys. I think an experience's Key-value pair store holds about 100 megabytes of data (or 1 gibibit). Requires a premium membership though.

 

P.S. You can edit posts.

Edited September 11, 2021 by Quistess Alpha

[Quistess Alpha]

6 minutes ago, Laurent Vesta said:

I have 3 lists: one that stores the stats collected during the day and has 1 date and 7 integers. This list add an entry each time the date changes, so once a day.

The other list keeps the list of visitors. It collects a key, 3 strings and a date. This one can add more than one entry per day, depending on the visitors in the region.

The third list collects the region restarts. It logs 4 strings to reconstruct a date but it doesn't add much data since restarts are infrequent.

That's pretty much it. Some string and integer globals.

None of that data seems like it would overflow script memory very quickly, but the fps taken every 10 seconds you mentioned in the first post definitely could.

[Laurent Vesta]

Thanks, @Quistess Alpha!

What about the Experience Key? I have a premium account and my customers would likely have one too.

[Quistess Alpha]

7 minutes ago, Laurent Vesta said:

What about the Experience Key?

If you have a premium account you get a free "experience" to play with that you can enable on land you own. Experiences mainly allow you to manage certain script-permissions (attaching and teleporting being my main use-cases) more easily, (llRequestExperiencePermissions()) but it also grants you access to a key-value-pair storage system.

I've not used it personally, as any time I think it'd be great for some project or other, I usually find some other way around it, but the wiki describes the functionality pretty well. Just be sure to set up an experience, and tick the box to compile your script with that experience. (near the other compile buttons in the script window) you also may have to enable the experience on the land, I'm not sure if the KVP store is only available when you're actually on land with the experience enabled or not.

http://wiki.secondlife.com/wiki/LlUpdateKeyValue

http://wiki.secondlife.com/wiki/LlReadKeyValue

among a few other functions.

Edited September 11, 2021 by Quistess Alpha

[Laurent Vesta]

Thank you, @Quistess Alpha! Much appreciated!

However, I did access the Experience tab for my land. I have a window that lets me add Experiences and ban Experiences. But i have no idea how I can add something there. When I try to enter the object that holds my script, the window returns "Not found"....

Edited September 11, 2021 by Laurent Vesta

[Laurent Vesta]

How can I use Experiences?

[Quistess Alpha]

51 minutes ago, Laurent Vesta said:

How can I use Experiences?

in your viewer (might be slightly different viewer to viewer) 'Me' tab -> Experiences... -> OWNED tab -> 'Aquire an Experience'.

 

[Innula Zenovka]

55 minutes ago, Laurent Vesta said:

How can I use Experiences?

First, read this Knowledge Base article and then take a look at the Experience Tools page in the Scripting Wiki.

Also search this forum.

Though I would strongly advise posting data to Google Sheets or some other external source rather than using experience keys to store this kind of data.

I've done a lot of work with both Experience Tools' KVP functions  and with Google Sheets, and they're two completely different tools, suitable for very different purposes.  

Experience Tools and KVP are great for data you want to store and update persistently, and share grid-wide in (almost) real time, but they aren't good for storing lots of historical data you want to access at all readily.

 

Edited September 11, 2021 by Innula Zenovka

[Laurent Vesta]

Just want to give an update so that all your replies were not forgotten or ignored. Thanks to all. I decided to split my main script in 3 parts. One main script, one script to deal with data and one script to handle HTTP requests. So far, so good. Thanks all. I'm still investigating storage solutions but that's not a critical part at the moment.