couple dancing without pose ball questions

[VirtualKitten]

Hi my scripter's and  scribblers.

 

I already have a single dance hud which I wrote to do single animations. I am wondering what the complexity of couple animation is like most seem to seem to do this on pose balls but i would rather not .

Has anyone done this or principally how do I keep dancers in keyframe ?  D I welcome any discussion as its helpful for everyone thank you for looking :)D

[Mollymews]

pose balls are used to keep the two dancers in the position and orientation needed to visually coordinate the animated dance.  When we don't sit the dancers then the dance becomes visually uncoordinated when either avatar is moved or rotated. Either using their viewer controls, or as is sometimes the case when they are bumped by another avatar which can happen in crowded dance clubs

we can reduce the complexity of couples dances, down to only 1 prim, where both avatars sit on the same prim, and further reduce down to only one script, where the script llRequestPermissions of both avatars in turn when changing to the next animation dance 

 

edit add. a FYI for anyone reading who might think about doing the 1 prim couples dance

a way is to use Linden Experience - enabled script

Avatar One touches the dance post.  A flat transparent prim is rezzed on the floor under their feet. Avatar One is force sat on the prim. Avatar One is animated into the default waiting/standing position.  They get a menu from which they can Invite Avatar Two to dance with them. Avatar Two accepts the Invite and is force sat on the prim with Avatar One.  Then dance menu thereafter as normal

Edited July 17, 2020 by Mollymews

[Qie Niangao]

11 hours ago, Mollymews said:

and further reduce down to only one script, where the script llRequestPermissions of both avatars in turn when changing to the next animation dance 

I'm glad you mention this. It's a thing I've been doing here and there to reduce script count, so far with no ill effects of which I'm aware. But I'm always a bit skittish about it.

At one point, it was received wisdom that you really needed to stop the animation of a no-longer-seated avatar, for which you need permission, and if there's a separate script for each animated avatar, that permission persists (assuming the avatar is still sufficiently in the region to be able to stop their animation). At some point, though, animations would stop automatically when an avatar stood, but still that "received wisdom" seems to dictate the design of every pose engine, even to this day.

I think the received wisdom is superstition. If not, I'd like to see a repro of what goes wrong with the "one script to animate them all" approach.

[Profaitchikenz Haiku]

30 minutes ago, Qie Niangao said:

At some point, though, animations would stop automatically when an avatar stood,

Only in TPV's which have an option to revoke permissions when standing. I've been banging my head against a wall on this. In the scripts I have, a script error pops up when an avatar using a TPV with this option set stands. On the official LL viewer there is no such script error. And since you can't detect what viewer the sitter is using you can't code for it.

[Qie Niangao]

1 hour ago, Profaitchikenz Haiku said:

Only in TPV's which have an option to revoke permissions when standing. I've been banging my head against a wall on this. In the scripts I have, a script error pops up when an avatar using a TPV with this option set stands. On the official LL viewer there is no such script error. And since you can't detect what viewer the sitter is using you can't code for it.

I think that's something else, though, because if you don't call llStopAnimation() after a sitter stands in the Linden viewer, the seat's animations stop anyway, don't they? 

This viewer-revoking-permissions thing sounds like even more reason to check every conceivable failure before calling llStopAnimation() -- or (better?) just omitting it altogether on standing, which is what I've been arguing here.

By "every conceivable failure" I guess I mean testing that the now-stood sitter is still == llGetPermissionsKey() and their llGetAvatarSize() != ZERO_VECTOR. I guess one could also test llGetPermissions() & PERMISSION_TRIGGER_ANIMATION, but that's presumably still good if the script has any permissions on that avatar... but now that I think about it, I really don't understand how the whole TPV revoke permissions thing works.

[Qie Niangao]

1 hour ago, Qie Niangao said:

I guess one could also test llGetPermissions() & PERMISSION_TRIGGER_ANIMATION, but that's presumably still good if the script has any permissions on that avatar... but now that I think about it, I really don't understand how the whole TPV revoke permissions thing works.

