Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Stupid things
Ryder Spearmann
Early Adopter
Join date: 1 May 2006
Posts: 216
06-17-2008 08:55
From: Viktoria Dovgal
Remember that LSL is just a front end to functionality run by the sim. A prim with a sit target doesn't even need a script to stay inside for a sit target to work. And changing a sit target doesn't currently move avatars once seated, special-casing it for this one function is going to be trouble. Best to leave that part alone.


Much closer to workable, but you know something? You're going to have to check those permissions anyway, if you want a script that behaves well.

Automatic animation stopping is a function of the client, it doesn't happen if the client is running on a non-Linden code base or if the packet monster eats that message, so good practice is still to explicitly stop them. The permissions go away (ETA: i worded that poorly, it's more that both permissions and presence are requirements to do animation stuff) if the client crashes, so permissions checking (and presence checking!) is still good practice to keep the script from shouting error messages.


Those are syntactic sugar rather than semantic changes.


Interesting. What happens if you change a sit target under a sitting avatar, and then run a new animation? Is that a problem?

"Automatic animation stopping is a function of the client."

Why does it have to be automatic? Does not llStopAnimation() do this server side?

lf llSitWithAnim() needs to stop an animation, and you think having the client do it automatically is problematic, should not llSitWithAnim() call llStopAnimation() as needed?




I don't know exactly how a sit works in SL, but it seems to me that the client sends a sit request... the server checks to see what animation is to be triggered, and sends that UUID out to the clients that need to see it, and then tells the clients to perform the sit... the clients already know the sit targets, yes? If there is a sit target change, the target is sent ahead of the animation UUID and the trigger.

I suppose there is no guarantee that the new target will arrive before the animation+trigger... but isn't that already the case?
Viktoria Dovgal
…
Join date: 29 Jul 2007
Posts: 3,593
06-17-2008 10:38
From: Ryder Spearmann
Interesting. What happens if you change a sit target under a sitting avatar, and then run a new animation? Is that a problem?

The sit target point changes (for the _next_ time someone sits) but the avatar stays put.

From: someone
["Automatic animation stopping is a function of the client."

Why does it have to be automatic? Does not llStopAnimation() do this server side?

It does, but lots of people have been getting lazy in their scripts and relying on the client to clean up after them since that message was fixed/added in the LL viewer. Hilarity ensues when people try to use lightweight clients for AI experiments, machinima, etc.

From: someone
lf llSitWithAnim() needs to stop an animation, and you think having the client do it automatically is problematic, should not llSitWithAnim() call llStopAnimation() as needed?

I'd be concerned about it. LL has been all along pushing more and more functionality away the simulators. That's why at stand time the official viewer takes on that role, if keeps track of all the avatar's running animations and requests stops for all the ones started by that object. Should the simulator really be keeping tabs on all that when it has enough trouble with all the other state it has to track? Does it make sense for the sim to track this only for the first animation started by this special function? Should it track other animations triggered by the object during the same sit, and update each time a script stops one before standing? (The LL viewer already does a lot of magical starting and stopping of the stock animations, some of quite intentionally random, and that's maddening enough. The recent stop animations after teleport "fix" broke stuff. That's the big thing that makes me leery of any magical behavior like this, LL doesn't have much on the way of an overall design so they can see what the consequences of implementations might be,)

From: someone
I don't know exactly how a sit works in SL, but it seems to me that the client sends a sit request...

So far, so good, the sim plops the avatar on the prim (on the sit target if defined) and pumps out the single hard-coded sit. The LL viewer will jump in when it gets toldthat a sit happened, see if the avatar's shape is male or female, and possibly make a substitution.

From: someone
the server checks to see what animation is to be triggered, and sends that UUID out to the clients that need to see it, and then tells the clients to perform the sit...


Just the object sit, that would be a constant, and that would happen after the sit brouhaha is finished.

From: someone
the clients already know the sit targets, yes? If there is a sit target change, the target is sent ahead of the animation UUID and the trigger.


Right now? The client doesn't care about targets. It tells the sim the UUID of the object or prim it wants to sit on. If there is a sit target, the sim plops the avatar on it and then triggers the changed event for LSL (the sim does extra silly things if there is no target). This is a recurring theme with LSL events, we're told what just happened, not what is about to happen except by inference.

From: someone
I suppose there is no guarantee that the new target will arrive before the animation+trigger... but isn't that already the case?

That's the nice thing about the "complicated" sitting model, you do know there really is something there with the changed event, and you can check that it's an avatar and if it's sitting where you intended.
_____________________
1 2 3