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 Fluff

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.

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 r

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 i

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 lookin

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 afte

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 in

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.