MLPV2 questions & bug reports

Waiting on a copy of Liz's .MENUITEMS* notecard and to get ingame to sort that out.

I assume you don't delete ~swap, which would cause this behavior.

Was that comment to me? 'Cuz I do delete it.

Will be sending you my .MENUITEMS. Thanks so much as ALWAYS Lear!!

OH MY GOODNESS THAT WAS IT!!!

When the ~swap script came out I never used it because I don't use the swap button in my menus the majority of the time. I did not realize that that script was actually essential to the working of the mlp2. Sigh....so much time I spent puzzled over this. THANK YOU LEAR for figuring this out for me. You are fantastic!

Thanks Lear, I tracked her down on the OSGrid forums. Her SL region appears to be gone now, but I sent her an IM, hopefully she's still active in SL.

OSG has their own version that they call MLP but it's really stripped of all the features of MLP, it's more just a poseball rezzer.

Is there any way to query a ball to see if someone is on it?

Or, to query a poser script or another script as a proxy and find out?

There is a way another script can track who's on each ball. See the Xcite script (the complicated one; I forget its name, the one configurable per poseball per pose). If you want to track each ball and who's on it, I suggest you start with that script and gut the xcite stuff out.

In theory, each ~poser* script knows, but I've never made use of that, or put handlers in them to answer queries. If you want answers to queries, rather than full tracking, that's where to put them. But full tracking is more efficient than frequent polling.

I'm assuming the script doing the querying is in the MLP object. If not, then you could have the balls answer the query -- but the querying object would need to know the MLP's key, to know which channel to use to talk to a ball.

That's what i ended up doing just now -- maintaining a list, using that exact snippet from that script you mention. I want to restart the MLP products in the stores automatically, and if someone is on a ball, give them a bit of a heads up what is about to happen...

Didn't want to build handlers into the standard MLP scripts -- would be more to have to remember to bring forward when I bring version updates :}

Thanks Lear!

I use menus with many animations in them. I use AUTOBACK and would love an AUTOSWAP feature (i know you support up to 6 poseballs - so maybe there could be default swaps for them - I just use 2 atm)

Thanks!

By default, the first two balls swap -- if that's not so, I goofed!

While it would be cool for the default swap to rotate all balls, I don't think that's simple to do given the way the configured swap feature is implemented. However, the default could easily swap even and odd numbered balls.

Just been doing some testing prior to making use of your scripts

CHAT Chat Info | OFF //switches chat info: ON/OFF (set default)

Just doesnt work
Im running latest version i believe (2.4n4)

Also, VERY weirdly, when using *none (or *+none) in the ~ball description field and selecting either of the 6-way demos, the 6th (and sometimes 5th) ball color isnt changed from default. With description of +none they color themselves perfectly. Mystifying to me.

If the CHAT default problem could be investigated Id be extremely grateful

What I was asking for was to have the SWAP button be put on every menu (like the AUTOBACK feature does) using something like an AUTOSWAP command.

Oh, I see.

Well, actually, I goofed the AUTOMORE/AUTOBACK thing from the get-go.

