MLPV2.2 Enhancements

### THREAD CLOSED ###

Please post feature requests in "MLPV2 Feature Requests" thread:

/147/f7/269545/1.html


Thanks!

###################

Here's what I'm planning for MLPV2.2:

1) LMs when folks get on & off balls, giving av key, ball number, and pose name, to make it easy for folks to add support for worn devices like xcite, locksmith, and sensations. I'll provide an AutoZhao compatibility script as an example. (AutoZhao automatically turns off when you sit on an AZ-compatible device, and back on again when you get up.)

2) MLP Chaining, so that you can use two MLP prims that will be coordinated -- essentially giving you more than 4 avatars. Admittedly it won't be as clean to set up as if it supported more avs intrinsically, but going much higher would take a bigger rework than I'm interested in doing at the moment. This is a pretty simple change.

3) I *might* add support for one or two more avs.

Comments and suggestions, please!

I'd be ecstatics with being able to set up 6 AV / mlp2.2 instance.

I've been recently contemplating using 2 mlp2.1's together to be able to have small groups of friends use furniture for cuddles and whatnot. Being able to have two coordinated together with 6 AV's per would be fantastic!

Thank you for continuing to develop MLP!

using the miffy multipose script MLPV2 Version 2.1c with version Second Life 1.21.2 (96080) Sep 9 2008 09:58:58 (Second Life Release Candidate) about every other pose causes the user to lose hair. I went back to the regular SL release version and no problem with losing hair. Running a mac osx with latest OS version PowerPC G5 tower with ATI Radeon X800xt video card.

Is there someplace I can get the MLP scripts you are working with? There seems to have been an asset server bork and now the database cannot locate the ~pos script in all of my MLP based items.

I'm also having the missing hair and sometimes missing shoe issue with the new update.

Johan - you can find the most recent MLPV2 here: www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=692115

And what tips would you like regarding this?

