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?

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.

I think Pussycat sums it up well, if I'm understanding the OP correctly. There was no cause for an AR here, if that's what happened. If they just reported you to the group owner, well, that's fair enough, and all you risk is being ejected from the group. You can probably avoid that by simply apologizing and saying you've learned your lesson. Offering freebies is nice. Doing it on a completely unrelated group where that isn't permitted is inconsiderate, but that's a forgivable offense if it's not repeated.

Good tip from an experienced master! Thanks :-)

Lucky for you, LL allows you to do this. The price we all pay is that griefers and theives can keep coming back with new accounts. If it were my decision, I would require identification. But it's not. As long as LL continues with their policy, this is just what we have to put up with. I don't see any evidence they'll change.

The simplest solution to most griefing as well as a content theft and other dastardly behavior would be for LL to require identification for all new accounts (e.g., PIOF). That would make it far harder for repeat offenders (assuming LL bans them). But LL is pretty firmly against that. I don't know what their reasons are. I do understand that there's a benefit to complete anonymity. There's also a price, and this is an example.

Kudos to you SimonLeo! I'm sure a lot of us would be interested to hear anything you learn about the nature of these attacks. I'd like to learn how someone might be "locked out of their sim" and what measures can be used to prevent it. (No, I don't want details on how to reproduce the attack, just the technical nature of the threats.)

Adding a PG continent is an excellent idea. Separating PG and Adjult into different grids would be a case of "divide and conquer" -- both populations would lose out significantly. The teen grid was never open to adults, so it's not a fair argument to say LL had a PG grid and it failed. But it is an example of a separate grid that failed due to the wall between the grids. While the shift from Mature/PG to Adult/Mature/PG was a hassle, I think it was a step in the right direction. It would be interesting to see what percentage of avatars want to be Adult-capable. Unfortunately, since all PIOF and PIU members are Adult capable, we don't have any good stats. The percentage of Adult verified among currently active NPIOF members might be interesting, but would be a bit skewed.

I finished my work in reducing MLPV2 script memory usage. The goal was to reduce the parcel memory footprint, not to enable more poses -- but I did find some optimizations and it might just allow more now. Join the MLPV2 group and view notices to get the pre-release version for testing. If you just replace all the scripts in your existing MLPV2 (no need to update ~ball this time), you can compare parcel script memory usage between older and latest version. Some versions took over 1000k, the latest version took about 750k, and with small configurations the new one takes about 400k. The bigger your notecard config, the more memory it will take. It sizes itself automatically. If you see stack-heap errors, you can configure more reserve memory in the notecard for the crashing script. This overrides the default memory cushion reserved after reading the notecards. When you press the menu Adjust button, it now prints the free memory, so you can monitor the health. In Adjust mode, it maxxes the limit for ~memory, so you have room to store new pose positions. ~props should do this too, but I forgot that one. If you don't have a lot of props, you should be fine. See the .readme file for more info. Please give it a test and post any bug reports here.

Since viewers now can report parcel script memory usage etc., I've started working on reducing MLPV2's footprint. Here are some of the things I've done so far (and posted to the MLPV2 group -- join the group if you want a copy to experiment with). I'll be interested in feedback and suggestions about other things to consider. Also, I haven't seen the memory usage stuff in the client yet. I'm running an older one and need to update, but don't get much SL time these days. I'll appreciate any tips or clues you think I should know about region/parcel/avatar memory usage. Keep in mind the goal is to reduce the memory footprint, not (specifically) to increase the number of poses or positions. However, I'm keeping an eye open for any improvements I can make there, too. ~menucfg, which reads the MENUITEMS.* notecards and sends the processed configs to ~menu, now reduces its memory to a small pad over the used memory before it shuts itself off. MENUITEMS.* notecards can now contain MEMORY directives. After receiving the configuration, ~menu sets its memory limit to the given value, and then reports the remaining avaliable memory. POSITIONS.* notecards can now contain {MEMORY} directives. The syntax is odd but I didn't want to eat into the memory available for positions. After reading the positions, ~memory sets its limit to the given value and reports the remaining available memory. I plan to do similar things for sequences and swaps. In addition, I'll probably have ~swap reduce itself automatically if no swaps are configured. It would be nice to be able to eliminate the ~swap script if you're not using swaps, but I tried that originally and kept getting hit by race conditions. I had planned to change ~poser* scripts to mono and have them reduce their memory to a constant, but in Mono they take 17K, so I left them at their 16K which is always the case for LSO. However, they actually take less room on a server in Mono because they use little data; most of the space is code and code segments are shared in Mono. I may add a constant memory limit to them in case anyone recompiles them in Mono, or might change them to Mono "for the greater good" regardless of the fact that it would increase the apparent memory footprint. ~run sets its memory to a small constant. ~run sets its memory I had other items on the todo list, which are in the .readme notecard in the MLPV2.5a example I posted on the MLPV2 group notices. I can't get ingame at the moment. Feedback please! Let me know how this version appears in whatever script memory displays we have now, compared to previous versions. Thanks!

The smallest program segment was 512 bytes, last I checked (and I *really* wish they'd reduce that!) Every state takes at least one program segment. Every function takes at least one program segment. The minimal script might also need some fixed number of program segments. Each state might take one as well, but I never tested that. So, the minimum program size is 512 (for one small event handler in the default state), plus whatever the per-state and per-script overhead is. Someone above mentioned that in Mono scripts, it's the data that takes most of the room. That may be typically true, but isn't the case for some scripts. For example, my Spin The Bottle game has a surprisingly large amount of algorithmic code. (The worst case is to handle the multiperson case; given each player's sex and sexual preferences and a list of possible poses, with the role of each poseball coded, finding the candidate poses that are possible given the players present, and after selecting one, randomly assigning the applicable players to each poseball. Which is trickier than it sounds, unless you're a genius and have some metamathmagical trick up your sleeve, which I am not and do not.)

Thanks again for updating me, Void! Are you sure there's no way to avoid the double-space penalty in mono? I remember reading a wiki entry that went into great detail about the best way for LSL vs Mono, with a few other variables as well. Perhaps things changed since then. I'm sure I never noticed seeing freemem go up since starting to work with mono, but since I believed it was still a high-water mark it might have happened and I missed it. BTW, something changed behavior in Mono in the last month or so. I have a product "Spin the Bottle" which has a master script that uses a hacked up MLPV2 in a child prim sort of like a marionette -- it's rather clever, and I do mean that in the pejorative sense. It had worked without customer issues quite robustly for many months, but now it sometimes doesn't initialize properly. The init involves interprim link messages and sometimes one is lost, probably due to a state change. Any idea if anything significant changed in this area lately, or in the order of processing different kinds of events? If that's not fuzzy enough for ya, we can make it even blurrier: just squint really hard. ;-)

Absolutely! I'm training to be a dragon! Seriously, SL is a training ground where we learn that we really drag our problems around with us. It's also a great place to learn that running your own business can be rewarding, despite being a huge pain in the ass.