Jump to content

Synced pose balls


bbrasta Boa
 Share

You are about to reply to a thread that has been inactive for 984 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hello everybody.

I found a Synced pose balls script

Quote
// :SHOW:
// :CATEGORY:Pose Ball
// :NAME:Synced Pose balls
// :AUTHOR:Fred Beckhusen (Ferd Frederix)
// :KEYWORDS:
// :CREATED:2016-05-02 13:04:04
// :EDITED:2016-05-02  12:04:04
// :ID:1105
// :NUM:1893
// :REV:1
// :WORLD:Second Life
// :DESCRIPTION:
// Two Or more people sit on two or more pose balls.  The pose balls play a series of animation in sync
// :CODE:
// To use this, just put several dances in a prim and add this script.
// Shift-copy the prim.  Anyone who touches it will dance in sync with anyone else who touches it.


float RATE = 10.0;  // rate to play animations

string lastDance;  // the last dance played on the slave script
string animation ; // the currwent animation name we must play
integer index;     // the num,ber of that animation found in inventory
key avatarK;       // the key of tjhe seated avatar
integer channel = -12134;    // some random number
integer granted = FALSE;

default
{
    state_entry()
    {
        llSetClickAction(CLICK_ACTION_SIT);
        llListen(channel,"","","");
    }

    on_rez(integer p)
    {
        llResetScript();
    }


    changed (integer detected)
    {
        if (detected & CHANGED_LINK)
        {
            avatarK = llAvatarOnSitTarget();
            if (avatarK != NULL_KEY)
            {
                index = 0;
                llRequestPermissions(avatarK, PERMISSION_TRIGGER_ANIMATION);
            } else {
                granted = FALSE;
                llSetTimerEvent(0);
            }
        }
    
    }


    run_time_permissions(integer perm)
    {
        if (perm & PERMISSION_TRIGGER_ANIMATION)
        {
            granted = TRUE;
            animation = llGetInventoryName(INVENTORY_ANIMATION, index);    // first animation
            llSay(channel,animation); // tell another poseball to let them dance.
            llStartAnimation(animation);
            llSetTimerEvent(RATE);
        }
    }

    timer()
    {
        integer newindex = index;     // We must stop old animation
        newindex++;                    // and play new one

        // test to see if we are past the end
        if (newindex >= llGetInventoryNumber(INVENTORY_ANIMATION))
            newindex = 0;

        llSay(channel,llGetInventoryName(INVENTORY_ANIMATION, newindex)); // tell another poseball to let them dance.
        llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, newindex));
        llStopAnimation(llGetInventoryName(INVENTORY_ANIMATION, index));
        
        index = newindex; // get ready for the next animation
    }

    listen(integer channel, string name, key id, string message) 
    {
        llSetTimerEvent(0);        // last one to send a message wins control
        
        if (granted)
        {
            llStartAnimation(message);
            if (llStringLength(lastDance))
                llStopAnimation(lastDance);
            lastDance = message;
        }
    }
}

But for some reason, when the first animation starts, the avatar only plays it from the waist up, because it remains seated, how can I avoid this? 

Thanks in advance.

Link to comment
Share on other sites

 

16 minutes ago, bbrasta Boa said:

for some reason, when the first animation starts, the avatar only plays it from the waist up, because it remains seated, how can I avoid this?

the first animation has a lower priority (most likely Priority 3) than the default sit animation which is Priority  4. Basically higher priority animations play over the top of same and lower priority animations

info about animation priority is here: http://wiki.secondlife.com/wiki/Animation_Priority 