Amara, I prototyped the chained MLPs, and I think I'm not going to do it. Turns out to have a lot of complexity and usability issues. (It works ... I just hate to think about the kinds of problem reports I get for it!) So, maybe I'll add an av or two. Maybe ... Either that or try a slave MLP unit. (Still, there would be issues with that. E.g., ou'd need to keep the two prims in the same orientation.)

Johan, join the MLPV2 group and look for "Old" in the notices. Do this within two weeks or it'll be gone (notices time out).

Blaze, please discuss bugs in the MLPV2 questions & bugs thread, scripting tips forum. However, I don't see how it could possibly be an MLPV2 bug. I have some questions, though; please post in another thread so we can discuss it.

Ordinal, are there any new features you'd like to see, or suggestions regarding the proposed features?

Lear, I've been reluctant to hit you with a feature request what with all the work you've done thus far - but since you mentioned it directly...

Any thoughts on support for timed sequences of animations? It's something I've been thinking about attempting to tackle myself for a good long while, but I haven't had the time to really dig in to the MLP and look for the best way to go about it. It certainly seems like a highly desirable feature, especially considering the extremely popular and highly-regarded products of a certain well-known couple's animation designer that depend on timed sequences for their effect.

This isn't really a request on my part, as I've no immediate application for either of the following, but what I hear most is people asking for ability to handle sequential, and for ability to trigger sound.

Good suggestions.

Sounds are a likely candidate. Shouldn't be too complicated -- just a button like POSE, only it plays a sound. (Without any mods, this would be real easy to do with LINKSMG and a simple script, but building it in would make it accessible to non-scripters.)

Sequences -- hmm. Probably unlikely. Seems to me the kind of change that would require a lot more complexity in both configuration and execution. But, I'll give it some thought.

For my sequences, I just let the folks cycle through a set of anims at their own pace. Frankly, that's one of the things that got me into this in the first place: hating that LoveScene rushed me through several favorite phases!

Ah thats cool. Even 2 more AV's would be fantastic. Again thank you for your continued development of MLP

Okay, I came up with a feature request. That hitting adjust pose would toggle the beams off and on. Many times after adjusting a pose for personal use I want to beams to *go away*.

Good one Chaz. Currently the only way is to hop off and back on.

For this to work well with just one button that flips from adjusting to normal state, ~ball would have to be adjusted to stay in adjust state regardless of people hopping on/off or balls rezzing/de-rezzing for poses in menus with different ball counts. Ideally, I think, STOP would put them all back in normal state.

Frankly, I don't bother with "adjust" any more -- I just drag to select the (tiny) poseballs and move 'em.

And YW, Amara!

OK, here's an idea about sequences. Could be done with an additional script, configured with a sequence of menu & pose buttons to "push", with timers. An LM button could kick off a given sequence.

So, something like this, configured in a .SEQUENCES.* file:

SEQUENCE toss-n-turn
MENU Cuddles
POSE spoon-right
WAIT 30
POSE spoon-left
WAIT 30
REPEAT

SEQUENCE romance
MENU Cuddles
POSE chat
WAIT 60
POSE sit-kiss
WAIT 30
POSE lie-kiss
WAIT 60
MENU MF-sex
POSE missionary
WAIT 180
POSE doggy
WAIT 180
MENU Cuddles
POSE lie-kiss
WAIT 30
POSE man-passed-out-woman-filing-nails

Would that do the trick?

ok just have to laugh at that last pose in the last sequence. smirks.

What, don't you file your nails afterwards?

Smirks.

Sorry for not responding earlier (since I was the one who brought it up); my browser cookies must have borked, when I checked for the newest replies a couple of days ago I shot right past this to page 2 and saw only a wink and a smirk

Anyway...

That would be brilliant, Lear, thanks so much for taking the time to consider my request. And as much as I personally, well, disapprove of non-interactive animation sessions in some contexts, I think something like this would open up new opportunities for extended series of animations that are designed to work together. Think randomized stands in an AO, but with cuddles instead...

Hey that's something to think about while deciding how to organize and parse the new notecard data: a RANDOM flag?

Please accept my apologies if I seem too presumptuous with suggestions like this, especially right on the tails of my previous request. Your hard work thus far is very much appreciated; I only bring it up now for your consideration since allowing for another parameter right now makes more sense to me than waiting until a bunch more work has gone into things and much depends on the particulars of the notecard format and list indexes and such. And of course it goes without saying that you may still decide this whole sequence thing isn't a worthwhile or attractive venture after all.

Something to think about anyway...

I'm the one asking for input, so don't worry about presumptuousness! Ideas are always welcome.

The sequence thing came up recently because a friend also requested it and I asked why, and her response was illuminating: she was thinking of using it for machinima, using bot alts as participants. I particularly liked that -- it shed new light on the feature as being able to be used in imaginitive ways!

I confess I'm more inclined to do things I think of as fun rather than things that are "good for business". Thus taking so long to getting around to xcite, but I'd seen people spend so much time dealing with script updates over that stuff that I broke down and addressed it despite the fact that I'm not really interested in using the feature myself ... usually. (Heck, I also admit I enjoy doing whatever my, um, guest thinks is fun!)

News update:

I have an Xcite partner adaptor script working, to serve as an example for anyone wanting to add Xcite to MLPV2. You'd still have to work with Xcite! to get authorized as an XCite! partner to use this. MLPV2 has been modified to make this kind of thing a lot easier -- you no longer need to modify any of the MLPV2 scripts. I will probably also add Sensations support. It's notecard configurable, per ball per pose. This is not yet available in beta, but should be soon. (The MLPV2 that the adaptor script works with has been provided as beta in the group notices, probably timed out by now. If there are any XCite-authorized partners who want to work with this, please let me know either here or by IM ingame.)

I also developed a feature that allows you to rotate all the entries in your .POSITIONS* files for the case where you've re-oriented the MLP prim. For example, many engines are oriented like the default box, with Z axis pointing up. Many older beds have MLP in elliptical mattresses, which have Z axis pointing either to the head or foot. And most Sculptie mattresses and sofa cushions have Z axis pointing to head or foot, but with the face with the texture seam on the bottom -- which might be 180 degrees from how an elliptical mattress might have been oriented. Well, if you develop a set of positions for one orientation and want to re-orient them for a different one, you'll soon be able to do this using menu buttons. I will probably make this tool available as an add-on module, since it applies more to builders than end customers. I might also add the ability to shift the positions (offsets) in any direction by any amount, since it's a simple extension.

However, it might be useful to end customers who want to add a module (set of anims and config notecards) to an existing piece of furniture. So far, I haven't thought of a method for doing this that's simple enough for customer use, though -- because it rotates ALL your poses, not just the "new module". (MLPV2 doesn't know which notecard a pose came from, once it's done, and I hesitate to add that kind of complexity.)

So, future work under consideration include:

* 2 more avs
* adjust beam toggle
* sequences

I may release V2.2, mono-compiled, first. However, I have some reports of temporary malfunctions, and I need to get to the bottom of that before starting any of the above projects. But please keep the ideas coming!

I have done a simple modification to the ~poser scripts that gives me a link to Xcite!

It works well and will also provide animation and avatar information to any external addon script. All of my Xcite! processing is done by an additional script to provide the link to the partner scripts.

(code snipet)
link_message(integer from, integer num, string an, key id) { //an animation is set
if (an == "PRIMTOUCH" {
return;
}
if (num != ch) return;
an = getExpression(an); // get & save expression, and return unadorned anim

if (avatar == llGetPermissionsKey()
&& avatar != NULL_KEY) {
llStopAnimation(animation);
startAnim(an);

llMessageLinked(LINK_SET, 40001, an, llKey2Name(avatar)); // Link to external script for Xcite! or other script

}
animation = an;
}
(end of code snipet)

Ravanne, I strongly recommend you to get the latest MLPV2.2 beta from the MLPV2 group and use that rather than your solution. Here's why:

1) It supports more than just XCite, because it gives the ball number, which helps with chains. It also allows more specific XCite configuration.

2) You won't have to modify the ~poser scripts each time there's an MLPV2 update.

3) You might find a bug and report it, in which case I can fix it for everyone.

I must be missing somethng but I am seeing little that would help with Xcite!. I get the ball number and avie key when I sit and then get the selected pose with no other useful information when a pose is changed. With the mod I use I get the Avie name (could easily be changed to avie UUID if needed) and the pose that that avie is put in. I can see that there might be uses for the avie/ball information but for Xcite! it really is not useful. Perhaps a combination of the two would be more useful and flexible.

Your code can easily get the avname using llKey2Name(). It can get the pose name by listening to the POSEB messages. An animation could be used for different purposes in different poses, so this is more information. However, it's a good idea to also pass the animation name in the message, so I think I'll add that.

Thanks

I use the animation name to key the Xcite response. This makes it easy for the enduser to edit and customize the response based on the animation. If just the pose name was used it would make it more confusing for them to know which response will go to which ball in the pose pair. I can see using the pose name and the animation name for selecting the appropriate response. Such as PoseA and Animation RideHim Use response RidHimA if PoseB and animation RideHim use response RideHimB. Also by sending the animation and avatar from the ~poser scripts I do not have to keep track of who is on which ball and which animation is being sent where. I will still use my mod but I am happy to have the additional information your changes send to use for more sophisticated responses.