MLPV2 unknown problems

[Raena Parx]

I've worked with MVLP2 menus quite a bit but never had this problem... It appears the first menu notecard is being read twice.  Then I get an error that there are duplicates.  I have checked and rechecked every menu card, positions card and props card.  There are NO duplicates.

I have 4 sets of the cards (menu, positions, props) that I'm trying to setup as add-on modules.  Each set (module) runs fine on its own, but when I combine them I get a heap stack error.  I'm not sure if it's related to the first problem or if its a secondary problem.

Does anyone have an idea what's going on, and how to fix this?

Thank you.

[Phil Deakins]

I'm not sure that I understand what you are trying to do, but this is what I think you are trying to do. Correct me if I'm wrong. You are trying to place multiple 'sets' of cards (modules) into a single piece of furniture, presumably so that in use you can switch between which set is being used.

If that's what you're trying to do, you need to make sure that all the data from the currently loaded set is removed before you start to load the next set. Both of your stated problems (stack-heap collision and duplicates) would occur when you don't remove all the current data first, assuming that you have duplicated one or more animations in the sets. E.g. used the same cuddle data in more than one set.

ETA: To remove the data, all you need to do is reset the lists that it's stored in.

Edited September 3, 2017 by Phil Deakins

[Raena Parx]

That does make sense.  However I made sure that each card has its own individual names of positions, props and menus.  For example I would use the same positions but precede the names with d1.name,  d2.name,  d3.name, etc so each card has its own named sets.

Am I overloading with too many?  Or is there a better way to do this?

If I need to reset the lists, can you please tell me how to have MVLP2 do it automatically?

Thank you so much.

[Phil Deakins]

The stack-heap collision does mean that you are overloading it. In case you don't know what a stack-heap collision is, I'll explain it. When compiled in Mono, you have 64k of memory for the script and its data. The programme code is at one end. That's the 'heap'. When it is loaded, it is fixed. The variables, such as animation data, start at the other end and builds as needed. That's the 'stack'. If the two meet, there's a stack-heap collision, and the script 'breaks'. If it didn't break, the data would overwrite the code, and it would break anyway.

Since you ensure that there are no duplicates, without examining what you have, I don't know why you get the 'duplicates' errors. One thing you can be sure of is that, when it says there's a duplicate, there really is a duplicate. It doesn't matter though because clearing the lists before loading the next set will fix that. Clearing the lists means that the next set will need to be loaded each time you switch, and that takes time. It's not instant.

MLPV2 is a development of the MLP system and, although I used the MLP system many years ago in my furniture, and modified it quite extensively to suit what I wanted, I never looked at the MLPV2 system. So I can't tell youi how to clear the lists in it. What I can tell you is how to clear a list. Suppose you have a list called 'anims'. To empty it, all you need to do it use the line, anims = [];  That leaves the list intact but without any data in it.

To save the loading time each time you switch sets/modules, you could use multiple sets of scripts, or at least multiple scripts for specific things like positions data. Then you'd need to modify the system's scripts so that it will switch between them. It would take some doing and you'd need to be quite a reasonable scripter.

Another possibility is to get in touch with MLPV2's creator. I know his name but I can't bring it to mind. I have the system but the creator is shown as 'unknown / multiple' at the moment. One of the multiples was Miffy Fluffy - something like that. he created the MLP system. The one who changed it was a regular forum user many years ago. He improved the MLP system so that it could accommodate more than 2 avatars. He's the one to find if he's still around.

Edited September 4, 2017 by Phil Deakins

[Phil Deakins]

18 hours ago, Raena Parx said:

If I need to reset the lists, can you please tell me how to have MVLP2 do it automatically?

I just had a thought. The line that I quoted suggests that you are not really a scripter and, if you're not, then what you are trying to do won't be possible for you to do yourself. Doing it needs to get into the scripts and modify them quite significantly.

You could always do it the easy way and have a seperate prim to click on for each set/module. In use, it wouldn't be very elegant, but it would work.

Edited September 4, 2017 by Phil Deakins