Hmm... that might possibly be the source of the errors you're seeing, @Profaitchikenz Haiku. It appears that a script can have just its animation-related permissions revoked, a result of "Stop Animating Me", to wit:

default
{
    state_entry()
    {
        llSitTarget(<0,0,1>, ZERO_ROTATION);
    }
    changed(integer change)
    {
        if (CHANGED_LINK & change)
        {
            key av = llAvatarOnSitTarget();
            if (av)
                llRequestPermissions(av, PERMISSION_TRIGGER_ANIMATION | PERMISSION_TAKE_CONTROLS);
            else
            if (av = llGetPermissionsKey())
                if (ZERO_VECTOR != llGetAgentSize(av))
                {
                    llSleep(2.0);
                    if (PERMISSION_TRIGGER_ANIMATION & llGetPermissions())
                        llWhisper(0, "Not stopping animations, even though I could");
                    else
                        llWhisper(0, "This would be a BAD place to stop animations");
                }
        }
    }
    run_time_permissions(integer perms)
    {
        llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, 0));
    }
}

When my Firestorm-equipped alt sets the option to Revoke upon Stand, he'll get that "BAD place" message because the script retains PERMISSION_TAKE_CONTROLS (so he's still llGetPermissionsKey) after PERMISSION_TRIGGER_ANIMATION has been revoked.

Edited July 17, 2020 by Qie Niangao
"its" possessive, not "it's" contraction

[Profaitchikenz Haiku]

I'll have to dig out my notes again, but I was looking at the following scenarios after a sitter has been animated by the script.

 

Sitter stands up but remains nearby

Sitter does a flying-sit to a nearby scripted-sit object

Sitter crashes/logs out

Sitter TP's out of the region without first standing

 

I was also testing Avatar_size, which returned zero_vector for the crashed-out or TP-ed out sitters

I was seeing a disparity between the error messages depending on whether the sitter had a TPV with "revoke permissions on stand" active, or had the LL viewer or else a TPV but the revoke permissions option unchecked.

I was mostly worried about the sitters who TP-off to another region because of the known issue with people returning to a region where they had previously accepted animations from a scripted object still being under control of the script in that they had never explicitly revoked the permissions.

But if you say that all viewers now revoke permissions when standing up I might be worrying to no purpose.

[Qie Niangao]

30 minutes ago, Profaitchikenz Haiku said:

But if you say that all viewers now revoke permissions when standing up I might be worrying to no purpose.

Oh, no, definitely not saying that. The script retains permissions, but as far as I know, the animations are always stopped.

[Profaitchikenz Haiku]

Ah. muy bhad. Just checking back it looks like I gave up on stopping the last animation over a year ago because it wasn't possible to do it without getting the script error for the TPVs so it does seem to back you up, the animations are stopped.

I miss the good old days when somebody would arrive near you in a strange grotesque pose leftover from whatever it was they had been doing last, and you had to give them the red rose of release.

[Profaitchikenz Haiku]

Ok, finally found my notes and scripts. What I was seeing was, despite doing the tests for agent size indicating the avatar was still in the region and permissions showing permission to trigger animations was still set, trying to stop the last-applied animation was giving a permissions error for any TPV with the setting on to revoke permissions when standing, but not for LL viewers or TPVs without that setting.

At the time I then was seeing this vary from place to place and this was when the percentage scripts run was beginning to drop. I didn't know if the scripts run drop was the cause of the delay, or if the TPV's revoke-permissions method was taking a while to actually change whatever the stored settings were (i.e. with the LL Viewer, standing stopped the animation but the permission was still there so the script-call succeeded. with a TPV the object permissions might have been revoked after the test to see if animation permissions were still granted but before the call to stop the animation, hence the error message).

I had begun experimenting with adding llSleeps of short durations to see if that got improved reliability but given some of the parcels I was looking at had script run percentages of less than 60 I was loath to add further delays.

I've done some quick testing and I think you're right, the animation gets stopped as soon as the avatar stands. In that case I don't see any need to stop them in the script.

Edited July 17, 2020 by Profaitchikenz Haiku