Stupid things

In this edition of stupid things:

Sitting.

The most astoundlinly stupid level of scripting complexity is the simple act of sitting. After hours of research, I still can not get my avatar to sit reliably using a simple 2 frame animation.

Much of this stems from the utterly pointless permissions gibberish needed to handle all of the multitudes events.

Why on earth must permissions be obtaind to trigger animations for sitting? Is not the user already showing the full intent to have the avatar change position by selecting to sit in the first place?

Why does standing require the stopping of animations? Should it not simply stop them?

llSitTarget()
and
llStartAnimation()

Should just simply work. Permissions should be assumed for all sits. ending animations should be assumed for all stands.

There probably should be an llSitWithAnimation() function that has the target and the animation as arguments.

*sigh*

/me wishes there were lindens working on making lsl better.

I've never used these functions, but the elder wiki entry may help you better understand the whys and hows.

http://lslwiki.net/lslwiki/wakka.php?wakka=llStartAnimation

Good luck.

one of the main things with standing and animations is, standing is a animation in itself and it basicly overides all other animations if done wrong and just think LL is probuly working almost 24/7 with SL there is probuly tons and tons of codes

SL's scripting system is pretty generic; made to at least attempt to be able to do anything you want to do with it. That means that animation and sitting are independent features. No, they didn't build into the basic system much of a bias toward using the two together (really the only instance I can think of is that certain permissions are granted automatically--that is, without a blue dialog, not without requesting them--when the requesting script is on an object the avatar is sitting on).

I think this is a GOOD thing, and what small bumps in the learning curve new scripters have to overcome are outweighed by the wide-open nature of the system. One of the big reasons for this forums' existence is to help folks overcome those bumps, so when you come up with bits you aren't understanding, you might try asking for help here instead of immediate and complete ranting. We're happy to help!

exactly, why sl is called a vertchuel world, it is literally a world in its own were anything is posible with the right scripting knowhow (spelling is probuly way off going to sleep lol)

I agree, it does get a bit complex, and perhaps some new functions combined with some simplification might be in order. Personally, when I've had issues understanding a particular function or, in this case set of functions, I head to the wiki at http://rpgstats.com . I find the explanations there to be a bit more friendly than the ones at the regular wiki hosted by LL. The LL wiki though, does have the latest and most up to date information. Perhaps head to rpgstats and read up there for a bit better explanation.


http://www.secondscripter.com/

I do not agree about the complexity in this. The hole thing has a lot of sense in it, when you realize how it prevent abuse of other avatars. How would you prevent me make your avatar do animations against your will without the permission request?
Sit and stand are just animations ( with different priority ) like all others so why should they be treated differently?The permission is given implicitly when you choose to sit by touching a chair. It is in the script if you use a scripted sit, but is that a problem?

Well, what I think he's driving at is that the avatar's actually already right clicking and choosing sit, which would imply permission as opposed to a script forcing an animation on someone. I think everyone agrees that permission is required when someone else is requesting to animate, but a self induced sit shouldn't require permission.



http://www.secondscripter.com/

I see the request rigmarole as insurance. If any of the several permissions silently granted for attachments and sitting turn out to cause problems in the future, LL can enable the dialogs for the problem ones without breaking scripts. And since animation permissions are persistent, even sitting carries a small risk.

Actually, it does. Any animation triggered in an avatar by an object upon which that avatar has sat will be stopped when said avatar ceases to sit (whether by "standing" or TPing elsewhere).


A number of permissions are automatically granted when asked of agents sitting on the object containing the script, or avatars to which the object containing the script is attached, but the permission must still be requested (if for no other reason than the permissions key defines what agent receives the action of the functions to which the permissions apply).

As to your difficulties, could you possibly post your code so that we may help you find the error(s)?

Scripts which assume automatic permission and do not place relevant code in a run_time_permissions event handler will be broken, e.g. placing an llStartAnimation call immediately after the llRequestPermissions call.


I would think this would best be handled by blanking the permissions bitfield when a sit ceases (or at least zeroing the automatically-granted bits), rather than invoking the permission dialog. Assuming a "properly" written script which doesn't assume permissions will be automatically granted, this would require the user to grant animation permission every time they sit on a scripted chair with a custom sit pose, but that permission would still persist after the sit ceases.

You can take a look here for a poseball script that stops all running animations when you sit and starts the one you want for any ideas that might help:

http://wiki.secondlife.com/wiki/AO_Overriding_Pose_Ball

And as for:
"/me wishes there were lindens working on making lsl better."

Most work on LL functions has been stopped until MONO is fully integerated into MG. That being said there was a recent thread on 3 new functions which will hit grid soon and Kelly is working on adding a sorely needed new function; http_server. That one should hit MG in about 6 months or so but will be in Aditi for testing before that.

Those scripts are already broken, they only accidentally work in root prims as it is.

Assuming that animations will be stopped at stand time is also broken, FWIW. That's client-specific behavior and not all of them send the messages to do that.

I went to rpgstats.com.... got a blank page. nothing there.

Yeah, but what about experienced scripters?

And do you really think that THIS:


