Script features to reduce lag

Hi,

Following up from a thread on Scripting Tips I'd like to know if it would be at all possible to implement some scripting features which would serve to enable the number of scripts in each item to be reduced, thus greatly reducing lag. Namely:

a) Link versions of llSetPrimitiveParams and all its descendant functions (yes, including llSetLinkTargetOmega).
b) llGetLinkNumberNamed, a function that returns the link number of the prim with the specified name if it is linked to the current object. At the moment, some scripters/builders are forced to use scripts in every prim while they are working on objects because if a single script is used, all the settings are based on link number, which can change frequently and erratically if the build is still being worked on from time to time.
c) llSetPosRate, a version of llSetPos that allows the speed at which the object moves to the new location to be specified;
d) a flag on the object (the root prim) which disables enforced sleeps on functions which have them. Since the flag is on the object, a scripter could not create a runaway object by mistake (flag would be unset by default) and if one did go runaway unintentionally, the scripter could unset the flag, causing the sleeps to return immediately. Optionally, the flag could only be set by "trusted" users based on payment status or similar. Lindens would have an option to disable the flag globally across the grid in case these features were being used for an attack.

Although I understand implementing these functions might be a lot of trouble, I hope that the consequent lag reduction when scripts can use these will be worth it!

I vote for this!

integer link_dirty = TRUE;

check_links()
{
  if(link_dirty)
  {
    integer i;
    integer n = llGetNumberOfPrims();
    for(i = 0; i < n; i++)
   {
      string name = llGetLinkName(i);
      if(name == "this name")
        this_name_link = i;
      else if(name == "that name")
        that_name_link = i;
      //...
    }
    link_dirty = FALSE;
  }
}

changed(integer what)
{
  if(what & CHANGE_LINK)
  {
    links_dirty = TRUE;
  }
}

This is almost certain to be more efficient than having llGetLinkNumberName(), because unless the latter is used in code similar to the above (with calls to llGetLinkNumberName() instead of the loop) scripts will be redundantly traversing the whole link hierarchy over and over instead, or LSL will have to cache and update this same information internally... and I don't trust LL's caching.

The delays in many functions that make bulk changes in prim status produce erratic updates seems to be a bigger motivation for this.
I vote for this.
Interesting. This would address the problem above, but I think the flag should need to be set on the script *as well*, or it should be limited to scripts writable by (or even created by) the person who set the flag, otherwise people would set it on objects containing non-mod scripts written with the built-in delays in mind and you'd get all kinds of misbehaviour.

There are so many really awesome things I could do if I had that function.

>llSetPosRate, a version of llSetPos that allows the speed at which the object moves to the new location to be specified;

From the wiki
http://www.lslwiki.com/lslwiki/wakka.php?wakka=llApplyImpulse

setVel(vector newVel, integer localAxis)
{
     vector curVel = llGetVel();
     
     if(localAxis)
     {
          rotation rot = llGetRot();
          curVel /= rot; // Un-rotate curVel.
     }

     newVel -= curVel;
     newVel *= llGetMass();

     llApplyImpulse(newVel,localAxis);
}

A physics enabled item has the same physics sim loading as an avitar, so limit it's use unless an avitar is going to be sitting on it.
Edit: typo

That's kind of the point of suggesting llSetPosRate(). I do a lot of effects with llTargetOmega(), such as door open/close animations. At this point, I'm fairly adept at making low-lag smooth animation for anything that moves rotationally, but it'd sure be nice to be able to do similar for translational movement without using up valuable physics processing.

OhBoy, you just brought together a bunch of ideas I've had aboutthe problems of llTargetOmega, the lack of a smooth non-physical translation, and joints. Thanks!

How about llTargetPosRot(vector pos, rotation rot, float rate, float timeslice); (as well as a "local" version for linked prims) that would change both at once, for doors moving around centers other than the edge? This would be non-physical movement along a path, updated every timeslice seconds (from 1/35th of a second). The movement would be non-interruptible and the object would be phantom while it was going on: the sim could simply phantom it at the beginning of the movement and let the client simulate the transition - the timeslice would be a hint to the client as to how fast to run the transition.

This would give you:

* A way to do a lot of joint effects without the side-effects and lag of joints.
* A way to get reciprocating llTargetOmega effects without jumping at the end when there's lag.
* A way to handle sliding doors and other similar parts.
* dot dot dot . . .

Grumble, I know how old you are and you should know how to spell "avatar."
To everyone else that uses an "i" in that word:
QUIT IT! THERE'S NO "I" IN AVATAR!
It's an easy word. One vowel. A-V-A-T-A-R.

Are you some kind of unvarified account type?

Seriously... Great suggestions Yumi... (however I do agree with Argent on the llGetLinkNumberNamed() function.)

Likewise I've been wondering if some of the dampened rotation/translation functions for physical objects could be applied to non-physical objects, in such a way that as far as the sim was concerned the object jumps from point A to point B roughly half way through the damping period... and on the client, there's a smooth progression from point A to B during the damping period.

It'd cut down on collision checking, push a lot of updates and processing to the client and look much better, despite the slight out-of-sync effective behavior.

I'd be all over it like jam on toast.

I have started a proposal for llSetLinkTexture()

maybe if we cant get the whole linked params feature we can at least get this passed.

http://secondlife.com/vote/vote.php?get_id=2239

They are working on something like that... it's called "Mono". Only time will tell.

However, velocity implies a physics engine. It may not be havoc, but it must be some type of physics engine.

I see this as a physics engine upgrade, not a scripting upgrade since the scripting system already has a method of setting an object to move smoothly.

Rumor has it that LL is working on a client and sim physics engine upgrade that will allow for more things to be client side processed. The Sim would still have priority, but the client could handle both speed and acceleration in-between sim packet updates.

Right now you can make lots of objects physics based and still keep the sim from laging as long as they are phantom. For example. I am working on a physics based vehicle that does not use the vehicle system at all.

Yeah, it's called ODE (not Ohio Department of Education )

Open Dynamics Engine, it's a free open source engine with some licence jumbo stuff to go along with it. I'm sure you'll understand all that, but if you want to look more, go http://www.ode.org/

EDIT: The engine is nice, I tell ya.

Mono has nothing to do with this. This would be a change in the *client* and a change in the sim to send a new message to a client to do the rendering. Whether the script's compiled to LSL bytecode, Mono, Forth, or UCSD Pascal bytecodes is irrelevant.

That may make existing scripts run faster. But the real problem I was getting at here was based on a comment on Scripting Tips that once a sim gets above about 3000 scripts, it starts to lag, no matter how well written the scripts are.

At the moment, to move a non-physical object at a speed other than either a) the maximum possible or b) so slowly it stops every 2 seconds, requires a process farm of 4-8 scripts. Writing an object that quickly communicates with a server object in another sim requires a farm of 3-20(!) scripts. Someone has asked me recently to script a big networked project - not just a single vendor or similar, but an (small) area that will load its features from a network server and update regularly - and although it's possible, it's a nightmare of parallelism. Once I've put the "set this prim's texture/settings" script into every prim and created the e-mail farm to talk to the server, I'm already on 50+ scripts in that single object. And that's before any actual functionality! Given that this thing is supposed to be offered to others to include in their builds, that doesn't seem very ecological

I asked LL about this - ie, if we're allowed to create these functions, why not allow people to do them without having to resort to awkward workarounds - and their reply was that in order to create a process farm, you a) have to know what you're doing, and b) have to be doing it on purpose - which would therefore, via a) make potential griefing harder and via b) make accidential damage less likely.