MLPV2 questions & bug reports

That would make the props script quite a bit more complicated. I'm not planning to do that any time soon. You get at most one object per pose.

The latest version supports up to 6 avs. I will not be adding more. The architecture doesn't really encourage it. I recommend XPOSE if you need more than 6 avs, unless you can achieve what you want using two MLPs in the same object (different prims). I've done this in my hot tub and it works great, but of course, the two MLPs aren't synchronized.

I did a trial linking two MLPs so that using the menu of one sent the same command to the other. Now, I'm a reasonably clever guy, but the complexity of setting this up and making it work reasonably required all my concentration, not to mention a number of rather odd changes to MLP that I didn't anticipate beforehand. I abandoned the project as asking too much of both MLP and the builders who would be trying to use it. Seemed like a nice idea, but no soap.

HOWEVER, there might be another way to do it, working similarly to the sequencer, but having it send the same commands to two MLPs in different prims. If you're up to scripting, I suggest you consider looking at the sequencer script and seeing if you might want to add a menu to it. You'd put this in a clickable prim, and the two MLPs in one that they normally wouldn't click. As the builder, you'd know which prims to click to control the configuration of each individual MLP. The biggest trick would be for the new script to find the object IDs of the two MLPs, which it could do by going throug all the object prims and looking for some string in the prim name, and building the channel number for each, remembering those, and sending all commands on each remember chat channel. (Note that this would extend to any number of MLPs.)

It would still be a lot of work to set up; you'd have to have a pretty clear understanding of MLP (just to set it up, never mind the scripting), and it would be confusing at times. User saving of .POSITIONS entries would be far too complicated for most users.

So, for these reasons, I think you'd be better off just going with a product that actually supports the number of avatars you want, like XPOSE. Really, I've given this a fair amount of thought, and I think that if you have this kind of requirement, you'll save yourself and your customers time and confusion by going with a good sollid product that was desgined to handle it from the ground up.

Be sure to see the latest, MLPV2.3f (actually, MLPV2.3g has a bug fix for a rare case; i forget just what, but it's not posted yet -- but if you ask on MLPV2 group someone will probably drop you a copy). Lately I've been too busy with a big project that pays the rent.

Concerning swap, MLPV2 only supports swapping the first two balls.

If someone can come up with a configuration architecture and coding concpept that allows configurable swapping, please pipe up. I'd love to make it better, but the current configuration model doesn't support it very well.

I believe that XPOSE allows swapping to be configured on a per-pose basis. I don't own any XPOSE so I have to reply on the reports from others, and I may have misunderstood.

I suspect the best MLPV2 will ever see is per-menu swapping configuration, though I think that should be good enough for most purposes. (It woud be good enough for my purposes, the times I've wished it could do more in actual use.)

Thanks for reminding me about this; it's at the top of my list of things to look into for MLPV2, next time I get back into it. Feel free to bug me again in a couple weeks if you don't hear anything on that! I saw this problem during development and fixed it. Either the fix got lost (I sometimes have too many copies out, and lose changes), or a subsequent change broke it. This is definitly supposed to work, and is the main reason for the AVWAIT command, so you can start a sequence, it posts the balls, and then waits for the required balls to be sat on before proceeding.

I assume your sequence chooses the appropriate menu before starting the pose. If not, that would be the problem. No need to reply if my assumption is correct.

BTW, I'm pretty sure the only necessary side effect of choosing the menu is to get the right number and color of balls. But I'd recommend that you still include a MENU statement any time your poses change menu, just in case I'm wrong, or in the future we find some other consequence it should have (e.g., configurable SWAP).

The menu does not seem to work in the latest version
... whenever you press a button in a menu, the action performs well but the menu goes away and one is forced to click the object to get it, falling always back to the main menu.
The REDO ON does not make a difference either.
Is it intentional or is it a bug ?

Bug. Get v2.3i from the MLPV2 group notices, which fixes that.

v2.3h fixes the bug mentioned above about poseballs not rezzing when starting a sequence.

Hi Lear

I'm seeing MLPV2.3h in the group notices but not MLPV2.3i. Will that be released today?

Also...just want to extend my ongoing appreciation of all the hard work you've put into this!!

~Desi

Hmm, I probably forgot to hit "OK". Seems I do that a lot. I'll post it ASAP.

This might seem very novice or possibly lazy on my part but when the updates come in (thanks so much!) is it possible to copy from say the Ball on down in the folder. That way I dont lose my menus or props and sounds or stomp on top of my other notecards?

The ~timeout script in the notice is no copy no modify.

Hi Lear,

The timeout that does STOP -- am I wrong in thinking that stop still leaves the listens running?

The balls unrez, so you lose one listen per ball. The ~menu script retains its listen, as do the ~poser..~poser5 scritps.

Yup, goofed. I'll fix that next time i'm in

Not lazy, smart.

For non-letter version changes, or if .MENUITEMS is mentioned as changing, it's a good idea to include that too (assuming you're smart and keep all your pose menus in a separate .MENUITEMS.whatever file). Some new features require a new options menu button, and you won't see it if you're using old options menus.

Not sure if this is currently supported, if so I haven't figured it out yet. Can you add a module menu ie: .MENUITEMS.myposes and have it show as a top menu item with sub menus? Something that would give a My Poses button that when clicked would open a sub menu dialog with buttons for my poses 1, my poses 2 etc.

Abolutely, and that's the best way to do it.

Start your .MENUITEMS.mystuff with the parent menu. Fill it with "TOMENU" statements like this:

MENU WhizBangInc | ALL
TOMENU WBI-cuddles
TOMENU WBI-fun
TOMENU WBI-freaky
TOMENU WBI-illegalin42states

Of course, don't forget STOP and BACK buttons, which should be on every menu.

Why STOP on every menu? It solves so many problems, and should be encouraged anyway. For example, if you use STOP, you don't get ejected like a James Bond villain if the poseball happens to be buried in the furniture. After moving or rotating a bed, STOP resets the position (I put in code to do this automatically, but there's no event that tells you when rotation stops). And no doubt, SL and MLPV2 have bugs, and I've seen funky and unrepeatable oddness that STOP fixes in a jiffy.

