Pasted over from Hotline to Linden as suggested (many ideas for SL!) w00t

No, not looking to troll at all, if you read my first posts, you'll see I was being laid-back, civil, nice... and if you read my last post before this one, you'll see specific examples where I felt insulted, especially directly insulted, which as I stated, I never did.

As far as what it can do better? That one I've mentioned over and over until blue in the face. And not trying to be mean with saying any of this... but I said over and over, even quoted the Linden documentation in saying, that querying the dataserver takes longer, is slower, and adds to lag. I've even pointed out true and actual scenarios, where I had a person (Blue Stormwind) from above, there and present, who also witnessed that Targetting was much faster, and that I had to make a do/while loop for touching, etc, at least as far as getting the av key was concerned, because detection is slower, and doesn't return an exact value from the start, whereas Targeting does.

Also spoke of examples, and comparisons where sitting, the av key, from a SitTarget is right there, ready to use. When touching however, once again, must resort to detection, which I also explained over and over is slower.

The screen I spoke up which starts up dances, sometimes still takes quite awhile for the animations to begin, because the detection process is rather slow, whereas sit items, occurs rather fast... why, targetting more fastly returns the values needed as far as keys and such go.

I also stated examples above, wherein querying the dataserver can contribute and greatly add to lag. If a query to a dataserver needs to process that information and/or it adds to the lag factor, not to mention overhead bandwidth usage, think of the snowball effect or bottleneck you're having at events such as bingo, slingo, tringo, or even busy malls, dance events, games, etc. Tringo and Slingo as an example... you have 25 or so people all in a small area already, processing whatever they're wearing, using, etc, the surroundings, there you have your typical loading and bandwidth. Now add to that, every turn in the game, each person clicking their board... that's 25 or so simultaneous queries to the dataserver... that tends to make for uber-lag. Now, if when someone touched the board or the object, if it had a target function, and returned the key, etc right off the bat from said function, there wouldn't be as much need to query the dataserver. I dunno, maybe I'm just missing something, but it does seem simple enough for me. As far as the exact code, yeah, may be more easily understandable, but unlike some, I do have other responsibilities and issues to attend to both online and in RL, and don't always have all the time in the world to sit around writing specific code, and when I do, I use that time typically if writing code, to webscript, LSL-script, NWN-script, etc for already existing items, purposes, etc. Not to mention, I try and keep it on a conversation level, and in "laymens" terms, that way everybody reading can understand it. Yes, you understand the LSL code, I understand it, Seraph, and a couple other posters understand it... but in a feature suggestions forum, not everybody is going to understand the system code, so in displaying it in system code, going to lose people following what's being done, etc; perhaps even lose interest.

And for the record, yes Strife, I do feel you've been doing well at staying civil; like I said, it did feel like a slap in the face, when we were chatting amongst the forums in a laid-back form, I answered your post, thanked you, explained, etc... and then suddenly, there's a post where it didn't seem you were addressing me anymore and instead were addressing anybody that could read it, saying you don't support, etc, as if in a slight protest. That was the only part that semi-bothered me, albeit, not that badly. What bothered me more, as I said in the post above, was the direct comments made by Seraph. For me, forum posting, and chatting is more a "relaxed" sort of thing to do... I don't bring myself to forums in a classroom fashion, as much as I do rather in a lounged and laid-back fashion.


As I said, I never planned on coming here with the need to have the original base ideas already at a "documentation" level. And not to be mean or anything in saying this, since you're not really a coder or anything for Second Life, why would you need to be using my ideas in your documentations? hehe

PS - to make that example even more specific... think of a sim having multiple events within it... or think of areas that have hosting areas for tringo, slingo, bingo all in the same areas. Or again, the very heavily congested shopping areas, etc. Take it on a broad scale and add it all up, and pretty soon, you're dealing with King Kong sized laggage.

PPS - yes, I do realize there's a slight query with targetting on sitting... that's why I mentioned that I chose to use a half-second sleep event on the couch, so that said key could be gotten for animation poses. Now, let's compare, half-second on a sit, as opposed to 5-10 seconds and the need for a do/while loop on a touch. Better? Perhaps, possibly, and at least in my idea, yeah.

