nPose: open source, no-balls multi av pose system

Only put the scripts in the root prim - you do not need to put them in all the child (linked) prims.

Nandana, please put an entry for nPose in the SL wiki:

http://wiki.secondlife.com/wiki/In-World_Maker_Tools

Put it in with Posing tools, and make clear in one line what it's for (e.g., "menu-driven multiple avatar poses without poseballs, even suitable for vehicles".

I've been watching this from a great distance because I (like everybody) have had a variant of the same idea "in the works" for months and months, but never completed. Today I decided to actually read the instructions for NPOSE and found that it was doing the same thing I had originally been doing, in that it uses a separate slave script for each animated avatar. That raises a question:

Do we really think it's still necessary to stop the animation when somebody stands from the object that automatically obtained script permission to animate them by virtue of having sat on the object?

If not, shouldn't NPOSE be able to get by without separate slave scripts? Rather, I'd think a single script could just request permissions for whichever avatar it wants to stop/start anims, get the permission instantly, and do its thing, switching among all the agents on the fly, all in the same script. Once the agent stands, of course, it must not ask permission to change animation because that would be an explicit request to the viewer, and that would be really clunky. But I think, once the agent stands, all the anims associated with the sat-upon object are now quite reliably stopped anyway. Do we have any current reason to think otherwise?

With script memory limits ahead, it would be a win if we could do away with those one-per-animated-avatar scripts.

Maybe there are other reasons for the separate scripts. Perhaps the 0.2sec delay of llSetLinkPrimitiveParams() is just too painful when one has four or so agents to move around, so maybe this is just a bad idea anyway. (I've been purposely not reading the source because it's GPL'd, and for my main application, I dare not distribute some of my source--which I think I can keep separate, at link-message distance from the main NPOSE scripts, but if not, then I need to proceed with my original plan, not leverage NPOSE, in which case I guess I'd better not have read it.)

Maybe I'm misunderstanding, but isn't the main reason for having multiple scripts in applications like this that a script can only hold permissions to animate one avatar at a time; that is, it's not a matter of stopping anims but of being able to animate several avatars at once?

Right, but as long as the script is in an object on which the avatar is sitting, it can get that permission instantly, so it could just switch which agent on which it has permissions whenever it changes which avatar it wants to animate.

What I'm wondering, though, is what happens to the avatar(s) whom it did, at one point, have permission to animate but then someone else comes along and and sits down.

I sit on the object. The script automatically gets permission to animate me. Then you sit next to me. The script gets permission to animate you, thus losing permission to animate me. Am I still being animated, since at this point nothing's got permission to animate me?

Oh, I see what you mean. Good question! I had to try this just now with my alt. It turns out that the animation keeps playing on the first avatar even after the script has gotten permission and animated a second avatar. (Apparently whatever stops the animation when an avatar stands is not doing that because of lost permissions, per se, but because the avatar is no longer sitting on the object that had permissions.)

...And wouldn't have worked, back in 2006 or so.

Lear, as long as you're here: have you by any chance looked at the nPose Slave scripts? I took a quick glance at it, trying to understand why I was getting wildly offset positions for a unconventionally oriented nPose prim, and I've almost concluded that it's going to be necessary to change the way nPose calculates avatar positions if it's to be compatible with MLP positions.

It's complicated because nPose itself doesn't use llSitTarget() but rather pushes the avatar itself around, so it's trying to approximate that SitTarget effect on the fly. It pretty much has to do that because an avatar on a sit target is offset from the position specified in llSitTarget() according to a messy (and flawed) formula that includes the avatar's own height, so nPose has to emulate that formula to put different avatars at the same places they'd be if they were seated on a poseball.

Of course in contrast MLP gets that avatar-size-specific effect because the avatar is actually positioned by a poseball's sit target.

Looking at the nPose Slave script, I recognize the formula being applied there from my ancient post to Lex's original Easy Sit Target Positioner thread, . (I think it was Strife who eventually switched my division by 37.9 to a multiplication by 0.02638.)