[Qie Niangao]

3 hours ago, Phil Deakins said:

The one who changed it was a regular forum user many years ago. He improved the MLP system so that it could accommodate more than 2 avatars. He's the one to find if he's still around.

It doesn't look promising (assuming my memory of who made those changes is correct).

I'll just mention that AVsitter recently (end of July) went free / open source, if migration is an option. There's a migration-from-MLP utility script, but I have no idea how complete it is.

That's not to suggest that AVsitter is immune from stack/heap collisions. I'm not following this scheme, above, of multiple menu notecards -- I haven't used MLP for years -- so no clue if that's easier or impossible with AVsitter. (I also haven't used nPose for a long time, but if you're genuinely running out of memory for poses, I'm pretty confident nPose could handle many more anim sets than other engines, but as a consequence it's a tremendous pain to configure, with each set using a separate notecard loaded as-needed.)

[Innula Zenovka]

On 9/3/2017 at 8:10 AM, Raena Parx said:

I've worked with MVLP2 menus quite a bit but never had this problem... It appears the first menu notecard is being read twice.  Then I get an error that there are duplicates.  I have checked and rechecked every menu card, positions card and props card.  There are NO duplicates.

I have 4 sets of the cards (menu, positions, props) that I'm trying to setup as add-on modules.  Each set (module) runs fine on its own, but when I combine them I get a heap stack error.  I'm not sure if it's related to the first problem or if its a secondary problem.

Does anyone have an idea what's going on, and how to fix this?

Thank you.

The fact that you are getting an error that there are duplicates and the stack heap collision (caused by the script running out of memory) are certainly both part of the same problem -- that is, it would seem that when your script reads the notecards, it's adding list items when it should be over-writing them.  The lists, therefore, are far longer than they need to be, and that's obviously going to make you  run  out of memory a lot earlier than otherwise you would.

Without seeing your scripts and set-up, that's all I can say, based on the available information.   If you're not yourself an experienced scripter who is familiar with the MLPV scripts in particular and, in general, with how to manage lists and populate them from a notecard, I can only suggest you find someone who is to take a look at your set-up.   

It's a long time since I worked with MLPV but I suspect that, unless you've got a huge number of poses, it's going to be pretty simple to fix -- so long as the person fixing it knows what they're looking for.

However, I would echo Qie's suggestion that you at least consider migrating to AVsitter and seeing if that solves the problem.

[Phil Deakins]

1 hour ago, Qie Niangao said:

It doesn't look promising (assuming my memory of who made those changes is correct).

That's the guy. I now remember that it was Lear, but I wouldn't have been able to drag his first name up from the depths of my memory. I don't think he's been around the forums since the good old days of RA.

Edited September 4, 2017 by Phil Deakins

[Phil Deakins]

1 hour ago, Qie Niangao said:

I'm not following this scheme, above, of multiple menu notecards

I'm thinking that he wants something along these lines...

A set of menus for non-sex animations, another set to include sex anims, and perhaps another just for BDSM anims. The set perhaps being selectable only by the owner. That's the sort of thing that I imagine he wants to end up with. MLP and MLPV2 can be made to do it, but it would require some competent scripting ability, and I don't think OP has that, though I may be mistaken..

[Raena Parx]

Thank you all for your input.  I am not a scripter.  I've worked a lot with the basic "out of the box" MLP and MLPV2 just using notecards for configurations.  This is my first attempt to make a modular-style layout of configurations.  Individually they work, but if it's reading the notecards I cant find where or why, and i'm sure that's why i'm running out of memory.    

I attached an image below of the output when the scripts load.

It seems that if it was re-reading the notecards twice then ALL the notecards would show duplicates, but it's only these two notecards:  .PROPS.V DOC1 and  .POSITIONS.V DOC1.  

Each .POSITIONS.... notecard holds 40 pose sets.  After all your suggestions I'm thinking I may be expecting to load too much into MLPV2 and may need to separate into 4 individual exam tables instead if it is a huge scripting task.  Or do you think it could be made functional with just a few script customizations?  

 

