How can I reuse scripts or reduce maintenance on existing ones.

Hi,

I have some programming experience in RL, but I'm a beginner in SL scripting. I wonder how I can reuse my SL code. If I build 2 scripts that need the same piece of code, I could write this code in one script and paste it in the other... But then if I find a bug in it, I have 2 scripts to modify. And if this script is present in 5 copies of the same object, I have to modify each object, or modify one and erase the others and replace them with the new object. How can I keep one "master" script somewhere and have the objects that use it, use the last updated version of it...

Also, lets say that I write that nice piece of LSL that does something useful and that I could use in many other scripts. How can have it stored at one place, maintain it, improve it there, and call it from all my other scripts. It would be great if I could build my library of utilities functions or scripts, make them evolves and if I correct a bug in one function, all my scripts that use it benefit from the new version.

Feel free to points me toward existing documentation about it, I'm sure there's some docs about it (just can't find anything).

Thanks!

TiGuy Goalpost

Not sure if this is what you want, but go to your favorite lsl wiki, and look up llRemoteLoadScriptPin and llSetRemoteScriptAccessPin. Also look up the free updaters out there, and see how they do things.



This is probibly not what your looking for, but I've had to use several copies of the same script in an object for emailers or IMers. What I did was used the SL's own naming conventions in the prim, if I put in 5 copies of Emailer into the same prim, the names would change to Emailer, Emailer 1, Emailer 2... Emailer 4. I just had the script read it's own name, and assign the number given by SL to a variable to identify what script was pointed to by the controlling script. Takes a bit of string parsing, but it worked well. So when I made a change, or fixed a bug, I would change the one in my inventory, delete all the scripts in the prim, and put in as many copies of the "updated" script into the prim, and not worry about the unique Identifier for every script, since it was done automatically. From what it sounds like, you want to do that, and also use what I suggested for the remote loading of a script. Combining the two might get you what you are looking for.

Hope that helps you

EDIT: OK mine was a crappy response and even though I wasn't trying to be crappy, it still read as crappy

Let's try again, Lazink answered part of your question. The other part of your question pertains to using includes and unless I read it wrong, maybe even dynamic includes. You can not use includes in LSL, at least not in world. But you can use includes in Scite for example if you code in ESL and send it through the C preprocessor. There might even be some other alternative editors out there that can compile includes.

I use LSLEditor for all of my scripting and for simple things that I use in just about every script, such as common variable decorations, short functions and version Control headers, i have saved as my default template so that every time I select new script they are loaded.

I then open source library's in separate windows and cut/paste to the new script, for more advanced functions or event handlers, such as my standard LinkMessage addressing and decoding headers.

I also keep copies of full source, documentation and function libraries on Goggle docs so that if I need to give another coder access to a library i can just pass a link.

I try to avoid having to many scripts in the SL inventory as it is hard to manage, so once I am ready to test my code in SL I, do a syntax check in LSLEditer, open a script window in SL, then use the "Copy All to SL" function in LSLEditor. Any changes I now make on line as I test the code I make sure i copy back into LSLEditor on a regular basis.

It is probably not the ideal solution, but for an amateur scripter I find it works well, enough for my needs. But I really would like to see a #Include function in SL so that libraries could be created and distributed without exposing the code.

Didn't I read something recently that (and you know I have next to no understanding of this so I will appreciate being straightened out) if you need to use the same script and you use the exact same compilation (in mono), that it's more efficient?

Note that while variable decorations are not an essential part of scripting, they do make the scripts look prettier.

Alternately, variable decorations, although more trouble to make, can be used on many different types of occasion, unlike simpler static decorations.

Unfortunately, there is no easy way to deploy new versions of scripts. Even the llRemoveLoadScriptPin() has plenty of drawbacks. What I do is keep very, very good organization of scripts and the objects they go into in my inventory. And when I change a version number on a script, I re-stuff it into the objects that depend on it and immediately change their version numbers as well.

You can re-use scripts by placing the same script in multiple prims or objects, and you can even make re-usable modules in a sense by having them interact with other scripts through chat messages and link messages. What I sometimes do for large enough bits of functionality is create a (in-line) "header" with link message commands (and replies, since there's no way to make a synchronous call) enumerated by (semi-random) numbers and a documented protocol for the string and key parameters. Then by pasting the header into scripts that rely on the "library" I can create SOMEWHAT loosely coupled modules. It is less often that one of these "headers" needs to change--at least if you break things up well--than that the private implementation has to change.

There was a poll conducted by LL sometime last year--around the time Mono was hitting the Main Grid, I think--about what residents would be interested in in terms of future features. One of them was compiling C# as well as LSL. One of them (that depended on the C# feature) was being able to call DIRECTLY into another script in the same prim. As in a method in one script calling a method in the other without explicit link message serialization. Of course, like most tidbits from LL, we have never (that I know of) heard anything about it again. Maybe 10 years down the line....

Yes. This post explains it better than I can:
/54/af/289601/1.html#post2193208
.

Chances are every time you write a new script you'll have snippets of code that you can set aside for quick reference. I keep a folder for snippets that I commonly use in my inventory so I don't have to type them over and over again. I also have "wrappers" I use for various projects, like a notecard reader wrapper with built in code for permissions. Then I just fill in the rest of the code for the script I'm trying to write. One thing I suggest is to make an offline database of your scripts and snippets on your computer. A tree database like Treepad is perfect for this. Another thing I do, if I know I already have a project in my inventory that has a piece of code in it I need for a script, I'll just pull out that object and grab the code I need. All of these things make my own scripting work more efficient. I have switched from using version numbers to dates because version numbers aren't very descriptive and I find dates are a better way to determine exactly when the last version of your script was written.

Hi.

There is no import function, or OOP support.

LOL, I really should have Coffee in the morning before I login. I won't be popular when the other half gets home from work to find the Lounge has been redeclared either

It's come up again but it's not too promising at the moment. Right now there isn't anyone working full time on scripting functionality, and other features are higher on the list. More:

http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2009_01_07

Couple of items that may be similar to the concept of "includes"...

Functions.

You can make user-defined functions. Functions can be pre-written mini-scripts that you reuse again and again in each script. An example of this might be "CoolSay".. which is a function orginally shown to me by jadz0r Conover.

If you want to format all the text from a given object in a certain way, you can use a coolSay function to do it.

coolSay(integer channel, string message)
{
     llSay(channel, "[" + message + "]");
}

This is a very crude example.. but you'd use it the same way you'd use llSay.

coolSay(0, "Hello Avatar";

While this isn't the inclusion of a large script, a function can be fairly complex.. doing things like word-wrapping, for example.. or perhaps you might have a "giveMenu()" function that would doo all the fancy listen closing, random channel selecting, and listen opening for you.

Slave Scripts

You CAn also have "plugins"... that is, other scripts that do specified tasks, on command from a master (core) script.

Here's an example.

I have a script, whose entire job, is to wait for a linkmessage. When it receives a linkmessage like "673, "red", NULL_KEY"... it will take the word "red" and check it against a database. the script will parse the goven string, to see if it meets the criterial for a vector, or if it meets the criteria for a hec code for a color, or if the name is one of the 140 colour names in it's list. If it can decode the input, it will spit back another linkmessage, that simply says "674, "<1.00, 0.00, 0.00>", NULL_KEY"...

the master script then has it's own "wait for linkmessage" section, and when it receives a response, it does whatever it's gonna do with that colour vector.

I've built a plug-in for my updater package, that waits for a linkmessage "update".. and then runs it's functions.

Some scripts, particularly non-physical vehicle scripts, use llSetColor rather than llLinkMessage, to communicate a vector to several scripts at once.



While niether of these will give you the "remote" element you were hoping for, using modular things like these CAN make updating easier.

Hi,

Thanks everybody for your help, I read carefully all your answers and I'm doing my homework to understand all that good information. I tested llRemoteLoadScriptPin and llSetRemoteScriptAccessPin and it would do a part of what I'm looking for. I was able to have a script in prim A transfered into prim B and executed there. It means that if I have many prims that use the same script, I could modify the official version in a "master prim" and have this prim transfer the updated script sto the other prims that use it, if I have their keys and if the pin is ok and IF the prim is on the same sim.

It's a part of what I want to do, but there are 2 issues with this...

1) From what I read on the wiki, the prims have to be on the same sim for the txfer to work.

2) I have to know the key of the object I want to update, and from what I tested, the key changes if I delete it and rez another one.

Let me give you more info on what I want to do... I wrote a script that turns a prim into a radio. You click the prim and it displays a blue menu and let you change the audio stream on your land (assuming you have the permission). I gave a copy of this simple radio to many of my friends and I keep improving the code when I have time. I'd like to have all the radios that I gave away automagically updated to my last version of code, when I'm ready to release it. It involves that the radio checks if a new version of code is available, and gets an updated version if required. The radio can be anywhere in SL and the official version of the code will be in my inventory and in a prim on my land.

Thanks in advance for your help!

Your hitting another issue, radios/tvs/movie screen, whatever, that use land parcel settings must be deeded. You are going to run into that issue, of the deeded object becoming no modify, even if you set it up to be, it'll probibly happen.

However, to answer your concern about the update part, it all depends on how you want to go about doing it. You could save the version number on a website and have the radios periodicly check in to the website to check for the latest version, you can have the person who owns the radio click up button to check for an update via this way too. You could have a main server on your land that you don't move off your land or pick up, that holds the version key of the newest version, and the radios email occasionally to the server, asking for a version check, you could make a group and pass out the radio that way. There are lots of solutions to the update problem, and there is lots of information on different update systems on this forum and in the wiki.

The loading of a remote script into a prim on the same sim, isn't that bad, you just give the update object to your customer (again you'll run into deeded issues here), and they updater next to the radio, touch it, updater sends out a sensor, looking for the radio, get the key of the radio, and loads the script.