You do know when they refere to the dataserver they are talking about the dataserver event?

The documentation on Lag is incomplete. Querying the dataserver is not the cause of most lag.
Here is a short list:
Physics (are there 100 physical objects in the sim and are they coliding?)
Agents (agents are just as bad as physical objects)
Scirpts
How many listens are open
How many scripts use timers
How many scripts use sensors
Updates
Caused by scripts or physics
Textures
How many textures are in a area?


But lets look at script caused lag:
Most things that use sensors are security systems or sheilds. hmm anti social people cause lag...
Updates and timers go hand in hand. Most scripts that constantly cause updates are using a timer (or worse a sensor repeat). These are using things like venders that auto advance when nobody is around. Many vending machines also use listens. An area dense with venders will be using lots unique textures, like a mall. hmm people making money are causing lag...
Listens are usualy uses in avatar attachments for coloring or controling animation overrides. hmm fasion causes lag...

Running code constantly doesn't exactly help the sim. You see LSL is not an optimized language. Each time you call a function it has to re-populate the stack with the variables. It's very messy. So using the events actualy is a good thing.

BTW, here are some examples... (yes, I know the code isn't the neatest or could probably be done better... just threw it together quickly when making the objects they're on)...


As you can see here, I used a do/while loop to continually check for the permissions, to make sure they've been granted. Before this I placed an llSleep function as a test to determine the exact delay, combined with an llSay speaking "permissions granted" if the permissions value was anything but zero. In doing so, the permissions never became granted until about 5 seconds or more. Again, Blue Stormwind was there as a witness to this as I was making it, Upon further testing, I found it'd vary, anywhere from 2 seconds, to 5, to 10, etc, depending on the overhead lag, what state the dataserver might be in, etc. This is why I elected to use a do/while loop, rather than continually have it use an if/then with a jump or something. The do/while compensates for lag and or any slowdown, where as every if statement processed adds to processing.

Now the script I made for my couch:

Yes, not the best written, but it works. And as you can see, only have to have it sleep for .5 seconds, where as stated earlier, the detection takes 5-10 seconds, now what I was actually suggesting was the first using an "llAvatarOnTouchTarget" similar to how it's used in the couch script I wrote, which would return the key a bit faster, so as not to have need for a do/while loop, instead just a slight pause if anything.

Just in my teachings of scripting/programming, always seemed do/whiles or for/to loops were better used for situations where something was being constantly done, changed, etc, in this case, having to use a do/while loop for one purpose did seem a bit silly to me, but the best option.

Actually, thank you, you just hit on the head one of the things I was referring to. LSL is NOT an optimized language, and it IS very messy.

Now, as far as dataserver goes, yes, I do realize they're referring to the event, however, and I could be wrong, I was under the belief that detection was a hand-in-hand function, if not sub-function of the dataserver event, probably am wrong here now that I think about it.

But even so, as I pointed out, the detection is much slower than targetting, as I said in quoted script examples, which I had written, above.

And yes, I do realize what adds to lag... believe me, I've been online now about 14 years (yes, since the early days of dial-in BBSes, etc, yay), anywho, lag I'm very familiar with and what causes it. Yes, those other things do add to lag, as I DID state in my example above. But to add to that, 5-10 second delays per touch, per person, etc? Just feel there could be more and better "optimized" ways of retrieving data and returning it in a faster fashion.

Also, your referring to running scripts constantly is another good point I was making, thank you again. Granted my scripts don't run constantly, however, in checking for the permissions with a do/while loop, they do. Now, again, if the data could be fetched more quickly, and returned a bit more efficiently like in targetting, there wouldn't be such need for this, alas however, there is, and thus why I've decided to use a do/while loop for checking purposes. (Which strengthens my point in saying... if there was a way, be it targetting or however it might need to be done, to return values more quickly, or even a way to speed up detection, there'd be less need for overhead and constant checking, which you said yourself adds to lag.)

PS - My suggestion of more quickly retrieved data would also help slim down quite a few of those items you listed which cause some lag. Not all, but some.

