Jump to content

Object loses its "touch" attribute


Laurent Vesta
 Share

Recommended Posts

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?

Link to comment
Share on other sites

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 by Rolig Loon
Link to comment
Share on other sites

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 by Innula Zenovka
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Quistess Alpha
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Quistess Alpha
  • Like 1
Link to comment
Share on other sites

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 by Laurent Vesta
  • Thanks 1
Link to comment
Share on other sites

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 by Innula Zenovka
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...