Really it's about what best you feel comfortable with, and what you understand. There is really no right or wrong way to do an updater, yes some may be easier then others, or more reliable, some people think http_requests are reliable, others think email is better. Make a choice and roll with it.

A lot of people use a kind of "update system" whereby customers will be sent new versions of a product when it becomes available. It involves an object in-world that you use as a "server" to send new objects to people across the grid using the llGiveInventory() function (which does NOT require the recipient be in the same sim). It also often employs an external web server, since keeping contact with a known entity (the server) in-world is not completely reliable (as you've noticed, objects don't retain keys between rezzes; they must be kept stable on a parcel indefinitely to retain their keys, and then there is always the fear of object return for various reasons).

So the typical scenario is that the object you give to someone checks in with a web server via llHTTPRequest() every now and then (say when it is rezzed or attached), and the web server decides whether it is the newest version of the object or not. If not, it queues a delivery of a new version and at some point the in-world server fetches the info from the web server using another llHTTPRequest() call and sends a new version of the object using llGiveInventory().

For no-transfer products, often a whole new version of the object is given. Sometimes instead people send a simple little update package which will replace scripts in the existing object, but this can get tricky and often has questionable pay-off, at least IMO.

See /54/27/304671/1.html

not related directly related to the OP's post, but definitely related to Heewee's first post

a method for reducing individual maintenance in cases where you want to avoid time-delays (as in the referenced post, or are doing the same actions for multiple targets, which may be individual, or simultaneous, is to (as heewee stated) name multiple copies differently, and read those names in as variables... using those variables to target different sources.

alternately, placing those individual scripts into their target child prims, they can then be targeted en masse or individually by link number. (you can achieve the individualization by including a link message variable that must match the script variable to trigger)

by abusing the automatic numbering of script names that occurs when you drag a copy into the same prim, you can do without having to manually rename them all. simply grab the last to characters of the script name, and convert it to and integer (make sure you delete or rename to 0 the first script) which will all you up to 100 differently targeted (by their script number) scripts all with the exact same code, and very little effort.