MLPV2 questions & bug reports

Unfortunately, this only works the *second* time you visit the synchronized pose. The first time you use any synchronized pose (on a dance ball, MLP, whatever), the animations will NOT be synchronized unless they're very small, and both viewer and server are running "green".

This is because, as I mentioned above, each animation has to be downloaded to the viewer, and the viewer starts the animation when the download ends. They'll only appear synchronized if the viewer finished downloading them both at the same time. And this applies to the viewer for everyone watching.

I've watched synchronized poses from two viewers (playing alts) on the same machine, and they're in sync on one viewer but not on the other. (I'll see expressions on one but not the other, too, and this is typical -- I wonder why. Clearly an SL bug, not MLP.)

The only way to synchronize poses is to start them, then change to another pose (using different anims), and then change back.

Of course, Chaz's method still works -- just not the first time, for any given pose.

It is possible to fool SL by downloading the same anim twice and alternating between them. So, you could do this and make the pose a sequence, alternating between two identical animations using different downloads.

It is not possible to fool SL by copying an animation and renaming it. It works based on the UUID of the anim, not the name.

Finally, in case I forgot to mention it in my earlier post, you can make a sequence and use AVWAIT and list each ball you want occupied before the sequence continues.

The first issue is the NOCHAT one, mentioned above.

The second is this: after you run 1 sequence, you cannot run another successfully unless you stop (or restart the mlp). Any sequence you attempt to run after the first will start, then stop itself after the first pose.

here's what I see happening on the second sequence:

[9:38] MLP2.4n3 Object: testing: in timer
[9:38] MLP2.4n3 Object whispers: ~sequencer: WAIT|30
[9:38] MLP2.4n3 Object: testing: in timer
[9:38] Nuzz Stand
[9:38] Pool side 1
[9:38] MLP2.4n3 Object: ~sequencer: user stopped or selected a pose
[9:38] MLP2.4n3 Object whispers: ~sequencer: stopping sequence

(Note in the above that the menu wasn't touched; I didn't select a pose or interfere with the running of the sequence -- in fact, I'd settled back with a coffee to watch them to proof them.)


Versions: 2.4n2 / 2.4n3

Ok, here is one that I am wondering about.

I want to incorporate those pretty particle chains that you see with the Lockmeister cuffs. However, the way I intend it to be is that a prop has the emitter points for the chains on it and the avatar wearing the actual cuffs sits on one of the pose balls.

Is that possible at all ? if so, how ?

If it is not possible, I would probably revert to having the emitter points on the main device (such as a bed). But I still dont know what script/plugin/converter is needed to make it work.

Any help is much apprechiated. I am using 2.3.

I have props with chains. The problem is, with the simple system I use (and only for a couple poses), the sitter has to click the prop to hook up after every pose change.

I imagine there's a way to do it without that, but I haven't thought of one, or worked on it.

At jPose Island, there's a BDSM rack, using MLPV2.4, with a chains script, but I believe it relies on the chain points being linked into the MLP object, not a prop. (Feel free to buy the rack and use the script, but you'll have to figure it out yourself: it's not documented or supported as a standard part of MLPV2.)

For a scipt like this to work with a prop, it would have to use llWhisper() rather than llMessageLinked(), and it would also have to wait until the prop rezzes -- which would add a bit of complexity. But, it should be doable. If you're not a scripter, you're pretty much out of luck unless someone wants to take that on.

_________________________
UPDATE: FIGURED IT OUT

Issue occurs if you do something like this, having a waiting pose that is different from the starting pose.

SEQUENCE | LOVESCENE2-seq
MENU | LOVESCENE2
POSE | Nuzz Stand
AVWAIT | 0 1| Waiting for someone to sit on ball
POSE | Pool side 1

If you make the waiting pose the same as the starting pose (which means picking a starting pose where the balls are visible), then you can avoid the problem. So that's what I've done.

So provided people are aware of this, I'd say the only issue I know about with sequences is the NOCHAT thingy. I can live with it though -- having the sequence pose names show as they are run through. In fact, I'm kinda used to it now.

_________________________

I don't think that's quite it, Chaz, though I'll check.
Please drop me a set of notecards that don't work. Thanks!

Only seems to work if the sequence ends with the same animation that it begins with.

Example of a repeat that works:

SEQUENCE | VISITORS-seq
MENU | VISITORS
POSE | JustHanging
AVWAIT | 0 1| Waiting for both people to sit on balls
LABEL | here
POSE | JustHanging
WAIT | 9
POSE | NiceWeather
WAIT | 9
POSE | Couple01
WAIT | 9
POSE | Couple03
WAIT | 9
POSE | CoupleFloor
WAIT | 9
POSE | Movie
WAIT | 9
POSE | SitOnKnee
WAIT | 9
POSE | Couple02
WAIT | 9
POSE | JustHanging
GOTO | here

Say you have a sequence of 20 poses, with 60 seconds wait between each pose....

Well, that's a chunk of time to sit and watch it all to proof it.

Pop the sequence into notepad;
Do a search and replace on WAIT | 60, to, say, WAIT | 6
pop that into sequences card;
reboot
run sequence -- it will go fast with only 6 seconds between each pose;
when it's right, in notepad replace WAIT | 6 back with WAIT | 60, replace that back in sequences card, save, reboot, you done.

Obvious, I know, but took me a few evenings to go, duh!

You can also just click the RESUME button to advance from a WAIT or AVWAIT. Note that this is for checking your sequence, as opposed to verifying that MLPV2 scripts are working properly.

Ah. That's even better.

Oops, it's "RESUME", not "CONTINUE".

Well, that wasn't quite the problem.

The problem happens when you go from one sequence to another without stopping. The previous state gets pushed for a NOCHAT sequence, but not popped if you pick another sequence without a STOP in between.

Stopping or picking another pose pops the previously pushed state, which is wrong in this case, and things get further fubared the more you switch between tours without STOP or a normal pose between.

I'll fix it; thanks for the report.

Chaz was dead on about the loop problem. Thanks again, Chaz.

I have a fix, will distribute to the group soon, and probably release to public as well.

If you don't put waits between poses, the sequencer gets confused by signals coming from ~menu about old poses.

In the fix, AVWAIT has a small delay built in to avoid the problem. But it also means, don't run poses one after each other without WAITs between. (Wouldn't make much sense anyway, except for resynchronizing.)

I discovered answer to the following below through experimentation:

if you have poses already defined under regular menus, if you want to use those poses again in sequences, then you *don't* need to redefine them under special menus created just for sequences. Under menus specially for sequences, you only need to create poses that aren't defined anywhere else.

______________________________________


If you are make a sequence, out of poses already defined on regular menus do you need to redefine the poses all over again?

For instance

POSE Hug|Hug1|Hug2

say it is already in a user submenu

when you define a sequences menu, such as:

MENU SEQUENCES1|HIDDEN|PINK|BLUE

do you have to do this:

POSE Hug|Hug1|Hug2

all over again?

Right, Chaz -- don't know where you got the idea they had to be in special menus. A pose just has to be in a menu somewhere.

See for example, the example in the distribution: it uses poses from menus, and there are no menus that are just for sequenced poses.

Lear,

I've taken a stab at fleshing out the part of the tutorial covering creation of sequences menus.

When you have the time, could you make sure I'm not giving any wrong information?

https://wiki.secondlife.com/wiki/MLPV2_Tutorial#SEQUENCES_.28MLPV2.3.29

I seem to be a bit of a trail-blazer here with sequences, and with any luck, I can save others following some work.

Chaz

Thanks, Chaz -- I'll look it over!

I'm working with a friend on making an item of furniture that can change its shape quite radically. What ideally I'd like to do is to send a link message back to the ~menu script when I call llSetLinkPrimitiveParams to set a value -- "round" or "square", for example -- so the script knows whether to load the Cuddles_round menu or the Cuddles_square one when the end user simply presses a menu button "Cuddles".

I can see how to do that -- at least I think I can. If (round == TRUE) I will, under certain circumstances, add "_round" to the button string and have the script look for the Cuddles_round menu, which will depend on .POSITIONS.Cuddles_round. But what I can't see how to do (and maybe it isn't readily doable) is how to hide Cuddles_round when the script reads the various notecards at start up -- I just want one button, Cuddles, to be presented to the user.

