Stupid things

LMAO We don't have to defend anything, that's why they make the ignore button.

No problem. We all do a little complaining in the course of being constructive and helping each other, but you're just trolling.

The funny thing is that you're just having a little difficulty understanding the structure of LSL's library, and you could be getting a great deal of constructive help right now instead of pissing off the only people who do this kind of thing for free. If you run into this thread in a few months you are going to realize what an ass you were being, and that this is public record of it that will never die. Have a great day.

Then help. I posted the code.

Nobody is stoping you. Your choice... complain or help.

And you never answered... who is this "we" you spoke of regarding working on LSL. Are you a Linden coder? Did I offend your work?

Regarding LSL, complaining publicly about its shortcomings is reasonable. Moaning when others complain about shortcomings of LSL is pretty pointless, don't you think?

-Ryder-
(Who has never called *anyone* an ass in these forums)

Ryder, every programming environment has things like that.

When the creators design the standard library for a language, they have to make tradeoffs in designing the structure that they use. This means that some things will be harder that you'd expect them to be. (Try drawing a line in Visual C++. Try reading a string from a file in Java.)

Why no llSitWithAnimation? Because if there was one:
* You couldn't make animations designed to stack with an avatar's own sit (if the sit animation only moves the armature legs, the others could be moved by a stacked animation);
* You couldn't change the sit pose based on who sat, or the circumstances in which they sat;
* "Animation to sit with" would have to be loaded as a prim property, slowing down the rezzing of every prim on the grid.

It's all about design tradeoffs. To tell the truth, most things are.

Of course. I know dozens of languages from assembler on up... and I don't agree that you could not do the things you state. You would have to use other/additional functions for more advanced situations, but as all sits require an animation... (even if it is the default one) then why not?

And why do you say that the animation would have to become a property of the prim? I don't get that at all. They already call a default animation. Either the animation file is in the prim, or it is not... so why a prim property? Does llPlaySound() cause sounds to become properties of the prim?

Just an idea. A good one IMHO.

Also, keep in mind that LSL was supposedly developed in only TWO WEEKS. By ONE DUDE. Imagine if a thoughtful team spent another month on it... that would be a damned fine thing.

-Ryder-

I assume you left out some global variables at the top when you posted, preventing the code from compiling, so I added the following:

vector sittingPosition = <0,0,1>;
string anim = "TPose"; // my own test pose
key agentKey;

And the script works fine for me.

However, it could be simplified. llReleaseControls is unnecessary because you never call llTakeControls (nor request PERMISSION_TAKE_CONTROLS, for that matter). In the changed event handler, you have an "else if(agentKey == llAvatarOnSitTarget())", which is unnecessary, because agentKey was just assigned the value of llAvatarOnSitTarget() at the top of the handler. "else" alone is all you need.

