MLPV2 - What Is Max Animations Allowable?

[Saoirse Morrisey]

Hi:smileyhappy:

 

I've started building and creating furniture and using the MLPV2 script for beds.  After purchasing a preloaded MPLV2 engine, I decided to invest in more animations and bought a large bundle which cost me quite a few linden.  I added most to the bed, only to get the infamous "script run time error.  stack heap collision" message.  I've tried almost everything recommended from the MLPV2 Wiki pages, shortening button names, deleting animations, etc. and it's still happening.  So I looked at the MP to see other beds advertised with 300+ animations and had an inworld browse around.  The ones using XPose engines seem to be capable of having hundreds of animations, but I believe the engine isn't available to buy in SL anymore.  When I looked at other beds using the MPLV2 engine, the amount of animations used all seems to be about the same, 9/10 buttons on main page with 9 buttons per page, so between 81 and 90 sets, total animations between 162 and 180 or thereabouts. 

 

So, my question is, is this really the maximum about of animations that an MLPV2 scripted bed can have?  It seems quite low when you see beds advertised with as many as 600+ animations included.  I just want to get a rough idea before I spend another week tearing my hair (wig) out!:smileyhappy:

 

Any advice would be greatly appreciated:smileyhappy:

 

Thanks,

Saoirse

[Ela Talaj]

Everything has a maximum as a script is not made from rubber I don't really remember details on MLPV-2 and have no time to look it up for free but it would appear to me that the limitation is not in animation names but in associated positions. For each animation you have to load its poseball position and rotation. rotation is in a vector (Euler) format, so there are 2 vectors of 35 bytes each (or is it 36 bytes for a vector? don't recall from the top of my head), anyways considering list management overhead, we'd count 40 bytes per vector for the total of 80. A list of x bytes actually needs 2x bytes of memory for operations on that list, so a list of over 28000 bytes is highly improbable as you would not have enough memory left for code. So 28000 : 80 = 350. That is probably the maximum number of animations you can have.

Should you start including 3-somes, gang-bangs, etc the maximum would decrease sharply because you would need 6 or more vectors to store in the list (2 per each poseball). the above assumes the list operations are handled memory-efficiently and that is a very big IF From what I looked at MLPV scripts long time ago they looked pretty amateurish.

In any case look if all MLPV scripts you have installed run as mono, just to be sure.

 

[Qie Niangao]

In addition to checking that the scripts are all compiled as Mono, you might also check to be sure there's no MEMORY directive in any of the configuration notecards. As I recall, that was introduced to make it possible for MLPV2 scripts to reduce their memory footprint on the sim where they were running, and might impose a too-low limit.

If that's not the case, a couple of suggestions. The first would be to join the MLPV2 in-world group, and if you ask at the right time, somebody is likely to know the detailed scalability limits of the engine. The second would be to try nPose... although migrating from MLP to nPose is a non-trivial task if there are many different poses involved, so before embarking on that, you may want to wait for confirmation that nPose can scale to larger sets than MLPV2.  (There's an architectural reason to think it could, and it's being actively developed, so if it doesn't scale larger already, it would not be as difficult to make it do so as would be the case for MLP.)

[jwenting]

And there's a serious practical limit to the number of things you can put in a prim's inventory before it lags itself to pieces that's far lower than any theoretical limit imposed by the scripting language.

A few dozen is probably what you want for low lag items, a few hundred at most (including all the scripts and notecards) as an upper limit.

[Kwakkelde Kwak]

The wiki might have some answers on where to look for memory savings:

LSL_Script_Memory

As stated in the wiki itself, it's not 100% complete or accurate, but it will give a good indication.

 

(I'm a bit out of my comfort zone in the scripting area, so forgive me if I speak nonsense...)

Looks like listed vectors and rotations are pretty demanding, more than the strings, but don't forget the strings that can really add up when the animation names are very long. On top of that, you can't really save anything on vectors and rotations by simply reducing their length, you can with strings.

I assume the animation strings are listed in the script. Let's say the object has 500 animations. Naming them "A1, A2, B1, B2" etc will cost 22+2*2 bytes per pose, so 13000 bytes. If the poses ar called "relaxed_sit1" or similair that would be 22+12*2 bytes resulting in 23000 bytes. That's 15% of a monoscript more.

No idea how the lists are compiled though, possibly they are cleared after (sub)menu use. One would have to read the scripts to see how that works. I think everything is loaded at once though.

[Saoirse Morrisey]

Hi:smileyhappy:

 

Just wanted to say thanks for all the replies.  I've shortened almost all the animation names which should help somewhat and a more up to date box of scripts, so far, no stack heap collision message!

 

Thanks again,

Saoirse