More client side scripting ability

Client side scripting takes less bandwidth and reduces lag. Bandwidth = money. It would be an economically wise decision for Linden Labs to enable more client side scripting ability. The reductions in bandwidth usage, load on the asset server, and lag would be very significant. It makes me wonder why this has gone so long without really being implemented. The sooner Linden Labs implements this, the less money the will have to spend on bandwidth.

While I agree about SL needing more client-side scripting (particularly for doing smooth movement like llTargetOmega does for prim rotation and llSetTextureAnim does for texture animation), I don't think it would affect bandwidth THAT much.

/13/33/93040/1.html

SL wastes so much bandwidth in MANY other areas besides scripting I'd rather have LL improve THOSE areas first:

http://tnlc.com/eep/sl/index.html#improvements
/142/fc/102040/1.html
/invalid_link.html
/invalid_link.html
/120/91/30754/1.html
/13/9e/9750/1.html

Not only does it effect bandwidth but client side scripting is MUCH faster than server side. So many more things could be done with it.

I don't know what you people mean by "more client side scripting", because there's none right now. Some of the primitive parameters and attributes produce fairly complex client-side effects, but it's all strictly attribute-based. There's no ability to actually run scripts on the client side.

The client doesn't include an LSL interpreter, and I'm not sure it should... the client doesn't have to run thousands of concurrent scripts, and could use something like Javascript instead.

Note that this isn't anything to do with "HTML on a prim". HTML on a prim would run scripts that are isolated from the SL environment, they wouldn't have any access to the grid or to the client's knowledge of the world. I'm talking about stuff like...

// LSL code fragment
if(llGetPermissions() & PERMISSION_CLIENT_SCRIPT) {
  llClientScript(SCRIPT_NOTECARD,"facing.js");
  llClientScript(SCRIPT_IMMEDIATE,
    "target_prim.key = '"+((string)llDetectedKey(0))+"';");
}

// JS code fragment
if(target_prim.valid) {
  if(!self.attached)
    self.lookat(target_prim,0.1);
  else
    self.attached.lookat(target_prim,0.1);
}

I also agree with this -- having a express client-side-only LSL or Mono script (in 2.0) could overcome some limitations with the flexprims (you can't join two flexprims and have it act like just one). We'll need some communications betwen server and client, but it should give us enough rope to work nicely.

Client-side-only LSL wouldn't do anything for flex prim joining, Drake: According to this post:
http://secondlife.com/badgeo/wakka.php?wakka=flexible for more info.

Yes but remember the POINT about server-side scripting is to keep things in-sync with ALL clients in the area of (visible to) the scripted prim/object. Functions like llTargetOmega, llParticleSystem, and llSetTextureAnim show that not ALL functions NEED to be COMPLETEY in-sync with ALL clients so there's really no reason smooth positioning can't at least be added too (without having to make the prim/object physical).

Really all I think we need is an llSetRot() function that also has a time parameter that the client uses, that way you can smooth tail movements and such. For the purposes of collision though the movement would be considered to have occurred instantly on the server-side, so you don't have to working it out based on the moving object.

Client-side-only scripting could easily fake flexiprim joining, with a few extra calls.

vector llGetClientSidePos(integer side);
Returns the offset of the centroid of the indicated side from the center of the prim.

This information is available only to the client for flexiprims.

llSetClientPos(vector offset);
Moves the client's idea of this prim's location to the indicated offset.

And similar calls for rotation.

Then you could write the following code:

vector client_pos;
vector default_offset;
integer MY_PARENT_PRIM;
integer MY_ATTACHED_SIDE;

client // code executed in the client only
{
  state_entry()
  {
    llSetTimerEvent(1.0 / 60.0); // Or use llGetClientFPS();
    client_pos = llGetLocalPos();
  }

  timer()
  {
    llMessageLinked(LINK_SET,0,(string)(llGetClientSideOffset(0)),NULL_KEY);
    llMessageLinked(LINK_SET,3,(string)(llGetClientSideOffset(3)),NULL_KEY);
  }

  link_message(integer from, integer side, string offset, key k);
  {
    if(from == MY_PARENT_PRIM && side == MY_ATTACHED_SIDE)
    {
      if(default_offset == ZERO_VECTOR)
        default_offset = (float)offset;
      else
        llSetClientPos((float)offset - default_offset);
    }
  }
}

This fakes the hierarchy and is pretty manual, though you could easily automate it a lot more.