I also wonder if your irreproducible pose difficulties (assuming it's not an issue with the animation itself or a conflict with any other running animations) might not be possibly due to the fact that you double-trigger the animation: In the changed event handler, you request permissions, then immediately call animate(agentKey), which in turn calls playanim(). However, you also have a run_time_permissions event handler (which is raised, because the requested animation permission is granted automatically, even though the user is never presented with a permissions dialog) where playanim() is called again.

You could easily dispense with the custom functions at the top, and handle everything in the run_time_permissions event handler. Ergo, we are left with:

vector sittingPosition = <0,0,1>;
string anim = "TPose";
key agentKey;

default
{
    state_entry()
    {
        llSitTarget( sittingPosition, ZERO_ROTATION );
    }        

    changed(integer change) 
    { 
        agentKey = llAvatarOnSitTarget(); 

        if(change & CHANGED_LINK) 
        { 
            if(agentKey == NULL_KEY) 
                llStopAnimation(anim); 
            else
                llRequestPermissions(agentKey,PERMISSION_TRIGGER_ANIMATION ); 
        }
    }
    
    run_time_permissions(integer perm)
    {
        if(perm & PERMISSION_TRIGGER_ANIMATION)
        {
            llStopAnimation("Sit");
            llSleep(1);
            llStartAnimation(anim);            
        }
    }
}

Which is about as bare-bones as poseball scripts get.

Because the sit target is a prim property (which persists even after the script which set it is deleted, just like position, scale, color, particle effects, etc.) which you propose to expand upon.


Yes, one default animation for all prims, which means each individual prim doesn't need a block of memory devoted to storing what animation should be played when an avatar sits on it.


No, because that is a transient effect of a function call in a script, which persists for only as long as the sound clip lasts. Prim properties can be set by function calls from a script, but persist for as long as the prim exists.

Actually, yes. llPlaySound and llLoopSound do add to the properties of the prim. Just start an llLoopsSound and remove the script to see.

It's just a UUID pointer to the sound, not all that big a deal.

I'd expect a sit-animation could as easily be part of the prim properties, but I don't expect it to happen because it would limit what we can do with animations. For instance, one of my helicopters checks the height of the sitting avatar, and if over a certain height it plays a second animation that brings the avatar's arms in and ducks its head a bit. I couldn't do that if the animation was a prim property, limiting me to the one animation.

Perhaps, but not constructive.


Isn't complaining pointless too?


me



http://www.secondscripter.com/

OK, in the first case the sit target is a property of a prim currently. It does NOT follow that all other aspects of a prim must therefore also be a property of the prim. Certainly a sound file contained in the prim does not. Therefore, the animation file contained in the prim would not either. If it is called, then it is used INSTEAD of the default animation. Without the call, the prim behaves precisely as before. A transient effect just like sound.

-Ryder-

Quote:

Then help. I posted the code.
Regarding LSL, complaining publicly about its shortcomings is reasonable.


Perhaps, but not constructive.



Are you sure? Perhaps it is too early to tell. You can *never* know where things lead.

But still, WHY assume it should be a property of the prim at all? I think that is a totally misguided notion to begin with. I see no reason for it, and like you, see that doing so would be a Bad Thing(tm).

The llSitWithAnim would set the sit target property, then locate and call the animation to act on the avatar one time.

At no point in that sequence of events does the animation need to be made part of the prim.

Interestingly, the sound does seem to have a need to be part of the prim... after all, the sound still plays when the avatar leaves... on the other hand, a sit animation for an avatar does *not*.

Yes, it works for me as well, though at its core, it is not my code... I left questionable bits alone as sometimes coders add things to make LSL more reliable (llSleep(1) between the stop and start animation?)

I will try this "cleaned up" version next chance I get... thank you !

Well, if "llSitWithAnim" would not make an animation part of the prim, then how would SL manage the information? The prim is the center of the universe for SL. Even avatars used to be prims (Primitars) way back in pre-alpha.

Prim properties include shape, color, textures, particles, hover-text, sound, physics, vehicle physics mods, roll-locks for all three axes, material, sit-target, association to an object, position in the sim or relative position to the parent prim, volume detection system, and inventory (associated UUIDs).

So, llSitTarget sets one property of a prim, so "llSitWithAnim" would by the nature of how SL operates have to also modify a property of the prim - what anim to play when an avatar attaches.

Basically, to change what you'd like changed would require abandoning the current paradigm. That just ain't gonna happen.

Well, animations are played by functions already, using animations stored in the prim, but not as properties of the prim.

How can poseballs work today, as they invoke animations, and yet not set a property of the primitive?

Clearly, poseballs do work.

The managing of the information is the same as any other function that calls the contents (not the properties) of the prim.... excatly the same way that animation functions read the animation file in a prim, and then act on the avatar.

When an object "say"s things, do those messages become a property of the prim?

I don't see that...

if(avatar_height > 2.1)
{
llSitWithAnim(0,0,0.1, ZERO_ROTATION, "TallDudeAnimation";
}
else
{
llSitWithAnim(0,0,0.1, ZERO_ROTATION, "ShortDudeAnimation";
}


no biggie. Both animations located in the seat. But you are perhaps talking about one animation modifying another?

The trouble is that you mentioned having the sit target being set at the same time. The way the system is set up, targets need to be set _before_ the avatar is seated. That's why the prim would need to know about the animation in this new function, you're mixing something that is a prim property with something that isn't.

I am talking about running two animations at once, one animation changing the other, yes.

Also, the way it works now, changing the sit target does not change the avatar's position, so I doubt changing the animation property would work either. It's really more useful as it currently is, IMO, as it gives us more options for dealing with animations.

And to respond to your other post:

The scripts in pose-balls &c are using a property of the prim (inventory: associated UUIDs). Apply a non-full-permissions texture to a prim: The texture becomes listed in the prim's inventory because it's an associated UUID element.

Be careful not to let how SL presents this data to you color your perceptions about how the data is actually stored in the back-end.

Well, I think that is the beauty of the idea. llSitWithAnim would simply set the target first, and then run the animation. After all, it is open as to how the function would be coded.

And really, there is nothing that says that llSitWithAnim even has to have the target parameters. That can be left out entirely, leaving only the animation call.

Note that there are different ways to set texture properties... like setprimitiveparams and then all of the individual texture functions... so multiple functions that get at the same thing is not new.

Note that I am NOT proposing a replacement of functionality or getting rid of existing functions... but imagine having to set texture offsets using setprimitiveparams each time. That *could* have been done... (read all parameters... change one... then set them all again), but ll had the sense to create functions to get at most of the parameters individually.

I am not talking about a new way... I am talking about an additional way.

Right, but that is ok... because inventory is already a property, and one objection to my function idea was that it would necessarily have to *create* a *new* property for *every* prim, resulting in a prim handling penalty across the grid.

I only see it being part of the inventory property load which is *already* the case in all pose balls. Not a new property at all.

Is this correct or am I missing something?

I see that a function can set the sit target property. I see that animation functions can visit the inventory property and find the animation... and then send it to the avatar. Therefore, I still see no reason NOT to have an llSitWithAnimation (that would bulldoze the permissions issue at the same time, hopefully).

Is the issue that there is a paradigm that one should not mix prim property functions and animation functions in the same single function? Just a matter of function compartmentalization?

I really am still searching for the technical issue here.

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.

Ryder, might I suggest that a JIRA submission about this proposed feature would be more effective than a forum thread.

Not missing a thing, really. I'd thought you'd meant to remove script control of animations, but as that's not the case I'd be all for your new function as an addition.

As suggested above, making this a JIRA issue would probably be a good idea if you really want it.

It depends on what one is trying to do.

And honestly, I have lost all faith/interest in JIRA.

Very broken, high priority stuff from years back are ignored... I'd rather tell Summer Seale my issue, and then let her take care of it for me