Lear Cale

Regardless of where MLPV2 scripts are found, you are legally entitled to request the source for the script. MLPV2 is based on MLP, which was covered under the GNU Public License (GPL). GPL makes if very clear that anyone using or modifying GPL-licensed software MUST publish the source code or provide it on request. Since MLP was based on GPL, MLPV2 is also covered by it, and so is any script created from MLPV2. Refusal to do so is a violation of the GPL license and is legally actionable. If anyone refuses to comply with the terms of the GPL licence, please notify me as well as Miffy Fluffy (the author of MLP and XPOSE). Thanks to the GPL license, nobody needs any permissions (from me or Miffy Fluffy or anyone else) to run MLPV2 scripts on other grids.

Uh oh! thanks for the heads up. I'll be back!

Don't duplicate the stuff you duplicated. Delete your changes to the root menuitems. This is gonna be confusing. Your best bet is to probably join the MLPV2 group and ask for help ingame. But I'll try to clarify this. I confess I designed this mess, but the main reason it's as complicated as it is, was to be backwards compatible with old MLP notecards. That and I'm a bit slow sometimes. The "TOMENU -" lines are to get stuff automatically planted on the first page. Once you run out of stuff that gets planted on the first page, you're out. You can't make more automatic spots available. In general, don't ever change that particular part. Rather than making the main menu page extended, try to organize your menus so that the submenus can be longer. Here's an example. MENU girlboyTOMENU gb-kissTOMENU gb-cuddleTOMENU gb-playBACK MENU gb-kissPOSE .....POSE .....POSE .....STOPBACKMENU gb-cuddlePOSE .....POSE .....POSE .....STOPBACKMENU gb-playPOSE .....POSE .....POSE .....STOPBACK Because "girlboy" isn't on a TOMENU anywhere, it gets automatically planted on the first page. The other menus (gb-kiss, gb-cuddle, gb-play) are linked off the girlboy menu explicitly, and won't get automatically added to the first page. You can have any number of submenus: the gb-kiss menu could point to even more submenus if you wanted. I generally put a group like the above in its own .MENUITEMS.girlboy notecard, to make it easy for me to drag different menu sets into different products, but that's not required. It's just for convenience. Note that the BACK lines in the menus aren't necessary for MLPV2 to work, but they're important for the user to be able to navigate. IIRC, there's an AUTOBACK line you can put in any of the notecards, and it'll always add a BACK to every submenu. HTH

Never mind -- I think I missed an important bit of context here. My point was that the original is unmodified, so rezzing it doesn't cause unrecoverable harm. But if you need to modify after rezzing to use, then the fact that the original is still good is of little help (unless they change the behavior later). In any case, LL has gall calling anything a "hack" regarding LSL, because THEY NEVER DOCUMENTED any LSL functions. They left it to users to guess the intent of the functions, and document the observed behavior. So, they're stuck with the results. If LL had treated LSL the way any responsible middleware vendor would treat their product, they would have documented the intended effects. Then they'd be somewhat covered when they changed the undocumented behaviors, as long as the documented ones remained the same. But since they took the easy way out, they have no high horse to sit on, because ALL scripts are "hacks". They work because they work because they work. There is no other specification or standard by which to judge them. But (if I understand this issue correctly -- and no doubt am missing a lot because I no longer script and haven't followed the latest developments in ground mesh or whatever) phantom bounding prims to handle collisions with scuplties is NOT a hack: it's a way to turn unpredictable behavior (collisions with scuplts) into predictable behavior (collisions with phantom prims). Can anyone fill me in or point me to LL's explanation of why they need to make this change regarding phantom prims?

The reason is simple enough: to have one's cake and eat it too. It shouldn't be a big surprise. Regarding the cheating issue, a lot of people are making assumptions. Cheating is violating agreements. Since we don't know what agreements the OP's example has with his RL, any assumptions we make about his situation are just that. I've known people who have agreements with their spouses, who have monogamous RLs but all sorts of ... um ... "fun" in SL, and it's OK with the spouse. What could be the reasons for that? There are many. The fear of diseases might be one reason to be monogamous in RL, but wouldn't apply to SL. A person might feel jealousy for a flesh encounter but not an animated one, even if there's rubbing going on. The full list would be as long and varied as there are different kinds of people. Sure, I bet those cases are the minority. Otherwise, it's just a matter of what one can get away with, or how far over the line one is willing to go. While the points about SL relationships and emotions being real are valid, I still bet most of us would consider an in-the-flesh encounter to be a bigger violation of our RL agreements than an SL encounter. Why the "taken in RL" notice? Because it serves a purpose (avoiding entanglements, and avoiding misleading someone). Nothing odd about that.

Fortunately, most vehicles are copiable, so this won't be a problem: the original won't be modified.

There's a tutorial on SL Wiki MLPV2 page. MLPV2 wiki is at http://wiki.secondlife.com/wiki/MLPV2 Props to Teq Hutchinson for writing it up. I use my own scripts and not CISS, so I can't comment on the details.