[Phil Deakins]

I can't help you any more, I'm afraid. For one thing, the MLPV2 that you're using appears to be a later verion than the orginal that I have, so I can't even look at what you've got.

What I can say is a repeat - that, if you're  getting a stack-heap collision, it's because you are loading too much into the available memory. To that I can add that it would not be a simple bit of script tweaking to overcome it. It would be a relatively major operation. For instance, I added to the MLP system to do what I wanted. Changing it meant moving parts of the main script into new scripts, and doing that meant making sure that all the necessary scripts took account of the changes. It's not a matter of simple script tweaks. Many things can be tweaked, but, if you're running out of memory, then it's anything but a tweak to deal with in a big system like the MLPV2.

In your case, I don't know which script is holding the positions data. I'm assuming that it's that data that's causing the collisions. The system could be changed so that each module's positions are stored in its own script - a positions script for each module. That's a simple overview, but then the system has to be changed in various places to handle that, and that's where it takes time. It's not just a simple few tweaks.

It does sound like you have an alternative though - ".... may need to separate into 4 individual exam tables instead". That was a suggestion I made earlier - using a seperate prim to click on for each module. That's your best bet. Then, if you're really keen, you could spend a lot of time learning to write programmes, so that, at some time in the future, you could modify the MLPV2 to suit what you want. Or, better still, write your own system.

Edited September 5, 2017 by Phil Deakins

[Phil Deakins]

I just had what could be a eureka moment. When the MLPV2 was originally written, SL didn't use Mono for compiling, and each script had a 16k memory limit. So do this...

Open one or two of the scripts and look at the bottom of them. In fact, check them all. See if the Mono checkbox is checked or not. If it's checked, forget it, but if it isn't checked, check it, and do the same with all the scripts. You never know. If the scripts are not using Mono, then changing them to Mono could be the total solution to your problem. I think they'll already be using Mono, but you never know

[Raena Parx]

I had read something about that in another post awhile back so I did check them. All the scripts are checked as Mono.  Even if I separate them into separate exam tables, I'm still concerned that adding more modules as I originally intended may still overload.  I like your idea of using additonal prims for adding modules.  Do you know if MLVP2 can be added to a non-root linked prim if it already exists in the root prim? Or would it need to be an unlinked prim? I've never tried it.  Thank you again.

[Qie Niangao]

I'm looking at a .readme from MLPV2 Version 2.5 (I think it's actually "2.5c" based on the name of the box it came in), which came well after Mono, around the time llSetMemoryLimit was first introduced. There was a lot of confusion about what that function did -- we don't need to revisit all that -- but apropos the stack/heap problems, this notecard states:

Quote

// === SCRIPT MEMORY REDUCTION ===
//
// MLPV2 now reduces its memory limits after reading the configuration, to 
// reduce parcel memory usage.  This happens by default without any change
// to notecards.
//
// There are now MEMORY commands for all notecards.  See example notecards.
// These set the amount of free memory to reserve after reading configuration.
// Lower numbers use less region script memory but also increase risk of
// stack-heap errors.  Set MEMORY to 65536 to get max permissible memory.
// If MEMORY commands are omitted, defaults are used.
//
// When MLPV2 prints memory for a script as "(~scriptname: 10000 bytes free, 40000 byte limit)"
//      10000 bytes are available for the script's use.  If it gets stack-heap errors,
//          configure a higher MEMORY limit for that script's notecard.
//      40000 bytes is the limit: if this number is below 65535, you can configure more MEMORY
//          for that script.  If it's at 65535, you're maxxed out; you might have to reduce
//          (remove poses, shorten pose names, etc -- see wiki for tips)
//
// The "Adjust" menu button now prints free memory.
// During "Adjust" mode, ~memory script's limit is set to max, to allow storing new
// pose positions.  Its limit goes back down when you leave Adjust mode.
//
// Some scripts have hard-coded limits that can't be changed by notecard.
// If you get stack-heap errors for these, you can try modifying the script,
// increasing the number passed to llSetMemoryLimit().
// ========================