Related to this, and if what I'm trying to do isn't possible, then it doesn't matter, is I'm not at all sure if it would be better to have a Cuddles menu and a Cuddles_round menu or to have Cuddles_round and Cuddles_square, both hidden, and a simple Cuddles button that gets the value of its message changed as appropriate.

I hope I'm making sense here.

Can anyone advise me?

First, the extensions on the notecard names are meaningless, except to affect the order in the inventory (which is the order they're read).

It reads all the .POSITIONS* notecards and doesn't notice the boundaries between them. It's the same as though they're all concatenated together.

The multiple notecards is only for convenience in making modules, and also so you can put your poses in a separate .MENUITEMS notecard from the OPTIONS menus (making it easier to upgrade).

I don't think MLPV2 is suited for your purpose. Maybe someone can think of a trick to make it work, though.

Easy one i think, and not worth a release on its own, just to be snuck into a future release:


When the menu script pronounces MLP ready to use, here:

state_exit() {
llWhisper(0,""+llGetScriptName()+": "+(string)llGetFreeMemory()+" bytes free)";
llWhisper(0, Version + ": READY";
}

if it could also send a link msg saying ready.

That link msg could be used as part of an API to trigger other scripts, etc.

Yes, good idea Chaz. I'll do that in the next; and please remind me if I forget!

Has anyone had success with running MLPV2 in Opensim? I have been having an awful time about it. It took a ton of editing just to get the scripts to compile. I had to "undeclare" as an integer "ix" in a number of places since OS doesn't like to see if declared as an integer multiple times after the first declaration in a block. Same thing for data and name as a string and buttons as a list in a few places.

Anyway, I'm sure I have it all muffed up pretty good. Its compiles with about 30 warnings about OSSL and LSL differences with multiple assignment of variables.

Whenever I reset it, it comes up fine in the off mode. I click to start and it goes through startup just fine. Then when I click on it to start an animation, I get a popup menu with the last .MenuItem listed, no matter what it is (it's not selectable, just the text is there).. and the BACK and IGNORE buttons, nothing else. Clicking the BACK button just brings up the same menu again.

I do most of my testing of new animations and builds on my OS grid now, so it would be so awesome to be able to run MLPV2 there.

OS Grid info:
Build 9993
Script Engine - XEngine
Compiled scripts in both Mono and LSL with the same results.

Thanks if anyone has any tips. And please, don't assume an overabundance in intelligence on my part. If you think of something simple, chances are I haven't, so would love to hear any rudimentary tips as well.

Patasha

This one, one would want to see if enough people wanted it.

The feature request would be to have cleaner chat, as XPOSE does:


• XPOSE needs the ":XPOSE Xchat Interface" to chat info messages.
The Xchat Interface produces cleaner chat messages, without "object name:" in front of the message.

Now, I know that many people like their products to always say the product name, so perhaps (if wanted at all by enough people) it could be an option at the top of the .menuitems notecard, such as AUTOBACK is, for instance.

Xpose does it like this (from the Open Interface script called ":XPOSE Xchat Interface"

while (name == empty) name = llGetObjectName();
llSetObjectName(empty);
if (cmd == "1"
{
llOwnerSay("/me " + (string)msg);
}
else
{
llWhisper(0, "/me " + (string)msg);
}
llSetObjectName(name);


But again, it may be that only a very small handful of people would want this cleaner chat.

Help!

Has anyone else had issues with the ball wanting to remain at 0,0,0?

I am not new at using mlp2--I have been using it since it first came out but for over a month now I am having the same issues.

For example: today I took Lear's MLPv2.4n4(~menu fixed). I adjusted the positions in the "Example..." menu and it works fine (saved, copied to notecard, etc and positions then work fine). BUT when I replace the .MENUITEMS.example notecard with my own and place my animations in there and I save and copy/paste the positions for those poses in the .POSITIONS notecard when I do a PosReset or reset the scripts and use the menu the poseball does not move past the 0,0,0 location. I am having this issue regardless of which MLPv2 version I use.

Please help as this is a huge issue and is rendering MLPv2 useless for future products for me.

Again, the ONLY thing I changed from Lear's MLPv2.4n4 was adding my .MENUITEMS notecard and added my animations. I'm happy to show you a copy of my .MENUITEMS if that is helpful.

Many thanks!

~ Desi

Not that I heard, so far. Someone was trying it but I don't remember who.

That's unlikely to work. Intead, rename either the inner or outer variable. It's too bad that you can't disable this warning.