That should work, in theory, but I think something isn't quite right with the coordinate systems. When I get some time, I'll try to work out what's happening, unless it's already known. But I'm pretty sure that either nPose needs to use a slightly different calculation for placing the avatar (thereby potentially changing some existing nPose saved configurations), or it won't be able to accurately import MLP positions for arbitrary orientations of the nPose prim.

If that's correct and if it's ever to be resolved, this would seem the time, before too many MLP-incompatible nPose configurations get loose in the wild.

The automatic animation stop is done by LL-based viewers. libsl-based clients do not try. In the viewers that do support it, the mechanism is fragile and gets ugly when the sim is laggy.

The animation stopping stuff can be found in llvoavatar.cpp. If the viewer learns that the avatar is being unseated, LLVOAvatar::getOffObject is called. If the former parent object is known, a search in the viewer's own animation list is made to find the ones started by that object. The viewer then loops through those animations and sends stop requests to the sim for each, and the sim in turn sends those out to avatars in view. (The animation is killed locally right away, it can take some time for others to see any change.)

When a script stops the animations explicitly, it works universally, even with libsl clients. The delay waiting for the remote viewer to see that the avatar has been unseated, then for the animation stops to be received back from the viewer and relayed, is eliminated.

PERMISSION_TRIGGER_ANIMATION just controls if start and stop messages can be sent, it doesn't really get involved with things that were already running.

Thanks, Viktoria. I'm not sure I care about animations on libsl-based clients, but the mechanism of unwinding the animations from the viewer's internal list does sound fragile. Fortunately for my own application it doesn't matter (the animations and start/stop scripts are elsewhere); I was just hoping to reduce script count in the normal application of nPose. So much for that idea.

Working on my own, independent system similar to this one, I had to puzzle that particular issue out as well. Turns out the old UpdateSitTarget() function that Strife munged is no longer correct. The corrected version is actually simpler.

I've had to put the project on the back burner again temporarily, and it's been a couple months since I fixed that particular problem, so I don't remember the exact changes, but I tested it with varying avatar sizes and it seems to work.

I haven't gone back to test the llSitTarget() offset calculations again lately--but this problem was far from that subtle. I finally did track down the problem with the Slave script and submitted a patch to the Google Code project site for nPose. My fix still assumes the same magic-numbered llSitTarget() offsets and produces subjectively accurate results, but I didn't bother to retest or re-derive those numbers.

