Who stood up?
|
|
Phate Shepherd
Addicted to code
Join date: 14 Feb 2008
Posts: 96
|
10-06-2008 18:42
In building vehicles (or anithing that involve animations), I understand that I should stop any animations that I started when the avi stands up. No problem, I can do that.... but what about when different seats have different animations?
The standard way to stop an animation for a vehicle is to look for a changed_link event with a null_key and stop your animation by name at that time. Problem is, if you have multiple seats, each with their own animation, the change_link with a null_key fires off and I can't figure out WHO stood up so that I stop only their animation (to avoid scripting errors.)
So the question is, is there a way to determine who just stood up? Or do I have to do something complex to track avi keys linked to the vehicle?
|
|
Traskin Snakeankle
Registered User
Join date: 10 Mar 2005
Posts: 7
|
10-06-2008 19:42
on change event get the current count of prims,compare that to a saved prim count. if less then someone stood up. to find out who, you can keep track of keys. copy that to a temp list then loop thru links and remove the current linked keys. whatever is left is who stood up. if you only want to keep track of avatar links use following as test if (llGetAgentSize(llGetLinkKey(z))) { //im an avatar key }
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
10-06-2008 20:30
Generally you have to have one script per sitting avatar anyway if you want to stop animations when they stand up. Ironically you don't have to do that while the avatars are still sitting, but when the avatar stands (since you get notice AFTER they stand, not just BEFORE they stand), the script has to already have PERMISSION_TRIGGER_ANIMATION granted by the avatar or a blue permissions dialog will pop up when the script requests it (not a nice thing to do when someone stands up).
And when you have PERMISSION_TRIGGER_ANIMATION granted already, llGetPermissionsKey() will give you the key of the resident if you really need it.
|
|
Marcush Nemeth
Registered User
Join date: 3 Apr 2007
Posts: 402
|
10-07-2008 04:31
llAvatarOnSitTarget() 
|
|
Escort DeFarge
Together
Join date: 18 Nov 2004
Posts: 681
|
10-07-2008 10:44
The simplest way is to do the following (in each seat script): ....store the sitter's key for this sit target in a global... key avatar = NULL_KEY;
...then in the "changed" event... if (change & CHANGED_LINK) { if (avatar != llAvatarOnSitTarget()) { // if it's not this seat that changed, ignore avatar = llAvatarOnSitTarget(); if (avatar != NULL_KEY) { // start animation } else { // stop animation } } }
hth /esc
_____________________
http://slurl.com/secondlife/Together
|
|
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
|
10-07-2008 13:50
Out of curiousity, do we think there's still any reason to stop animations after the avatar stands up? I asked the same question, more or less, back in January, in /54/8a/235991/1.html#post1845458, but the answers seemed to be about attachments and danceballs, not sit targets. Now, teleporting away from a sit clears the animation (and llStopAnimation() didn't work for that before anyway), so... is there some weird condition where there can actually be an animation left to stop after standing?
|
|
Phate Shepherd
Addicted to code
Join date: 14 Feb 2008
Posts: 96
|
10-09-2008 19:30
Escort,
I've been staring at your code, and I think I am just beginning to wrap my head around it... looks like a rather simple solution, although the logic to it wasn't obvious. Will have to give that a shot.
Edit:
Tested this, and it is exactly the solution I was looking for. No more falsely triggered stopanimations, or permission errors from the wrong CHANGE_LINK event getting triggered.
|
|
Anti Antonelli
Deranged Toymaker
Join date: 25 Apr 2006
Posts: 1,091
|
10-09-2008 20:51
From: Qie Niangao Out of curiousity, do we think there's still any reason to stop animations after the avatar stands up? I asked the same question, more or less, back in January, in /54/8a/235991/1.html#post1845458/54/8a/235991/1.html#post1845458, but the answers seemed to be about attachments and danceballs, not sit targets. Now, teleporting away from a sit clears the animation (and llStopAnimation() didn't work for that before anyway), so... is there some weird condition where there can actually be an animation left to stop after standing? I'm curious about this too, having gone through the pain as a fledgling scripter of figuring out how to start/switch/stop pairs of animations in synced couple's poseballs. I ended up with a solution functionally identical to Escort's, but it sure seems like explicitly stopping an animation upon standing is pointless now. Of course once animation perms are granted all kinds of wacky things can happen if you carry on applying new animations willy-nilly without checking to see if your avatar is still on the sit target - but that's a different issue, albeit one that might lead people to erroneously assume that animations must be stopped on standing (present company excepted, of course  ).
_____________________
Designer of sensual, tasteful couple's animations - for residents who take their leisure time seriously.  http://slurl.com/secondlife/Brownlee/203/110/109/ 
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
10-09-2008 22:11
Not all animations are created equal. Has someone tested a plain stand up with an animation they KNOW is looped? I always wonder if the claim that animations don't have to be stopped on stand is due to a misunderstanding, since non-looped animations will continue to "play" while the avatar remains seated (no default animations that would change the pose are played automatically) but the "stand" animation is played as soon as the avatar stands up, and animations causing significant movement continue to be played automatically while the avatar is standing.
|
|
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
|
10-10-2008 03:19
From: Hewee Zetkin Not all animations are created equal. Has someone tested a plain stand up with an animation they KNOW is looped? Yep: Just to be absolutely sure, I tried it with my own looped anim, priority 4, and one that's very evident when played along with a stand (or most anything else)... as soon as the avatar stands, the animation is removed, without anything in the script to make it stop. I was pretty sure of that, going in. But I'm not sure if there's some wacky condition that somebody detected at some point, for which that llStopAnimation() is (still?) a fix. I mean, we've all gotten stuck in animations due to lost packets (or bad SL mojo) even with the llStopAnimation() call, so maybe it would happen more often without it? Or did at one time? But obviously, with lots more stuff these days wanting to animate multiple avatars sitting on the same prim, with or without a sit target, it would be Real Nice if a separate script for each agent weren't necessary.
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
10-10-2008 04:22
There probably is some automatic removal now, but it can't hurt (and is good practise) to stop any animations that you start whenever possible.
As for the code, one of the confusing things is that CHANGED_LINK doesn't tell you which link changed, so you don't know which avatar stood up, all the code that Escort posted does is keep a note of the last known avatar on the sit-target, if this was previously NULL_KEY, and isn't anymore, then someone has sat on it, if it was previous NOT NULL_KEY and now is, then someone stood up. In another case then nothing has changed.
_____________________
Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)
|
|
Escort DeFarge
Together
Join date: 18 Nov 2004
Posts: 681
|
10-10-2008 07:06
From: Haravikk Mistral There probably is some automatic removal now, but it can't hurt (and is good practise) to stop any animations that you start whenever possible. ..particularly since there's no guarantee that things will *continue* to work this way... /esc
_____________________
http://slurl.com/secondlife/Together
|
|
Ravanne Sullivan
Pole Dancer Extraordinair
Join date: 10 Dec 2005
Posts: 674
|
10-10-2008 12:19
If someone gets off another seat it will trigger the changed event in all seats even those with no avatar on them, if you don't check for animate permissions before stopping the animation you will receive an error See below. From: Escort DeFarge The simplest way is to do the following (in each seat script): ....store the sitter's key for this sit target in a global... key avatar = NULL_KEY;
...then in the "changed" event... if (change & CHANGED_LINK) { if (avatar != llAvatarOnSitTarget()) { // if it's not this seat that changed, ignore avatar = llAvatarOnSitTarget(); if (avatar != NULL_KEY) { // start animation } else { integer perm = llGetPermissions(); //Make sure that you have permission to stop the animation if (perm & PERMISSION_DEBIT) { // stop animation } } } }
hth /esc
|
|
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
|
10-10-2008 16:59
This isn't quite right, either. Structured this way, one would test for PERMISSION_TRIGGER_ANIMATION (not PERMISSION_DEBIT), but there are other ways to structure the code, too: Personally, I'd use a local variable instead of calling llAvatarOnSitTarget() twice. And if it's just a simple sit animation script, it will still have permissions to stop the animation on the avatar for whom it started an animation, so instead of llGetPermissions or llGetPermissionsKey, it could keep track of that most-recently-animated agent in a global variable. Then there's the problem of the avatar who teleports away, crashes, or logs out while sitting. (I used to mishandle this case myself.) In this situation, the CHANGED_LINK event is raised and the script will (usually?) still have permissions on that agent, but llStopAnimation() will throw an error: "llStopAnimation: Script trying to stop animations but agent not found." To avoid this, precede the llStopAnimation() call with some test for the agent being in the sim (llKey2Name, llGetObjectDetails, llGetAgentSize, etc.); see /54/6f/273123/1.html#post2086346.
|
|
Phate Shepherd
Addicted to code
Join date: 14 Feb 2008
Posts: 96
|
10-10-2008 18:02
From: Ravanne Sullivan If someone gets off another seat it will trigger the changed event in all seats even those with no avatar on them, if you don't check for animate permissions before stopping the animation you will receive an error
See below. Ravanne, that is the brilliance of his code... yes, all seats will get the changed link when someone stands up, but the seat/unseat code only runs if THAT seat has changed. That is the point of the global that tracks who is on that seat. Therefore, there is no nead to check for permissions on unseat, since the unseat code will only run for the person in that seat (and by extention, granted PERMISSION_TRIGGER_ANIMATION.)
|
|
Phate Shepherd
Addicted to code
Join date: 14 Feb 2008
Posts: 96
|
10-10-2008 18:05
From: Qie Niangao This isn't quite right, either. Structured this way, one would test for PERMISSION_TRIGGER_ANIMATION (not PERMISSION_DEBIT), but there are other ways to structure the code, too: Personally, I'd use a local variable instead of calling llAvatarOnSitTarget() twice. And if it's just a simple sit animation script, it will still have permissions to stop the animation on the avatar for whom it started an animation, so instead of llGetPermissions or llGetPermissionsKey, it could keep track of that most-recently-animated agent in a global variable. Then there's the problem of the avatar who teleports away, crashes, or logs out while sitting. (I used to mishandle this case myself.) In this situation, the CHANGED_LINK event is raised and the script will (usually?) still have permissions on that agent, but llStopAnimation() will throw an error: "llStopAnimation: Script trying to stop animations but agent not found." To avoid this, precede the llStopAnimation() call with some test for the agent being in the sim (llKey2Name, llGetObjectDetails, llGetAgentSize, etc.); see /54/6f/273123/1.html#post2086346/54/6f/273123/1.html#post2086346. The point of calling it twice is so that another variable isn't needed, and the global only gets changed AFTER the test.... which is critical to the operation of the script... and the genious behind its simplicity.
|
|
Ravanne Sullivan
Pole Dancer Extraordinair
Join date: 10 Dec 2005
Posts: 674
|
10-10-2008 18:21
Oops. I should pay more attention to what I cut and paste.
|