Client Side Scripting

Scripts at present are executed on the servers.

It occurs to me that there are things one might want to do with a script that could be executed on the client.

As an example, suppose you define a variable and display its value with llOwnerSay. There's no security reason why those commands need to be executed on the server.

One could add a new type of script if necessary, a client side only script, which could be used to do things like modify the prims in a hud while they are attached. Client side only scripts would not be able to use commands that modified the world directlly like llSetPos. It should be possibly to have client side calculations performed and then send the results to a server side script to do the part that involves modifying the virtual world.

The reason to want to use client side scripting is to speed things up for the user of the client side script and to reduce the burden of script execution on the server.

Indeed. Why shouldn't my HUD interface be able to manage itself and only communicate with the server only when it needs to set something on it? Why can't I create a graphical effect that requires using different world co-ordinates for each camera to view properly?

I could see a local llHTTPRequest without limits being very useful for some things.

Gods yes.

I suppose one could also have a llExecuteLocal(some way to pass valuesin). You'd need a way to pass values back; the functioin could return a list, I suppose.

If you wanted other people to share the code you'd have to get them to download it from you, shame we don't have file sharing buillt in.

How do you suppose we share notcards, textures, etc. then?

Isn't all this up to the open source client development community?

I am sure that if someone developed something useful, LL would incorporate it into the sl client.

What we need to do is develop ideas on what client side scripting could be used for.

I'm glad you are sure of that. I haven't seen LL incorporate much that is really useful to anyone except LL.

But, then again, getting rid of some of the server load could be useful to LL.........so we may win after all.

Oh, my comment about llExecuteLocal was about running normal programs like one would produce with Visual C# or other compilers, not about running LSL scripts locally.

Locally operatable sequences of LSL script commands could be distributed like other inworld assets, like you are saying, same as notecards and such are.

I wouldn't want anything running on my machine that could do more than running the code downloaded from the server. Calling external programs would be a very bad idea, imagine the chaos if someone calls something like "deltree /y" from an object.

It shouldn't be any more dangerous than JavaScript or Flash code being run on your machine.

Flash has a very limited scope of what it can do. As far as it's concerned it's the only thing that exists. It has no way to effect a file on your machine (regardless of its running on your machine or not). I can't even READ a file on your machine unless it's on your machine (and then it needs the path). The only javascript Flash can call has to be in the HTML page that the flash is embedded in (or .js files pathed to, see above about reading files).

Java also has a limited scope on what it can do.

ActiveX on the other paw CAN do nasty stuff to your machine.

Javascript and flash are specifically limited so they can't call external programs from your HDD.
JS can't even interact with local files except through the browser (cookies etc), flash has to be run from the local drive and have permissions granted IIRC.

Edit: beaten to it again. I was going to mention activex, but have never used it. Anyone know if it's not limited in the same way, or is it just MS bugs that allow all the nasties?

I'd be happy if I could use the HTML floater from LSL, with or without Javascript in that...

How about it?

if (llGetPermissions() & PERMISSION_OPEN_WINDOW) {
  llHTMLWindow(100,100,120,120,
    "<form action='chat:14132'>
      Instead of calling a bunch of dialogs, would you like to be able to
      put up an HTML form like this?<br/>
      <input type=text name=answer value='Hell Yes!'>
      <input type=submit value='Go for it!'>
    </form>");
}

//...

listen(...)
{
   if(channel == 14132)
   {
     list responses = llParseStringToList(msg, ["&"], []);
     integer n = llGetListLength(responses);
     integer i;
     for(i = 0; i < n; i++)
     {
       string s = llList2String(responses, i);
       if(llGetSubString(s,0,6) == "answer=")
         llOwnerSay("You answered "+llUnescapeURL(llGetSubString(s,7,-1));
     }
   }
}

Proposed as VWR-394.

Using it with HTML on a prim would be nicer, we could achieve the same effect using a HUD without having to float it in a window.

Last I heard they were still fighting with the problems of entering text into HTML in-world, and having Javascript running in HTML on a prim strikes me as just asking for trouble... how many baked texture updates a second do you think SL could handle?

In any case my proposal is kind of peripheral to this one, so I've started a separate proposal for it. Sorry for the digression.

As I understood it, the browser window was being rendered in OpenGL same as HTML on a prim would be. Am I wrong on that?

If this came to pass we would finally be able to have labled text entry fields, like I asked about in the Linden Answers forum at /139/2a/146213/1.html in September of 2006.

It would be wonderful. Currently a lot of scripts require some kind of tedious method in inputting values, either typing commands like dos commands, or editing the script itself or editing notecards. This is a pain so people just don't use scripts or make only partial use of scripts because they can't remember the commands or get tired of having things go wrong because they made a typo in editing a script or notecard.

IMHO, most of that could be eliminated with scripts making good use of the HUD and chat.

I would rather "type commands like DOS commands" than go through "click on this button, then type the name of the target, if you use quiet mode remember to enter "/9" before the name...". And then there's the ones that don't have a "quiet mode" at all, so you have people standing around talking gibberish at their HUDs.

I'd rather type commands myself for a lot of things, but it's quite confusing for some people; I've seen people having trouble entering web addresses. Plus the channel thing is still present with that as well, remember.

I think I was having a go at bad interface design using the current features rather than trying to add anything to the topic, don't actually remember writing it.

Anyway, I'll echo my thoughts from your thread about using the HTML floater here for the hell of it: shouldn't it be possible with some modifications to the OS client? Look for an identifier in the open web page call (I forget what it's called right now) then route it to the floater and return the result in chat.