I don't even know if that's the version you're using, but if so, you may want to check inside whichever script(s) throw that stack/heap error, to make sure they don't have llSetMemoryLimit() below the max.

Now, I also found an old MLP-derived furniture item containing lots of anims from 2011 (so presumably based on some V2) that has five ~memory scripts. I'm guessing those may have been a custom extension by this furniture creator to solve the problem of too many poses for available memory. These particular scripts aren't open, so I don't know more about them.

Not that this is much help, but I was reminded of the alt (or main?) of the name I mentioned before -- whose profile at least still shows up, but it doesn't look much more encouraging I'm afraid.

 

[Phil Deakins]

Good find, Qie. The system was developed since the version I have. I think the one I have is his first one. It's actually called 'MLPV2.0'. The '2' being what he used to show that it's not exactly the MLP system.

So that's what you need to do first, Raena - max the memory for each script that produces the stack-heap collision. If that doesn't work, then maybe think in terms of seperate prims.

You can put the system into multiple prims of a linked object, and whichever prim you clicked on will be the one that produces the menu. Try it with a couple of linked wooden cubes.

One thing that might cause problems are the poseballs, because, if I remember rightly, they are not linked to the object. The original MLPV2 used poseballs. I don't know if later versions went over to no-balls.

Edited September 5, 2017 by Phil Deakins

[Raena Parx]

Thanks for the suggestions guys.  I did try adding  the statement: llSetMemoryLimit(65536);

into the Memory notecard, but nothing changed.  Will have to try it in the script notecards also to see if it helps.  Otherwise I think I'm stuck dividing the modules into 4 separate prims.  AND that means having FOUR prims with duplicate poses, and props.  Wondering what that's gonna do to the Sim's memory.  Sigh. lol

Thank you for all your help tho.  I really appreciate it.

[Phil Deakins]

Imo, considering the sim's memory on mainland doesn't usually matter these days, because most sims are sparsely populated with 'stuff' these days.

You may not know but setting the maximum memory to 64k doesn't mean that a script will use 64k. Mono compiled scripts only use the memory that they need. The earlier LSO compiler caused scripts to use all the memory available to them (16k each) regradless of whether or not it was needed.

[Raena Parx]

Seems like the most efficient way would be for MLPV2 to just swap out the memory used for one set of poses to the next set of poses (clear and reload the next set).  But no idea how to make that happen, so I think I'll need to use the 4 prims scenario.  Thank you again for all your help. I greatly appreciate everyone's input!!!!

[Innula Zenovka]

20 hours ago, Raena Parx said:

I did try adding  the statement: llSetMemoryLimit(65536);

into the Memory notecard, but nothing changed.

According to the MLPV2 Wiki article, you set the memory limits for the ~menu, ~props and ~swap scripts by entering commands in the formats 

MEMORY MemoryLimit  in the .MENUITEMS notecard to set the limit for ~menu scipt 
|MEMORY|MemoryLimit|  in the .PROPS notecard for the ~props script
MEMORY | MemoryLimit in the .SWAP script for the ~swap script