Your memory is correct. There is a good reason many danceballs work that way. A script can hold permissions for at most one avatar. A danceball that handles 30 dancers and only asks for permission once for each dancer would need at least 30 scripts. So the simple one-script solution is to ask every time. A bit of a nuisance for the users, but sure saves on server memory. Of course, with Mono, the slave scripts that hold the permissions could be very small and take very little memory, and the code segment for them all is shared, so it wouldn't really be as bad as it might seem when looking at parcel memory usage. But I digress. ;-)

Just to clarify: a typical AO won't affect idle state. When I said "work like an AO" I meant a script that constantly monitors (in this case looking for the away state or the idle anim running) and turns off the idle anim. The away state will go away when you turn off the idle anim. That's if I recall this stuff correctly; it's been a few years. PS: I like Innula's idea.

It's not possible without rezzing an object. The way this is done (for example, for couples walking together) is to use an object (or pair of objects) that both people sit on, and it animates them both. As mentioned above, you can't sit on someone else's attachment. Follower scripts would lag too much. I have a couples walking animation that used one prim. First the owner sits on it and then the guest does (or something like that). That's slightly trickier scripting, having two avatars sitting on one prim.

For Qavimator, I have a two-frame starting pose that I use for all my anims, where every joint is moved between the T frame and the first (only) animation frame.

This was posted in scripting and moved to Wanted. See http://community.secondlife.com/t5/Wanted/Request-Twister-in-SL-Payments-to-discuss/td-p/1375357

archsagesoren wrote: If they refuse the fall animation, they're annoying. Odds are, they'd be asked each turn if they wanted to allow the object to act on them, which could lessen the fun. But hell, I've tried to puzzle it out in English, hopefully give some people a bit of inspiration or a head start, yeah? Or a basis on which to figure how much they want to charge for it. This is not an issue. If you've used a pose menu or poseball with multiple poses, you'll remember that you grant permission (to the script) once, and it keeps it as long as it wants to. It can even keep permission after you stand or leave for days and come back, as long as nobody else granted it permission in the meantime. I had to fix a number of MLP bugs in this area. It used to be amusing to watch people being animated after they'd hopped off a bed.

I gave this some thought a while back and decided not to try it. There are two approaches, both with difficulties. It's a very nontrivial game. I scripted a Spin The Bottle game, which was a lot more complicated than I expected (with a bastardized MLPV2 script to do the posing), and it's way way way simpler in concept than Twister. I wouldn't need objects for the spots (or code in the spots) or objects to be worn, doing it the way I would plan, but maybe there are approaches I haven't considered. Other than that, archsagesoren makes a number of good points. The simplest approach would involve completely premeditated games (or nearly so, more on that later). For each premeditated (pre-planned) game, you'd have a predetermined animation for each turn in the game. For example: turn 1: player 1 spins left foot blue, script poses player with his left foot on the 2nd blue spot. Turn 2: player 2 spins right hand red; script poses player with her right hand on 3rd red spot. etc, etc ... once you start down a path, the result is always the same. Now, with very clever analysis and crafting of the poses, instead of just a number of fixed independent games, you could plan a number of trees of games, where, from any preplanned position, you have more than one preplanned positions for the players to "spin", selecting from among them using a random number generator. This would be a LOT of work but could be fun. With even more thought, the "trees" might have branches that join up (that is, two different paths to reach the same pose) e.g., one where he places his foot on a given spot first, and then his hand on another, versus doing the same in the opposite order. This has to be done carefully to avoid intersecting bodies! The fun part would be the final turn for each branch in the tree, where an impossible move is spun, and the game concludes with an amusing animation where the players collapse in a heap. The other option would be considerably more complicated, and involves a set of poses created by someone already. I don't recall the name, but that system has hundreds and hundreds of animations to allow creating poses in SL, the anims move one joint, and say for right knee there are a large number moving in 5 degree increments on the allowable axes. Someone who's REALLY clever might figure out how to use that kind of system. I shudder to think, but there are plenty of clever people in the world! I coded MLPV2 (a free menu system that's used in lots of menu-pose furniture) and it's not a trivial script. Spin the Bottle was conceptually more of a challenge, involving a master controller script and MLPV2 to do the animation. The result is fairly complicated. But it pales in comparison to the kind of planning that would have to go into a system like this. Using the first option above, I'd again use MLPV2 as the pose engine and have a master script to control it and run the game. The master script would read a notecard that lists the possible game steps (defined as a tree using labels, probably), with a pose name as the result of each node in the tree. I'd suggest anyone look at the ~sequencer script to see how a script can operate MLPV2. It wouldn't need the modifications that Spin The Bottle needs, since it would only animate the current players. Maybe someday if I end up with lots of free time I'll do this. It really would be a lot of fun, especially if someone can help come up with a lot of fun trees of poses. And knowing me, I'd probaby have a baudy version. Meanwhile, anyone is free to try these ideas and I wish you luck!

IIRC, the "away" state is actually detected by the afk animation running. (Seems backwards, doesn't it?) If you run a script like an AO and when you find that anim running, turn it off, the "away" status will never appear except for brief moments.