MLPV2 questions & bug reports

for *long term* wish list, cause it's far from necessary --

a "rename" pose button
you'd click it, be told to type new name in chat
you do so, it confirms to you in text chat that both the pose and the position for the current pose (and any props) have been renamed
you work through them all, renaming, when you done, you hit a dump-all button, it prints out in succession positions and props as per normal then menu --- oh wait.

can't print out menu to screen. too complex. never mind.

I moved up to 2.4m2 the other day and I've noticed that the menu says it's 2.4l. Can someone tell me which variable and where needs changing to reflect the real version?

Or can someone tell me how to remove it as it's not something that customers really need to see. It used to be quite easy to remove but it seems that there's been a bit of a change..

How can I remove the output from the swap script on startup that says n swaps. As the script is only there to make the mlp work I don't want it giving customers spurious/unnecessary information.


My wish list would include an "about" button on the options menu. Which would display on the menu all usage/copyright terms and is documented in the .menu so it can't be removed. I don't know how hard that would be but it certainly would be a nice feature.

And I finally worked out why people have issues with the ball positions I think. I suspect it's that ~swap script. I've never been able to get any of the 2.4 series to work properly because I never have put the ~swap in. I don't like having any more scripts in the item than necessary and assumed because I didn't need to use more than 2 balls then there was not need for it as the built in couples swap would work fine. Of course now I put it in the thing works fine (except for the spurious output).

In 2.4, ~swap is absolutely necessary. If you delete it, poses will not work. In the first implementation for configurable swaps I tried making it optional, but ran into problems.

Thanks for pointing out that I forgot to update the version number (in an "unreleased" version, one posted to the MLPV2 group for testing purposes).

Well all the problems I've had down the months of trying to get each of the 2.4 versions to work seem to have cleared up with putting that ~swap in (there's a surprise lol). I know from the group chat that others have experienced the same problems as me so I can only think they haven't put it in either. Looking at the readme it doesn't state this and I can only assume that there's a few people who have been using it for so long that they made the erroneous assumption like I did.

my problems have been that it will save the positions but the balls keep reverting to 0.0.0 when the positions are reset and where it doesn't appear to read the loaded positions. I've got to say that I couldn't believe it when I put the ~swap into some old pieces that I'd kept with the 2.4 and they worked perfectly.. It was that "you idiot!" kind of moment



Group notices don't always make it to everyone so I must have missed that because I have no idea what the latest official release is. Although, apart from the 2.4l on the menu 2.4m2 seems pretty solid to me. I'm working on a 90 position solo and couple beast atm and it's been working beautifully - although I'm not done with it yet so I suppose anything could happen.

I have found that if I do a restart with the avs still on the balls when it restarts and I select a pose the avs both go into position - despite neither of them sitting on the balls and when they do sit on the balls it doesn't ask for animation permissions. I'm putting that down to the less than sub-optimal behaviour of our sub-optimal platform at the moment though rather than anything to do with the scripts.

Do consider the "about" though.. you could have it display automatically the mlp licence you grant and then a para underneath for the creator to specify the copyright and the usage. Fits in well with the new content management world we're moving into

OK, here's a warning about the unreleased versions.

(BTW, the latest released version is always the one at jPose Villa freebies section.)

It tries to stop lots of "unnecessary" scripts, more than just the poser* scripts. If you take it into inventory and then rez it, or if your sim restarts, next time you use it, it will set these scripts to running again.

Well, non-running scripts lose their state on sim reset or being taken into inventory. (And also crossing sim boundaries, which would apply to the HUD.)

This means that the scripts restart. That's fine, only, while they're restarting, the item doesn't seem to work at all. And things can get goofed up (I think) if you play with buttons while the scripts are restarting.

It's on my list to look into the best solution for this issue, but I've been busy with RL lately.

NOCHAT parameter on sequences turns off announcement of all pose selections, even those chosen manually via menu.

Not sure if this is intended behaviour.

Version: MLP 2.4n2

To reproduce:

1. set up a sequence, with the NOCHAT command
2. restart MLP
3. Choose a regular pose from the menu. It will be announced in green text.
4. Choose any subsequent regular pose or poses from the menu. They will not be announced.