The default delay between events is 0.05 seconds. This isn't bad because lag like this can easily ignored due to network latency. If i recall properly a command like ++ takes 0.017 seconds to execute (for integers). So really it's ignorable.

I assume you are starting that in a touch start event

do { 
    PERMS = llGetPermissions(); 
    if (PERMS & PERMISSION_TRIGGER_ANIMATION) { 
        if (GO == FALSE) { 
            float dnum; 
            dnum = llFrand(7); 
            if (dnum > 6) { DANCE = "Dance 2";} 
            else if (dnum > 5) { DANCE = "Club Dance 1";} 
            else if (dnum > 4) { DANCE = "Club Dance 2";} 
            else if (dnum > 3) { DANCE = "Club Dance 3";} 
            else if (dnum > 2) { DANCE = "Club Dance 4";} 
            else if (dnum > 1) { DANCE = "getdown";} 
            else if (dnum > 0) { DANCE = "HeadBang";} 
            llStartAnimation(DANCE); 
            GO = TRUE; 
        } 
        else if (GO == TRUE) { 
            llStopAnimation("Dance 2"); 
            llStopAnimation("Club Dance 1"); 
            llStopAnimation("Club Dance 2"); 
            llStopAnimation("Club Dance 3"); 
            llStopAnimation("Club Dance 4"); 
            llStopAnimation("getdown"); 
            llStopAnimation("HeadBang"); 
            GO = FALSE; 
        } 
    } 
} while (PERMS == 0); 

I see some major issues with this. First off it will run as fast as the sim will let it run. Meaning it will be sending constant av updates. When you stop the animations you are doing 7 stops which will require the sim to do 7 inventory lookups (name2key) then check the list of playing animations for 7 different animations.

Since you wanted this to run fast i've done some evil stuff (that will make it run faster). This code should work but haven't tested it. If there wasn't the speed requirement there would be less code. (i wouldn't copy the animation names out of the list and store in global).

list animations = ["Dance 2", "Club Dance 1", "Club Dance 2", "Club Dance 3", "Club Dance 4", "getdown", "HeadBang"];
string Canim;
string Nanim;
integer NanimN;
float range;
integer perms = PERMISSION_TRIGGER_ANIMATION;

default
{
    state_entry()
    {
        range = (float)llGetListLength(animations);
    }
    touch_start(integer a)
    {
        key p = llGetPermissionsKey();
        if(p == llDetectedKey(0) && (llGetPermissions() & perms)==perms)
        {
            llSetTimerEvent(0.0);
            llRequestPermissions(p, 0);
        }
        else if((llGetPermissions() & perms)!=perms)
            llRequestPermissions(p, perms);
    }
    run_time_permissions(integer perm)
    {
        if((perm & perms) == perms)
        {
            llSetTimerEvent(10.0);
            llStartAnimation(Canim = llList2String(animations, perm = (integer)llFrand(range)));
            while((NanimN = (integer)llFrand(range))==perm );
            Nanim = llList2String(animations, NanimN);
        }
    }
    timer()
    {
        if((llGetPermissions()&perms)!=perms)
        {
            llSetTimerEvent(0.0);
            return;
        }
        llStopAnimation(Canim);
        llStartAnimation(Canim=Nanim);
        while((NanimN = (integer)llFrand(range))==perm );
        Nanim = llList2String(animations, NanimN);
    }
}

changed(integer change) { 
    if (change & CHANGED_LINK) { 
        llSleep(0.5); 
        if (llAvatarOnSitTarget() != NULL_KEY) { 
            llRequestPermissions(llAvatarOnSitTarget(), PERMISSION_TRIGGER_ANIMATION); 
            integer perm = llGetPermissions(); 
            if (perm & PERMISSION_TRIGGER_ANIMATION) { 
                llStartAnimation("man-sitting"); 
            } 
        } 
        else if (llAvatarOnSitTarget() == NULL_KEY) { 
            llStopAnimation("man-sitting"); 
        } 
    } 
} 

