Tuesday, December 25, 2012

The Limits of Dance HUD Capacity

The Limits of Dance HUD Capacity 121225

I had a problem with a "stack heap collision" two times in the past few days with my Barre HUD. I thought about why this might have happened and found a fix to the problem, but  I thought that I should talk to the Barre creator, Racheal Young, about the problem and get her input. Racheal is always there with rapid customer service and I have included her response (with her permission). The discussion gets quite technical, but the practical effect is that I think I am finding the limits of how many dances you can put in one HUD and still have something that you can easily use.

Here are the notes:


Hi Rach,

Let me describe a problem that is happening with my Barre 3.02 and what I think the cause is. I've found a solution, but would like to know if I have identified the cause and your ideas to find a better fix.


The same problem has happened two times. I wasn't sure the first time whether I had done something incorrect or not, but I knew the second time that I was following normal procedures.

When I make sequences I do it either with dances already in my HUD or by adding new dances to my HUD. As you know I probably have more dances in my Barre HUD than anyone else in SL. The first time I experienced the problem I edited the HUD while wearing it. I have 6 notecards in my HUD right now and I added a sequence to one of the notecards that I call Med-Mod. To edit my HUD requires about 10 minutes for the contents to load because of the large number of dances in the HUD. To add a sequence while wearing the HUD I have a notecard with the same name in my inventory and make the changes there. Then, when the HUD contents are visible, I open the Med-Mod notecard in the HUD and copy and paste from the inventory notecard to the contents of the HUD notecard. I then save the HUD notecard. Since I keep a list of dances not in sequences in my HUD, I then again edit my HUD and wait 10 minutes for the contents to show and change the HUD notecard I call 94 Ordered by copying and pasting from my inventory version of it. In this case I am removing dances from the notecard. Once the 94 ordered notecard is saved, I close the editing window and reload the two notecards Med-Mod and 94 Inventory in that order. The first time I did it with the Barre 3.02 I got a stack heap collision error message when loading the 94 Inventory notecard. I verified that the HUD had loaded the revised 94 Inventory notecard, but found that the 10 buttons for dancing did not function.

To make the HUD work I had to reset all the scripts in the HUD using the Build menu. It took about 10 minutes to edit my HUD contents to be able to reset the HUD. Then I had to reload the six notecards.

Today I experienced the same problem doing a similar action. In this case I rezzed my HUD on the ground and added 6 new dances. I then added a sequence to my Fast Notecard using the copy and paste process from my inventory version of the Fast notecard. Once I saved the HUD version of the Notecard, I closed the editing window, wore the HUD and reloaded the Fast notecard. That is where I again got a stack heap collision. I solved the problem the same way.


I think what is happening is that the size of the HUD contents is slowing down the HUD's ability to process the revised notecards. Since it takes 10 minutes to open the HUD contents for me, I suspect there is some process that requires 10 minutes for the HUD to be able to properly read the revised notecard. Since I load the revised notecard in fewer than 10 minutes after saving it, the HUD receives a stack heap collision. So, the next time I will wait the 10 minutes after saving the last notecard changed before loading any of them.

Unfortunately the process of resetting the HUD has caused the Tool button not to work so I can't give you an exact count of the number of animations I have in the HUD.


I have read about the limits on HUDs in terms of script processing and number of dances. I think this problem of loading dances and changing notecards may be the real limiting factor on how many dances you can have in a HUD. I estimate that I have 6000 animations. To make the simplest change in my HUD of adding a dance and changing a notecard now takes me about 45 minutes. I think that I am getting to the practical limit of what the Barre or any HUD can contain.



Hi Nottoo,

The "Heap Stack" issue is a memory issue. I suspect that it is having to do with a MONO weakness in dealing with memory relating to LSL. Barre does ask LSL to perform as advertised from what Lindens describe as "proper usage". I can't even begin to tell you how many times I have had to do some bizarre hack because of something odd in LSL. Even after clearing a variable you have to wait for the server to catch up in some cases. But once again... the dance community pushes the limits of LSL in so many areas. It is sad to say this is commonly why many dance HUDs never evolve beyond their first few versions.

Barre 3.03 does have a new paging method for dealing with memory. I have not been able to force a "stack collision" with this version in all my testing. I won't say it is rock solid but I will say it uses better methods for dealing with HUGE amounts of memory. (*Nottoo you fit in this category. LOL)

From what you are describing to me it does sound like you have reached a hardware/user saturation limitation. As far as a "FIX" I don't think there is one, maybe work a around.
Populating an Inventory list of an object does take time to load from the server. It has to collect the data from the SL database and dump the list of inventory items into the editor every time you edit your object with new contents. For large object inventories this can take a very long time depending on demand on the SL database, Intranet, local region server traffic, server memory manipulation and finally the end users own Internet. All of these have an impact on how quickly the list populates to the editor. At some point the list can grow to large to be usable. This saturation point is not only a hardware issue but also a usability perspective of the end user.  I have often wondered where this point is. There is not a definitive line in the sand.

In the end to add any animation and confirm SL has loaded them (this includes all objects) you need to open the edit window, repopulate the list and verify it is in the list. LSL does have the ability to tell you that something has been dropped into your HUD. It can tell you that you added a new animation but once again there is a flaw with this ability since it reports locally and not by pinging the SL database to verify it is there. This can give you misleading results. Picking up an object at the wrong time may mean that it never really made it to the SL database since the object information needs to sync up the SL database information. Unfortunately this is something that many scriptwriters that use this method are not aware of. It can lead to failures and missing animations if not managed correctly. SL has been known to drop SQL queries and this is the core of the issue.

At some point the end user has to determine need over usability due to SL limitations. As most of us would love to have 1 million animation at a click of a button, you have to ask yourself is it really needed? When asked this question most users just laugh. I tend to hear they use maybe use 300 animations regularly and the rest are just specialty. As far as me personally, I like to have more then 300 at my fingertips, so I can appreciate the need for large inventories of animations and being able to manage them.

Barre 3.03 has taken a new approach to the saturation issue. Although not all issues with inventory can be dealt with by script improvements, there are some here intended to help. The new REC web interface allows for some internal manipulations of data in the HUDs databases. This is in early stages of development and if it is found to be useful I will expand on the concept.

As far as Barre 3.02 I have pause any "FIXES" on that version due to 3.03 being so close to release. I do have plans on splitting version soon. You will see a club based version of Barre as well as the show version that 3.03 is heading toward. I do have some surprising twists in the works.