I'm undecided if I like or don't like the non-announcement of poses. I actually might. If I don't, I will try to fix myself, as I understand there are likely further releases of MLP on the way (and I have frozen on this one for release.)

Just recording in case this issue has carried forward in subsequent releases.

Chaz.

That's not how it's supposed to work, Chaz, and while I'm sure I tested it, I either missed an important case, or it's subsequently broken.

Thanks for the bug report!

I am trying to fit a great many poses into one MLP engine. But I run out of memory in the ~memory script where the positions are stored. I am looking for a way to handle the position data differently so that an engine can handle a very large number of poses.

Yes I know LL is going to limit the memory usage, and that is one of the reasons I am looking into this. For example right now I have 3 beds just to hold the various poses I like to use. One of them actually has four MLP engines in it! What I have done is to put many of my poseball animations into the beds. So I have all everything all nicely stored away.

So I have to ask, what will use less memory, 1 very large efficent engine, or 7 smaller engines? I would have to think that the overall server memory would be less with only one engine running.. It would be about 1/7 the scripts running too.

I would like to avoid the devpose method, in which has each pose's information is loaded from a notecard when you select it, but that is an option. As it allows for nearly unlimited poses with very little memory usage, but there is a long wait when you change poses while the system calls the dataserver over and over. Which is also a big lag inducer it seems.

I am wondering if anyone in the group has any methods they have used to expand the data storage for something like this?

I am open to any and all suggestions.

Lizzy

I believe that one full one will take considerably less memory than a bunch of smaller ones, because there's a constant overhead for each MLP, and the amount of memory per pose doesn't change whether it's in one MLP or another.

Here's a tip for using less space in ~memory.