Ok that will work but will have problems and produce error messages in certain cituations (that aren't so rare). It will also not handle multi sit target furniture at all well (error messages for the owner). It's bad to assume that the permission will be auto granted. This was a feature that was added that could be just as easily taken away. Multi-sit target scripts get ugly. Here are the bare bones of a pose ball script (that should work no matter what LL does). The permission check is used to catch a situation where a change event will not be triggered if the person logs while sitting on the object, 1.6 will auto release the permission when it can't find the av. The if statement in the perm code is to keep SL honest, we don't want some bizzare bug killing our code.

key user;
string anim = "man-sitting"; 
integer perms = PERMISSION_TRIGGER_ANIMATION;

default
{
    state_entry()
    {
        llSitTarget(<0,0,0.00001>,<0,0,0,1>);
    }
    changed(integer change)
    { 
        if (change & CHANGED_LINK)
        { 
            llSleep(0.01);//i'm not sure if a sleep is actualy needed. but i'll leave it
            key sit = llAvatarOnSitTarget();
            integer u = ((llGetAgentSize(user) != ZERO_VECTOR) && (llGetPermissions()  & perms) == perms) );
            if(sit == NULL_KEY)
            {
                user = NULL_KEY;
                if(u)
                    llStopAnimation(anim);
            }
            else if(!u)
                llRequestPermissions(sit, perms);
        } 
    }
    run_time_permissions(integer perm)
    {
        key sit = llAvatarOnSitTarget();
        if((perm&perms) != perms || llGetAgentSize(sit) == ZERO_VECTOR || sit!=llGetPermissionsKey())
        {
            user = NULL_KEY;
            return;
        }
        user = sit;
        llStopAnimation("sit");
        llStartAnimation(anim);
    }
}

LSL is much like Java when it compiles. LSL is a bytecode language. It is possible to take the bytecode and translate it back into a human readable LSL script (not that this is a good idea). Not only is LSL not an optimized language, there is only very limited ways of optimizing LSL code. Mostly inlining variables & functions and combining multiple lines of code.

(will post more later)

I think the root of the problem here is that Rayne is not using the run_time_permissions(integer perms) event. Instead the while loop is used after requesting permissions, until permissions are granted. Keep in mind that some of the delay with getting animation permissions from a touch event is that the user has to make a choice. I don't think automatically granting animation permissions on a touch would work well. Instead of polling the permissions in a while loop inside the touch handler the run_time_permissions() handler should be used to determine what the user answered back with. The key, Rayne, is that llRequestPermissions() is a one way call. Once called, run_time_permissions will fire as soon as the user has clicked on yes or no to the request. Also keep in mind that a script can only hold animtion permissions for one user at a time. So if your script has permissions to animate user A, then user B comes along, touches your object, and grants permissions to animate, the script will no longer be able to animate or stop animating user A. Rayne, I suggest checking out the following wiki link for more information on how permissions work, and the current best practices for using them:

llRequestPermissions()
llGetPermissions()
llGetPermissionsKey()
run_time_permissions

As a side note, the detected functions are in no way directly tied to the dataserver event. These functions appear to execute fairly quickly. The major delay in the permissions request that you experience is the fact that the user is prompted to decide to grant or deny the specified permission(s). Factoring in the time it takes them to read and respond to the query, this can be non-trivial, but you don't have to poll for the response, the run_time_permissions event is automatically triggered when a response is given. The reason this isn't needed in your sit scripts (but should be used anyway) is that upon sitting on an object the avatar automatically grants PERMISSION_TRIGGER_ANIMATION and PERMISSION_TAKE_CONTROLS. Like Strife stated, this could very well change in the future, and so as a best practice, you should use the run_time_permissions event to ensure you have the propper permissions before attempting to use them.

Best Regards,
McW

Hrm, I'll have to look into the run_time_permissions, dunno why but could have swore I put that in there.

As far as the couch script, may fine-tune it when I get around to it, and yeah it has to do 7 inventory lookups (be nice if there was a wildcard for stopanimation [maybe there is and I don't know how?], so can just tell it to stop all animations all together [just standing, not like you need to do a jig]... buteven though it does those lookups it still runs pretty quick and fine... it's the touch-screen that's the time issue. But I'll definitely look into the run_time_permissions for this, thank you.