the simplest thing to begin with is to try different animations and see which ones work as expected (i.e. the avatar dances and doesn't stay seated) and only include the ones that work in your dance object. If you do this then you don't need to modify the script you have

 

Link to comment
Share on other sites

What is needed to stop the sit animation is an entry in the run_time_permissions to stop the sit animation before starting the desired pose. The best way to do this is to have a global variable named lastAnim, and when the poeball has nobody sat on it, lastAnim is initialised to "sit". So th snippets look like this:

 

Use his variable lastdance in this way:

 

// inside state_entry()

	lastdance = "sit";	// initialise for an emppty poseball

// inside the run_time_permissions once the test for permission to animate is known

	llStopAnimation(lastdance);	// sto the sit or other previous pose playing
	llStartAnimation(your_anim_name);	// start he desired new pose
	lastdancee = your_animation_name;		// and save it in lastAnim for subsequent stopping

// and inside changed, once the avatar on sit target returns a NULL

	llStopAnimation(lastdance);	// sstops last pose
	lastdance = "sit";			// ready for the next seensation-seeker

 

Just looking at Fred's script, you will also have to do some rewrites in the timer event to use lastnAnim properly. You'' see he is using a string global lastdance to do this, perhaps you can initialise lastdance to "sit" and use i instead of a new variable as I initially suggested

You'll need to work through the logic of how lastdance is also used in the listen event, you'll notice I put the assignment to it in the run-time-permissions event where he has it in the other events, but putting it in the one place where the animations actually get changed will simplify the code quite a bit.

Stopping animations after the sitter stands is a troublesome thing though, if their viewer revokes permissions after standing hen a call too stopAnimation will fail on permissions not valid bu not all viewers allow this and nt all users opt to use it if it's there.

Edited by Profaitchikenz Haiku
  • Like 2
Link to comment
Share on other sites

// . . . at this point
    run_time_permissions(integer perm)
    {
        if (perm & PERMISSION_TRIGGER_ANIMATION)
        {
            granted = TRUE;
            llStopAnimation("sit");      
// . . and so on

the easiest thing to do would be to stop the default sitting animation when the avatar accepts animation permissions. a fairly simple change which should mostly make it behave how you want it to.

  • Like 1
Link to comment
Share on other sites

i like your approach Prof.  is a nice and simple mod to be able to use less than priority 4 animations

when the avatar stands then we don't have to stop the lastdance as this is now done automagically by the server in every case.  So we only have to reset lastdance = "sit" when the avatar stands. And as Quistess mentions also we only need to stop "sit" when a avatar sits

 

 

  • Like 1
Link to comment
Share on other sites

I would recommend always explicitly stopping the sit animation when someone first sits on anything, in the run_time_permissions event at the same time you start the first animation.

It's one of those things that you can often get away with not bothering about but sooner or later you regret it, and then it's sometimes very puzzling.

ETA:  While I think of it, it's also good practice not only explicitly to stop the existing animation when the avatar stands but also to start the default stand  animation.

That's because llStopAnimation sends a message to your viewer to stop  playing the animation, but if it's a looping animation, it'll continue until the end of the loop unless over-written by another animation.    If you're wearing an AO, then that'll take over, but people whose AOs are turned off can find themselves stuck in the sit animation until they start to walk unless you explicitly tell the viewer to play a stand animation when they cease to be seated (I don't say "stand up" because they won't unless told to!).. 

Edited by Innula Zenovka
  • Like 2
Link to comment
Share on other sites

Stopping a system animation tied to a locomotion will also stop any animation tied to that locomotion set by llSetAnimationOverride().

With furniture, it's a good idea to not only to stop the default sit animation after the initial sit, but to also do it every time you change animations to combat AOs that cycle their locomotion animations.

This isn't the case with viewers that use their own AO that do not make use of llSetAnimationOverride(), but instead, just manually play the assigned animations "in-world".

Link to comment
Share on other sites

11 hours ago, Mollymews said:

when the avatar stands then we don't have to stop the lastdance as this is now done automagically by the server in every case.

That's good to know, I've had instances some time ago where the animations persisted unless explicitly stopped which lead me to this defensive programming method, so I assume there's been a change over the years.

 

ETA just seen Innula's explanation that might be what I had previously been seeing. 

 

Timing is an issue here, at what point after the avatar unsits do you lose animation permissions? I'm seeing frequent permission errors when trying to stop the current animation when an avatar unsits and their viewer revokes permissions. I've not as yet been able to measure just how soon this occurs, if, for example, it's sooner than the time you have in the detach condition to tidy up?

Edited by Profaitchikenz Haiku
Link to comment
Share on other sites

1 hour ago, Profaitchikenz Haiku said:

That's good to know, I've had instances some time ago where the animations persisted unless explicitly stopped which lead me to this defensive programming method, so I assume there's been a change over the years.

 

ETA just seen Innula's explanation that might be what I had previously been seeing. 

 

Timing is an issue here, at what point after the avatar unsits do you lose animation permissions? I'm seeing frequent permission errors when trying to stop the current animation when an avatar unsits and their viewer revokes permissions. I've not as yet been able to measure just how soon this occurs, if, for example, it's sooner than the time you have in the detach condition to tidy up?

it used to be that when we teleported while sitting on an object then the animation would continue to play on us at the destination region

Linden fixed this so that whenever we unsit then it stops any animations started by the sat on object. Since then I haven't bothered ever stopping an animation that my sit object script has started when the avatar unsits. I let the system take care of it

 

  • Thanks 1
Link to comment
Share on other sites

15 minutes ago, Mollymews said:

it used to be that when we teleported while sitting on an object then the animation would continue to play on us at the destination region

Linden fixed this so that whenever we unsit then it stops any animations started by the sat on object.

Interesting. When I was investigating in depth a few years ago I was examining three distinct scenarios:

Avatar unsits gracefully (stands via the viewer button or via the menu option) - stopping last animation gives perms error for TPVs with revoke set

Avatar unsits disgracefully ( Logs off or Crashes to desktop or TPs to a different region) - stopping last animation succeeds with no perms error.

But as you have said, the animation didn't persist in the two cases I could examine (obviously CTD wasn't examinable).

 

Edited by Profaitchikenz Haiku
Link to comment
Share on other sites

1 hour ago, Profaitchikenz Haiku said:

stopping last animation gives perms error for TPVs with revoke set

i have no real idea of how TPVs do Revoke on Stand, other than it probably is mod something something of standard Debug Setting: RevokePermsOnStopAnimation which is True by default

if i was making a commercial animation anything then I would precede each call to llStartAnimation and llStopAnimation with a check for the permission. Example:

if (llGetPermissions() & PERMISSION_TRIGGER_ANIMATION)
{
   ... llStopAnimation(anim);
   ... llStartAnimation(anim);
}
else
   ... reacquire permission depending on situation

this is how my AO HUD does it

When I select menu: Avatar \ Stop animations (used to be menu: Me \ Stop Animating Me) in the Linden Viewer then it does the RevokePermsOnStopAnimation.  Then because my AO is on a timer cycling animation changes, it uses the above method to reacquire permissions, and continues to animate

  • Like 1
Link to comment
Share on other sites

17 minutes ago, Mollymews said:

have no real idea of how TPVs do Revoke on Stand,

I didn't know the exact mechanism but I was beginning to suspect they took the pressing of the stand button and fired off code there so the permissions vanished well before a similar things such as detaching, I found no time to do any cleanups. The key to the puzzle was that a TP to a remote region didn't raise an error whereas a TP to elsehwere in the same region  did.

 

17 minutes ago, Mollymews said:

if i was making a commercial animation anything then I would precede each call to llStartAnimation and llStopAnimation with a check for the permission.

All very laudable, but I found a way to do it with less calls: since you are (hopefully) going to do a check for the required perms in run-time-permissions, all that is needed is a global variable to say if an animation is to be started or stopped, and then do all the animation controlling inside RTP. The reason I often put the stop last animation call in the changed event as the first statement after detecting avataronittrget was Null was to try and stop the animation befrre a TPV revoke action removed such permsissions.

What I never managed to achieve was a way of dropping the key of the avatar for whom permissions had been previously held without a full script-reset. A surprising omission in LSL, although I predict now somebody will pop up and say "Ah ah, you want to call llGetPermisions with an invalid key , that'll do the trick"

Edited by Profaitchikenz Haiku
Link to comment
Share on other sites

1 hour ago, Quistess Alpha said:

I think that might be viewer and settings dependent.

Very probably viewer, I was testing the the official LL viewer, Singularity, Firestorm, Catznip, Kokua, Alchemy Beta, CoolVlViewer and Kirstens, and none of them gave the some result.

BUT... all this was being done back when the performance of scripts within regions was deteriorating quite noticeably and so I was also left contemplating was this something in the event handler for the region itself? In an attempt to determine that I began trying to measure the region performance for scripts, with little success.

Edited by Profaitchikenz Haiku
Link to comment
Share on other sites

32 minutes ago, Profaitchikenz Haiku said:

I didn't know the exact mechanism but I was beginning to suspect they took the pressing of the stand button and fired off code there so the permissions vanished well before a similar things such as detaching, I found no time to do any cleanups. The key to the puzzle was that a TP to a remote region didn't raise an error whereas a TP to elsehwere in the same region  did.

All very laudable, but I found a way to do it with less calls: since you are (hopefully) going to do a check for the required perms in run-time-permissions, all that is needed is a global variable to say if an animation is to be started or stopped, and then do all the animation controlling inside RTP. The reason I often put the stop last animation call in the changed event as the first statement after detecting avataronittrget was Null was to try and stop the animation befrre a TPV revoke action removed such permsissions.

with the Linden viewer when RevokePermsOnStopAnimation is True  (the default) then it all works out of the box, regardless of unsit method. Stand, teleport, teleport to same region, llUnSit(), crash, menu: Avatar\Stop animation (which unsits the avatar)

if TPVs aren't doing this already as well then they should be soon. It might even be that this debug setting came out of previous TPV work

38 minutes ago, Profaitchikenz Haiku said:

What I never managed to achieve was a way of dropping the key of the avatar for whom permissions had been previously held without a full script-reset. A surprising omission in LSL, although I predict now somebody will pop up and say "Ah ah, you want to call llGetPermisions with an invalid key , that'll do the trick"

i have always wanted to be able to llRequestPermissions(NULL_KEY, 0) to set the script permissions to 0

we can request zero permissions and obtain this, but we need a agent id which is present on the region to do it

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 984 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...