The problem is that saved positions used to use lots of trailing zeros. While trailing zeros are no longer chatted, if you have any "old" positions, saved using the old method, they have lots of trailing zeros. Positions are stored as characters -- at the time, it took less space that way. (It may no longer be true now, due to Mono and handling of unicode characters -- I'll have to look into that.)

Anyway, there's a way to "scrub" all your saved positions, without have to save each one individually. Use the "reorient" menu in MLP-tools (drop it in and menu-reset).

Use the reorient menu to adjust the poses, and then adjust them back (net effect of zero).

Then dump poses and copy to .POSITIONS* notecards.

Shorter pose names will take less room in ~memory.

While ~memory stores position data, increasing menu size can cause it to get a stack heap error (because menu button config is sent from config parser to ~menu via LMs, and a big LM will take memory even in ~memory, which discards the message ASAP).

Make sure you don't have any positions in your .POSITIONS* notecards that don't have corresponding menu buttons.

Finally, I got a report that MLPV2.3 handles quite a bit more poses than MLPV2.4. MLPV2.3 is still available on XStreetSL. I wouldn't expect a big difference, but if the report was correct, there is (over 200 vs. about 150). If anyone has any data on that, please post. I'll be looking into it.

Don't know if anyone else does this, or if it is good practice or bad practice, but I even -- when possible -- rename the actual animations to something short and sweet like Sit7-1 & Sit7-2. It may just be a superstition of mine that it helps save a tidge on memory, somewhere.

What's annoying is when you get a no mod animation named something like:
Caress8 fem5 couple animation animations|caress8 m13 couple animation animations

that I can't rename, haha.

Good idea. I've actually been thinking of that the past few days -- storing the anims away in MLP systems, instead of just in a box -- so that I can just go through, select the ones I want, and grab their positioning out of the position card. Would make future work a heck of a lot easier; wish I'd thought of it two years ago. Owing to memory constraints, I was thinking of organizing them by labelling one MLP system couple sits, another solo F sits, solo M sits, couple lays, etc.

Yes, I rename my animations when I can, some of the worst offenders are marked no-mod though. I do keep my pose names short, always under 12 characters and most under 8. My problem has never been the ~menu memory, it has always been the ~positions memory.

In looking at other systems I notice that most of those that handle large numbers of animations use multipule ~memory scripts. I have a feeling based on the count that they are using one memory script per ball. So that each memory script only stores positions for it's ball. So a MLP2 engine would have 7 memory scripts. One master and 6 slaves one for each ball. The only issue I can see other than a bit more overhead to this method is the number of Linked Messages flying about as you save, reset and switch poses.

I think ideally a method where only the current pose was stored in memory and the rest reside in a notecard would use the least amount of memory and allow for nearly unlimited poses. The only issue would be the lengh of time it takes to read. If only we had random access to notecards. or at least a "seek" function so we could go right to line n, in a notecard and not have to read each line one by one. Of course we could put each pose into a notecard, and that would solve the load time, but my god, 200 notecards to keep track of!!

I am also going to look into some "number games" see if there are any ways to store the postition information in another more dense format once it is in the script memory.

More on this later.
Lizzy

Well I may have found the answer/problem.
I dug, put in debug code and noticed that the memory used to store a string of position data was MUCH larger than the data itself. Almost twice as much.

So I did a little number checking. Then tried storing the data differently
Here are the results so far:
I used the Jpose hud as my test bed, it has lots of poses and 2, 3, 4, and 6 ball poses.
The File size of the raw position data as a windows file 9.75 KB (9,987 bytes)
Base Memory before any positions are loaded : 0 positions stored (~memory: 38350 bytes free)
Stock [19:02] MLP 2.4m2 (new memory test): 83 positions stored (~memory: 17934 bytes free)
That equals 20,416 bytes to store 9,987 bytes of information. That is over a 2:1 ratio.. Something is wrong.

[20:22] MLP 2.4m2 (new memory test): 0 positions stored (~memory: 39086 bytes free)
[20:23] MLP 2.4m2 (new memory test): 83 positions stored (~memory: 30904 bytes free)
That equals 8,182 bytes to store 9,987 bytes of information. This looks more correct as some of the string is not stored, the time, spaces, etc.

Test of a a position save
[20:51] MLP 2.4m2 (new memory test): {Sit-hold1} <-0.092,-0.072,0.397> <0.,0.,0.> <0.15,-0.073,0.389> <0.,0.,0.>
[20:51] MLP 2.4m2 (new memory test): 83 positions stored (~memory: 30904 bytes free)
Memory holds

Everything works just fine..
Here is what I think is happening..
The memory script stores the position data into 4 lists in an alternating manner.
The first pose goes into list0, the next into list1, the next into list2, etc.
This is causing the heap to fragment, a known problem with both LSO and Mono languages as they have no garbage collection and are not very well structured for memory managment.

So what I did was to store all the position data into one big list.
Everything still works fine, the poses switch very fast, and there seems to be no problems
And the memory usage is correct. The memory used is the size of the data now. Not the size of the data times 2.

Lear will have to go over this of course, but this looks very promising.

Lizzy.

Edit..
If this works like it seems to, we get twice as many poses for the same memory, or half the memory usage for the same poses depending on how you want to look at it. I will keep on testing and report any problems I can find. Until Lear blesses this I would not recommend anyone trying this in a release item.

It's expected that ~memory would take about twice the space as an ASCII file, because Mono stores strings using two-byte unicode characters. (Or something like that, please feel free to correct my terminology if I'm not quite right.)

Storing to multiple lists was extremely important pre-Mono, because appending to a list required twice the space of the list. Dividing the list into 4 lists was a dramatic improvement.

When I tested with Mono, I saw no significant difference in memory usage between using a single list and using 4 lists, so I left the 4 lists in. However, with Mono, if it requires twice the space temporarily for list appension, that space usage was *not* reflected in llGetFreeMemory() results. With Mono, memory usage is only recorded when the script returns control to the system, e.g., completing a state or calling any function that causes a delay.

This is planned to change, due to the memory issues related to Mono (space usage causes server thrashing).

So, I'm reluctant to change this until we find out whether the 4-list split optimization will be beneficial or not, after upcoming changes to Mono.

It's possible that some of these Mono changes are already in effect. I haven't seen much on the forum about any progress on the proposed changes -- it seems like it's been back-shelved while they deal with the adult content clusterflock.

In any case, thanks for the feedback! It bears looking into further.

I still want to figure out why there's such a big discrepancy between MLPV2.3 and 2.4.

My point above is that it's hard to tell the difference between the two, since ~menu gets its config in an LM, and that LM, if too big, can crash ~memory.

If it comes up completely and ~memory crashes when storing a pose, then it's entirely positions memory.

That's how DevPose works, loading only the current menu's worth of data. The wait when switching menus is annoying.[/QUOTE]