(note differences between the configuration of each directive, depending on the notecard.

Other scripts you set the memory using llSetMemoryLimit in the scripts themselves.

You don't say which script it is that's blowing up (the error message window should tell you) but I suspect it's the ~menu script.   Anyway, hope this helps

 

Edited September 9, 2017 by Innula Zenovka

[Raena Parx]

I attached a screen clip of the output just upon rezzing the table inworld.  Based on that I'm pretty sure its the ~props and ~memory that are exploding.  I will try the MemoryLimit commands you gave me when I get some time.  Am hoping that may fix the problem.  Thank you again for your help!!!

[Innula Zenovka]

Are "d1.f1_STAND," "d1.f1_BP" and the rest the names of animations?    If they are, are you using the same animation in different poses?   

It's ages since I've worked with MLVP but I seem to recall that if I wanted to use the same animation in two different poses, I had to install two copies of the animation with different names.   But that's a vague memory and I may have confused it with some problems specific to the chains plug-in.

[Phil Deakins]

3 hours ago, Raena Parx said:

I attached a screen clip of the output just upon rezzing the table inworld.  Based on that I'm pretty sure its the ~props and ~memory that are exploding.  I will try the MemoryLimit commands you gave me when I get some time.  Am hoping that may fix the problem.  Thank you again for your help!!!

Yes. You don't really need to enter a line of code about memory in those two scripts. Just remove any that exist in them. That way, they will each use up to the maximum of 64k. If either script still generates a stack-heap collision, then you have no choice but to use an alternative idea. Even if one or both of them still cause the collision, it's possible to move some of the code into another script, but that would take a good degree of scripting competence, so you are effectively stuck with an alternative.

If removing any memory restrictions actually works, then you will be left with the duplicates, and that should easy enough to deal with.

Edited September 9, 2017 by Phil Deakins

[Raena Parx]

On 9/9/2017 at 9:03 AM, Innula Zenovka said:

Are "d1.f1_STAND," "d1.f1_BP" and the rest the names of animations?    If they are, are you using the same animation in different poses?   

Each notecard used the same animations but in different positions.  In order to do this I renamed each animation with a prefix per notecard so they are all different.  I wish MLPV2 could just release the prior configs and load the new configs when it reads the notecards, but guess it's not that easy lol.

[Raena Parx]

On 9/9/2017 at 11:17 AM, Phil Deakins said:

Yes. You don't really need to enter a line of code about memory in those two scripts. Just remove any that exist in them. That way, they will each use up to the maximum of 64k

Thank you. I will definately try that.  I also read that shortening the pose and prop names may help save a bit of memory, so I'll be trying that also. 

[Phil Deakins]

Let us know the result when you've done it. In case it works, here is what you need to know and do about the duplicates warnings.

They are generated by the '~memory' script, and it's not duplicated animation names that cause it. It's duplicated position names. Those are the names on the menu buttons, which are taken from the '.MENUITEMS' notecard. Each animation line in the .MENUITEMS notecard has an line in the .POSITIONS notecard, and it's the position names at the start of those .POSITIONS lines that are duplicated. Here's an example .POSITIONS entry/line:-

{Sit up} <-.7,0,0.9> <0,0,0> <.7,0,0.9> <0,0,180> <0,-.7,.9> <0,0,90> <0,.7,.9> <0,0,-90>

It's the {Sit up} part (the words on its menu button that the user sees) that's duplicated in more than one entry in .MENUITEMS, and the warning occurs when the memory script is loading the .POSITIONS data into memory. It doesn't matter if the rest of the line is different.

So, say you have a set of animations for each of two sets, both of which are loaded at the start. If both groups have a 'Sit up' animation, then you'll get the duplicates warning, regardless of whether or not the animations and/or positions are the same or different. Changing one of the names in the .MENUITEMS notecard will make the warning disappear; e.g. in Set1 it could be called 'Sit up', and in Set2 it could be called 'Sit Up' (case does matter, I think) or 'Sit up 2'. When you change a name in the .MENUITEMS notecard, you need to save it in the .POSITIONS notecard, of course.

The fact that there are duplicates doesn't prevent the system from running. It's not fatal. The duplicate positions are still loaded, and the system will still run. Mostly it will work fine. Where it won't work fine, but will appear to have a bug, is when the user selects the 'Sit up' button where its position is not the first 'Sit up' in the .POSITIONS data. The system will always use the first entry in that data, so Set2's Sit up will use Set1's Sit up position.

Fixing the .MENUITEM names, dumping the positions and saving them into the .POSITIONS notecard, will clear the duplicates warnings. I hope that you get the stack-heap collisions sorted or I've just wasted half an hour writing this

ETA: Check which ones are duplicated in the sets. If the same position is right for all the duplicates, simply ignore the warnings. It'll work fine.

Edited September 12, 2017 by Phil Deakins