Plus it makes the poseballs go away.

The only problem with STOP is that it gives people the impression that the MLP is off, which it isn't. It's still running all those listens, contributing to lag in the sim.

When monitoring scripts in a sim, I often see STOP'ed MLPs spike over .2

[Monty Burns]Excellent.[/Monty Burns]

Thanks. So obvious when you see it but I started working on it late at night and I guess I was too brain burned to figure it out and just kept making hte same mistakes when I was awake.

Thank you so much for providing us with such a great tool.

Hello! Good New Year to you all!

CHAT Chat Info | OFF //switches chat info: ON/OFF (set default) in the MENUITEMS does not set chat info off after restart.

Would it be possible to create a prop controlled by two buttons, ON / OFF, that, whenever ON, would remain present in all poses? By other means rezz/unrezz an object but have the control in the MLP menu, independently of the poses running?

Last though not least a HIDDEN command for menus would be very much appreciated for building menus that do not show, with poses that are solely used in sequences.

Thanks for the update 2.3k! So far seems to be very stable!

Thanks; I'll look into that. A feature I never use, but a good one nonetheless.

Good idea, but it would really complicate the current props script. (I'd also like to have per-menu props, but whenever I start looking into it, I get dizzy.) It would be easier/better to do this from a completely separate rezzer script, controlled from the MLP menu using LINKMSG buttons. Use any popular rezzer script you can adapt to working from LMs.

If any scripter is interested in taking this on, I have a rezzer script that I pass out full perms that could be adapted for the purpose. (It would also want to be adapted to hear MLPV2's "STOP" link message, to de-rez the prop.) Let me know and I'll be happy to provide the script. I use a version of it to rez the water for my hot tub, but it's not connected to the MLP menu. Hmm ... Maybe I should! In any case, I won't be adding this to MLPV2 main scripts.

Yup, on my todo list for the next version. Right now, I'm working on configurable SWAP, since I thought of a way that wasn't very intrusive.

Glad to hear it! Happy New Year!

First, the spikes don't matter as much as the average.

Second, I tried the simplest means I could to make the poser* scripts stop listening on STOP, but didn't manage to make it work without problems like occasionally hitting STOP and getting stuck animated. Seemed simple and I'm not sure why it didn't work. I'll try again later.

But in any case, this is the kind of feature that really needs to be designed into the system from the ground up. Restart is a pain in the ass already, due to oddness with the way SL handles inventory and other matters.

As much as I'd like to add this feature, it would come at considerable cost in complexity, meaning it would be likely to add bugs. MLP is pretty robust for its complexity, and whenever I tinker with it, I try not to make major changes to the architecture to avoid adding new transition states and race conditions.

As a result, unless I try again and get luckier with the poser* scripts -- which seemed like a simple change -- I won't be likely to do this. It's still more efficient when not in use than SexGen (at least, compared to the one I bought a year ago). Making it more so is a laudable goal but robustness is terribly important and these kinds of changes are finicky.

Just a quick question, where can I get the latest version of MLP?

Lazink Maeterlinck MLP is now Xpose but im me in world and I will send you MLP if you need it.

No, XPOSE is a new product, redesigned from the ground up, and not open source & full perm like MLP: you have to pay for it. It's by Miffy Fluffy, the original developer of MLP. It has lots of features not found in MLP, including support for up to 15 poseballs, configurable SWAP, rezzing props, and no doubt many more. I haven't ever used it myself, but this is what I've heard.

The "latest MLP" is MLPV2. No rearchitecture, just cranking on it plus taking advantage of Mono to get the most out of the original architecture: new features and more poseballs (up to 6). It's still full-perm and open source.

I recommend against using old MLP, but instead upgrading to MLPV2 due to the added features like more poseballs, expressions, props, sequences, and (soon) configurable SWAP. No doubt, other new features I'm forgetting. Oh yes, it's also easier to adapt to Xcite, Sensations, and chains (no need to modify the MLPV2 scripts). New MLP is backwards compatible: you can use notecards from old MLP in MLPV2, though you won't get all the benefits. Most things will work the same, but there will be a few differences in behavior.

The latest at XStreetSL is currently 2.3f, but 2.3k is the latest. I'll post it to XStreet soon; it's the most robust of the 2.3 versions.

MLPV2.4 is now available to members of the MLPV2 group via group Notices.

This adds:

HIDDEN option for a menu (in place of ALL/GROUP/OWNER), for menus used only for sequences.

NOCHAT option for sequences (append "| NOCHAT" to the SEQUENCE line), to keep MLP from chatting the pose names as the sequence proceeds.

Per-pose configurable SWAP behavior, useful for poses with more than 2 balls. I wish I could have made it configurable per-menu, but couldn't think of a simple enough implementation. This adds a new script (~swap) and notecard type (.SWAP*).