We do. See llGetNotecardLine().

Hmmm, ok much to think about. I do wonder why now using only one list shows such a drastic memory usage change. I will push the list to the limit and see where that is as far as doing replacements.

SL is a total train wreck this morning, so I am going to hold off on my next phase of testing until things improve.

I am planning on pushing it hard with the next test, to try to see what the limits are.

I will also take a look at using the llGetNotecardLine() and see what the ramifications are to using such a system.

Thanks for your input on this Lear, I hope we can come up with a solution that will allow for more poses without increasing the memory used by much. I really wish to consoldate my favorite poses into one system. It would be much more efficent that what I am doing now with multipule engines and a lot more convient. And if they implement the memory limits in typical LL fashion (ie. badly) then we are all going to need a way to do more for less.

Lizzy.

I have a random sound object that I use in conjunction with MLPV2 to play my sound clips. I can easily start the sounds in a sequence using the “SAY | ch | chat” command.
I’ve also figured out where in the ~menu script to insert my “llSay(69,”stop”) that turns off the sounds when the STOP button is used to end MLPV2.

My problem is where to put an additional llSay so that the sounds will be stopped if someone exits an animation by using the “Stand up” button. I am currently using MLPV2.4k. Any pointers to where and in which scripts MLPV2 reacts to the stand up?

Monique, I suggest that rather than modifying MLPV2 scripts, you add a script that listens to its link messages and responds. That will make it easier for you to upgrade to a new version for new features or bug fixes, or to deal with upcoming memory handling changes in the sim sever.

Take a look in MLP-Tools and see how the xcite scripts detect the avatar getting up.

Or, get a copy of the jPose BDSM Rack, which has a chains script, which also reacts to that case. (When I get ingame next, I'll take a look and post back; I don't remember offhand how it works.)

You can also see how these scripts detect STOP.

I have inherited a 3some menu set up like this:

MENU MFF CUDDLES | ALL | BLUE | PINK | PINK
POSE Cuddle 1 | male-cuddle1 | fem1-cuddle1 | fem2-cuddle2

I want to swap the balls around to be
MENU MFF CUDDLES | ALL | PINK | BLUE| PINK
(for brevity, I won't explain why, but I can later if anyone wants)


The recorded position, which I have, is
(square bracket comments added here just for illustration)

{Cuddle 1} [blue ball] <-0.448,0.255,0.5> <-0.1,1.7,1.8> [/blue ball] [pink 1] <0.403,-0.275,0.519> <1.1,1.3,139.8>[/pink 1][pink 2] <-0.445,0.332,0.362> <0.,0.,1.7> [/pink 2]

As blue was the first ball, I'd think it would be as easy as moving the blue ball bits to be in the middle, like this

{Cuddle 1} [pink 1] <0.403,-0.275,0.519> <1.1,1.3,139.8>[/pink 1] [blue ball] <-0.448,0.255,0.5> <-0.1,1.7,1.8> [/blue ball] [pink 2] <-0.445,0.332,0.362> <0.,0.,1.7> [/pink 2]

and restarting.

But nope, positions are all off.

Okay, maybe I need to swap the pink 1 and pink 2 of the recorded position around as well.

Nope, positions off as well.

Any thoughts? I'll keep on trying.

It should work. However, be sure to keep the whitespace the same -- the same number of spaces between ">" for one ball and the "<" for the next. I don't think the script is very forgiving in that regard. If it fails to scan the line, the ball will probably take the "default pose" position for that ball number.

BTW, to speed things up, once you have the menu set how you want it, just do a "pos reset" after changing .POSITIONS* notecards.

You're correct that the positions for the balls are in the same order as in the menu. I bet it's just a whitespace thing.

Yep works now if I replicate the spacing exactly!

cheers thanks!

It's not how I would have written it ...

I forgot to put a prop in:

[16:49] MLP2.4n2 whispers: Warning: can't find prop 'Relaxing Pillow' in inventory
[16:49] MLP2.4n2 whispers: Warning: prop 'Relaxing Pillow' is no-copy!
[16:49] MLP2.4n2 whispers: Warning: prop 'Relaxing Pillow' is no-copy for next owner

1st msg right; next two incorrect.