[Edit: It turns out that my fix was wrong, and I haven't yet had the intestinal fortitude to dig through this mess, with its SVC-93 complications, to figure out how to make it right.]

No, I didn't look at the nPose code. But then, I never did understand that avatar offset correction; I just used the code Strife posted (for something other than MLPV2).

It would be nice to make the configs compatible between MLP and nPose.

Quite a few posts back, Qie asked why we couldn't get away with doing all animating from one central script instead of using slaves. In fact, the first versions of nPose worked that way by requesting anim perms for the first seated av, then animating that av when perms came in, then requesting perms for the next av, and so on.

The switch from that approach to one with slave scripts was driven by a couple things:
1 - When adding timers to handle looping through sequences and face anims, it was a lot simpler to have one timer per av (in a slave script) instead of overloading one timer to handle all avs.
2 - In the no-slave version, the request/animate loop could be interrupted by an av sitting or standing in the middle of the loop (since the loop required waiting for new run_time_permissions events for each av). Or a link message to switch poses or swap positions could come in while still looping. I didn't want to deal with the hassle of making sure that things were left in a sane state if the loop were interrupted by one of these things, so I switched to a simpler loop in the main script that can complete in a single event, having it send link messages to the slave scripts.

Corrected version?

I'm not entirely sure if we're talking about the same thing with UpdateSitTarget, but I just tested the old sit target offset calculations and they seem as good as ever. Here's the script I use for that:

// Sit on a poseball, then touch the prim containing this script.
// It reports your position and rotation and sets the llSitTarget() to replicate that pos & rot
// Then sit on the scripted prim and touch it again to see how closely you match your previous position.

// 09-19-2008, per Kitty Barnett, Strife condensed this to:
//vector vAgentSize = llGetAgentSize(llDetectedKey(0));        
// vTargetOffset += (llRot2Up(rotTarget) * vAgentSize.z * 0.02638) - < 0.0, 0.0, 0.4 >;

reportPosRot(vector pos, rotation rot)
{
    vector rotVec = llRot2Euler(rot);
    vector degRotVec = < RAD_TO_DEG * rotVec.x, RAD_TO_DEG * rotVec.y, RAD_TO_DEG * rotVec.z >;
    llWhisper(0, "Pos = " +(string)pos+ 
        ", Rot = <" +(string)degRotVec.x+ ", " +(string)degRotVec.y+ ", " +(string)degRotVec.z+ ">");
}

default
{
    touch_start(integer total_number)
    {
        vector avPos = llDetectedPos(0);
        rotation avRot = llDetectedRot(0);
        reportPosRot(avPos, avRot);
        vector avSize = llGetAgentSize(llDetectedKey(0));
        vector heightGlitch = < 0, 0, (avSize.z/37.9) > ;
        vector myPos = llGetPos();
        rotation myRot = llGetRot();
        rotation targetRot = avRot / myRot;        
        vector targetPos = (avPos + heightGlitch*avRot - myPos) / myRot  - < 0, 0, 0.4 > ;
        llSay(0, "llSitTarget(" +(string)targetPos+ ", " +(string)targetRot+ ");");
        llSitTarget(targetPos, targetRot);
        state ready_to_sit;
    }
}

state ready_to_sit
{
    touch_start(integer total_number)
    {
        vector avPos = llDetectedPos(0);
        rotation avRot = llDetectedRot(0);
        reportPosRot(avPos, avRot);
    }
}

To test the calculations, you pretty much follow the instructions at the top of the script:
1. Drop the script in an object,
2. Rez some ordinary poseball and sit on it,
3. Touch the scripted object,
4. Stand up and sit on the scripted object and touch it again,
5. Compare the Pos and Rot values reported in steps 3 and 4.
6 - n. Reset the script and repeat steps 2 - 5 for ad nauseum adjustments to position and rotation of the scripted prim and the poseball, and to avatar size and shape.

(I hack up the script for various uses, and generally lose track of which hacks do what, but I'd guess this version would need tweaking for use in non-root prims.)

Yeah, in my system, I got consistent positioning errors using that code; I narrowed it down to the calculation based on avatar height. I fiddled with it to see if the numbers just needed to be adjusted, but it turned out that the calculation was not needed in that form. I simplified it, and it worked perfectly.

It may be related to the way my system works, I dunno, but it was a head scratcher for the better part of a day, using all kinds of yardsticks, markers, and lots of fiddling with the script until I just removed most of the calculation, and it started working beautifully.

ETA- yes, my system uses child prims for the sit targets. Not sure if that would/should make the calculation vary.

I'm taking down the XStreet listing for nPose because of the new freebie policy, and also the old location for joining the update group has closed down. Because I'm lazy, I'm not going to post updates to the nPose SL group anymore, though it's still a good place for discussion.

The new place to get nPose updates is http://npose.gridshout.com . You can join the update group on that site to have nPose notices sent to you inworld. If you prefer, you can touch the join board at http://slurl.com/secondlife/Furever/7/171/22 , though unverified avatars might not be able to get in there. In that case, just join on the website. The end result is the same.

I suggest you update the first post in this thread with this info, so people looking for npose don't waste time looking on XStreet. Thanks!

The permission is PERMISSION_TRIGGER_ANIMATION. Once triggered, an animation keeps running.

Incodentally, pose ball systems that rez pose balls from an object don't use the automatic "when sitting" permission. Whether you're sitting or not shouldn't have an effect on permissions.