What I should have done is allowed you to specify any number (well, maybe up to 3) buttons on the AUTOMORE line, and those buttons (along with "MORE" would be automatically added at the end of each page. For example,

AUTOMORE SWAP STOP BACK

That would add 4 buttons to any page with an automatic "MORE" button, and 3 buttons to the last page.

IIRC, one other person wanted something like this -- probably Chaz. Don't hold your breath; I probably won't get to this right away, especially not until we find out how critical memory footprint is.

I'll look into it; thanks for the reports. PLEASE bug me (IM) if you don't see a post before long.

Hello - I am making beds with sex animations. I have my own set of animations, 122 couple- and 4-somes poses, 230 menu items.
The menu worked with a previous version without any problems.
But: I want to include xcite functionality, and therefore I would like to use the newest version vof MLPT.
But - when I insert the same .postions, .menuitems, etc. notecards the whole thing loads, but it never says "bed ready", and the menu never pops up when I click the bed. And no - lag ist not the reason, it does not even start after 2 days.
But: If I reduce the number of menuitems the whole thing works.

So - maybe I have too many menuitems. Okay. But why did it work in previuos versions? And there is no failure massage - it even says "121 positions stored (memory: 7820 bytes free)" and "230 menuitems loaded (~menucfg: 25150 bytes free)"
But... then nothing happens.

What's wrong? What can I do??

Tinah, do you get the script error indicator at the top of your screen when this happens? I suspect that ~menu is getting a stack/heap overflow. Each version of MLPV2 has more features and therefore a bit less memory for poses, though I thought someone reported well over 200 couples poses. Perhaps that was too many versions ago.

I’m working on an air mattress that uses only one repeated sequence. I made sure that all my animations are exactly the same in frames 1 and 2 with various lounging posses beginning at frame 3 and ending with the initial pose used in frame 2. One of the animations is the static rest (frame 2) pose that I use in between the other animation in the sequence. I’ve adjusted all the WAIT times to their appropriate lengths.

The problem I have is that the first time the animations play through the sequence there is a slight jump as the animations transition from one to the next. After the animations play through for the first time and repeats, the sequence transitions are all smooth as intended.

Is the initial jumping something to do with the way SL stores and plays animations or is there something else I need to take into consideration when making my animations to get the smoothest sequence possible? I thought that having the same 1,2 and last frames identical in all animations that it would ensure smooth transitions. What are some others things that I can do to get an initial smooth transition?

I'm not sure exactly what symptom you're seeing.

However, whenever SL needs to download an anim to a client (which it has to do the first time any viewer "sees" a given animation played on any avatar withing viewing range), it takes time, and the avatar hangs there unanimated until the anim is downloaded to the viewer. Thereafter, whenever that animation is used, it starts more or less instantly. This persists until the viewer discards that animation to make room for other stuff.

If that's what you're seeing, there's little to be done about it. The best you can do is to use animations that are as efficient as possible -- i.e., ones that are as small in data size as possible. These load more quickly, just as smaller textures load more quickly.

To make an animation as small as possible, it's best to use the lowest frame rate where the crucial motions are retained, and to keep the length of the animation as short in duration as possible. Even then, you're only reducing the time the avatar hangs suspended and unanimated -- not eliminating it.

Hi -- sorry I didn't respond to this earlier. Or perhaps I did, but only ingame.

I understand the issue: you want a state-dependent menu. So far I haven't thought of a good way to do this.

Thanks for the response. It most likley is the initial loading to the client pause that I am seeing as it only occurs the first time through. I could reduce the lenght of the animation clips but since this is counter to the effect I'm trying to achieve I guess I'll just live with it.

Latest version, posted to MLPV2 group, fixes the issues mentioned above. Forgot to save the updates before logging off, so this is from memory:

- CHAT buttonname | OFF (now works)

- removed object name from pose chat

- Instead of arrow keys adjusting, you now press both page-up and page-down to enable the arrow keys (shift left/right, up/down, and page up/down). Push page-up and page-down to disable again. This way, folks trying to adjust their view won't move their avvies.

- followed Liz's suggestion to use one list rather than multiple. I don't know why multiple had the severe overhead. When I tested it earlier, the two methods worked the same in Mono, whereas multiple lists worked much better for LSL. However, there's an issue here, and I expect this subject will come up again, related to memory handling differences for per-parcel script memory limits.

- Added Chaz's "ready" LM. The distributed version isn't the way I meant to do it (pulled the trigger too soon.) Chaz has the corrected version. I'll post the update soon.

- Fixed the issue with "+" in ball name, mentioned above.

Here's my .XCITE file.

debug=-1
timer = 15
pose = Ride 1 = * = 15 =100 = = =
pose = Ride 2 = * = 15 =100 = = =
/anim = sit_ground = 5|20|%o is sexy
anim = Ride Em Cowgirl = 15|100|cowgirl 2
anim = Rub_M = 15|100|Rub M
anim = doggie-fem-beging = 15|100|doggie fem beging
anim = Missionary_F = 11|100|Missionary_F
anim = Missionary_M = 11|100|Missionary_M

If I do the poses, every 15 seconds a fresh 20001 message is sent.

Example:

Testbed whispers: Ride 1
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: got LM 0: 'POSE'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: got LM 0: 'POSEB'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: Pose: Ride 1
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20014, 'JJ Annamemnon'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20014, 'Jagga Meredith'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: got LM -11002: '0|Ride_M'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: anim Ride_M on ball 0
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: got LM -11002: '1|Ride_F'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: anim Ride_F on ball 1
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20001, 'JJ Annamemnon|15|100||'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20001, 'Jagga Meredith|15|100||'
Xcite! X3 Clit: Beads of perspiration are starting to appear on Jagga's body.
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20001, 'JJ Annamemnon|15|100||'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20001, 'Jagga Meredith|15|100||'
Xcite! X3 Clit: Jagga is most definitely aroused.
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20001, 'JJ Annamemnon|15|100||'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20001, 'Jagga Meredith|15|100||'

If I do the animations, one 20001 is sent, and that's it.

Example

Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: got LM 0: 'POSE'
Testbed whispers: Missionary
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: got LM 0: 'POSEB'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: Pose: Missionary
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20014, 'JJ Annamemnon'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20014, 'Jagga Meredith'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: got LM -11002: '0|Missionary_M'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: anim Missionary_M on ball 0
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20001, 'JJ Annamemnon|11|100|Missionary_M'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: got LM -11002: '1|Missionary_F'
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: anim Missionary_F on ball 1
Testbed whispers: ~MLPT-Xcite-adaptor4 v0g: lm to xc: 20001, 'Jagga Meredith|11|100|Missionary_F'


What gives?

I'm using the supplied pillow.

My .PROPS file:

| pose_sit1_v1 | pillow | <0.000,0.266,-0.656>/<0.000,90,-0.1>

There's an entry in my .MENUITEMS file:

POSE PILLOW | pose_sit1_v1

The animation is there as is the pillow.

I'm a renter but can build where I'm doing this work even though the icons at the top of the screen indicate "Building/Rezzing not allowed". If I'm using something like a TV, it needs to be deeded to the group to work. The pozeballs rez just fine, so I don't think this is necessary.

What gives?

Here:

| pose_sit1_v1 | pillow | <0.000,0.266,-0.656>/<0.000,90,-0.1>


you should be referring to the name of the POSE, not the animation.

so

| PILLOW | pillow | <0.000,0.266,-0.656>/<0.000,90,-0.1>

Working as designed.

The "anim" based messages happen only when you start a pose using that anim. It was a very simply implemented suggestion from a user, so I added it. Originally, it only had the timed pose-based messages.

This should be clear from the MLP-Tools readme; I'll check that next time I'm ingame.

It's case sensitive. Use PILLOW in both places.