playanim()
{
llStopAnimation("Sit";
llSleep(1);
llStartAnimation(anim);
}

animate( key id )
{
if( (llGetPermissions() & PERMISSION_TRIGGER_ANIMATION) && (llGetPermissionsKey() == id) )
//if we have permissions to animate play animation
{
playanim();
}
else
{
llRequestPermissions(id, PERMISSION_TRIGGER_ANIMATION);
}
}

default
{

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


changed(integer change)
{
agentKey = llAvatarOnSitTarget();
if(change & CHANGED_LINK)
{
if(agentKey == NULL_KEY)
{
llStopAnimation(anim);
llReleaseControls();
}
else if(agentKey == llAvatarOnSitTarget())
{
llRequestPermissions(agentKey,PERMISSION_TRIGGER_ANIMATION );
animate( agentKey );
}
}
}

run_time_permissions(integer perm)
{
if(perm & PERMISSION_TRIGGER_ANIMATION)
{
playanim();//we have been granted permission, so we play anim
}
}

}





is better than THIS?

llSitWithAnimation((<0.0, 0.0, 0.1>, ZERO_ROTATION,"mysit";


I think that is indefensable.

Thank you Deanna, yes the code is now posted.

Related issue: animated sit position is not repeatable sit to sit.

Thanks!

-Ryder-

Then just stay away from LSL. Sorry, but it is set up the way it is and all of the rest of us work with it and it works just fine. There are always a couple of things about every single language I work with that I think might be made a little different and better. I work around them and get on with the code. At least with LSL we have jira to suggest new functions or changes.

I guess we all thought that you were also kind of asking for some help too. Evidently that isn't the case.

re: LSL


This is rich.

No, Jesse. LSL does not work "just fine".

If it works fine, experienced programmers would never need be in the forums.

Can you make a sit animation reproduce it's sit position precisely every time?

If you can, I'd appreciate knowing how that is done.

What about llAnimateAndUnanimateOnTouch(...) for dance machines? What about llWarpAndStandOnSit(...) for teleporters? What about llRezObjectOnTouch(...) for certain HUDs, and llGiveMoneyToRandomNearbyAvatar(...) for contests? Those seem pretty indefensible to ME.

A script to play an animation when an avatar sits is not very complex, may be even simpler if you know the animation isn't looped, and can be made into an easily configurable template for easy reuse by just about anyone. Ask any scripter who has been here for more than a couple months and they will almost certainly hand you a script for playing an animation when you sit that you can customize to your heart's content. The permission and animation systems as they are now are more than adequate for this kind of application and allow for all number of different applications as well. Start introducing a bunch of redundancy to the API (multiple ways to do the same thing) and you will not only confuse people even further, but you'll square the complexity and introduce any number of extra places for errors to crop up (SL is buggy enough as it is). No only that, but you're going to have to specify how your new function interacts with all the exsiting ones (what happens when the existing animation functions are used while yours is in effect, for example?).

Works just fine for me and you really should look at the link I posted because in many cases you need to stop more then just one animation.

This is the way I see it and just my personal opinion. Many wonderful things have been created with LSL. There has been absolutely nothing that I have wanted to create that I haven't been able to create. An incredible amount of hours have been poured into and are being poured into the back end to get LSL working, add new functions and keep it working. Can't even imagine how many more hours have been spent doing the switch over to MONO and making it so that nothing old is broken. Whenever I am learning a new language I may spend some time being incredibly frustrated also, BUT>>>>>>>>>>>> The difference is that I am frustrated with my lack of understanding of the language, not frustrated with the language itself.

You are bitching and moaning that sits and animation permissions are horrible and bloated and that LL spends no time working on LSL. This is simply not the case, multiple people have come on and stated that there is a method behind the madness and you refuse to accept that. Again, both my code that I linked and the code for animating sits from others work just fine. Both SL and LL are not perfect by any means, in fact right now the asset server bites big time. But I sure wouldn't want the task of creating my own language from scrap, nor try keeping everything working with this much concurrency. But many of the guys and gals at LL are working serious overtime to fix these problems.

Lost count of how many times I have caught some of the QA crew on at 3 AM, thier local time, tracing down problems. Can you say that for yourself and your job? I know I can't.

You say that "This is rich", well what is rich is that mine works.

You're absolutely correct. LSL does NOT work "just fine." So let's concentrate on fixing the parts that DON'T work. You're suggesting (if not demanding) we focus on "fixing" the parts that DO work just fine already, and that most people are happy with. What kind of reception do you think that's going to receive here when just about every scripter contributing to these forums knows there are SERIOUS issues that need to be addressed, like scripting access to estate tools and correct behavior for things as simple as rotating a child prim. :-/

opps, sorry, try here...
http://rpgstats.com/wiki/index.php?title=Main_Page





http://secondscripter.com/

You are inventing functions that while interesting, are not integrated into the user experience.

The PIE menu has Sit and Stand. Functions to serve that level of user experience could use some refinement.

You will not find such integration for Warping n stand ... and rez on touch is already a single line of code.

I rest my case.

Thanks a bunch, looks awesome.

Excuse me, but who is "we"?


And all you are doing is saying that LL is way behind.

How about they make HUDs touchable in mouselook again... been waiting on that one for well over a year.

How about llName2Key?

The JIRA is choking on work to be done, issues to be addressed.

And your basic argument: "you should shut up because there are worse things" is simple fallacy.

I get to complain about LSL because it is a thing.

Now, defend you and others complaining about me. Step right up.