Single versus multiple scripts

[LissomePrey]

Has anyone written a blog or similar on the criteria to decide when you should use a single script and when you should split into multiple scripts?

If there is a good one would it be worth pinning it in this forum?

[Rolig Loon]

Not that I am aware of.  There really aren't many "rules", though. The decision to combine or split scripts really depends on personal style as much as it does on practical limits like script memory.  It's much like asking the question about whether to write a script with multiple states or to put everything in one state, or maybe asking whether it's better to use strided lists or multiple lists with parallel indices. There's no "best" way that applies to all situations or that all scripters will feel comfortable with.

For what it's worth, I tend to avoid splitting a script into several smaller ones simply because it's easier for me to keep track of current values if they are all in one place.  If I have a real monster job that is going to push memory limits, I will use one master script to handle UI matters and a second one to do the actual work or to manage access lists or whatever.  In general, I'd rather update one script as needs evolve than update a suite of two, three, or more scripts, but I'll do whatever seems best for a particular job.

Edited March 10, 2021 by Rolig Loon
typos. as always.

[LissomePrey]

Thanks Rolig. I tend towards a single script but just wondered if I was affecting performance, lag or anything else.

[Quistess Alpha]

I believe the general consensus is you should use a single script when possible for best performance and lowest lag (to the server).

If performance isn't an issue there are a couple of different specific reasons to use separate scripts.

1. Separating functionality for easier development.

If I wanted to script a bunch of different doors for example, I might want to have things separated into three scripts, one for presenting a nice dialog to the user for changing configuraton options (locked/unlocked, who has a key, should it open on touch or try to sense someone coming etc etc.) another for determining when the door should open (could be rolled into the first script) and a third for actually opening the door. this would make it a bit easier manage scripting several kinds of swapable opening mechanisms (rotating double doors, single doors, sliding doors, turnstile doors. . .) while leaving the configuration options alone.

2. Data storage.

If you have a script holding some mission-critical data, and aren't using some sort of external storage, it might be a good idea to have a separate script store the data, so you can make changes and fixes to the 'main' script without affecting the stored data, since you only get 64kb of memory per script (for mono scripts), this is also a decent way of expanding your memory allotment if you need to store some large (but not over 64k) lists.

3. Parallelism.

All Scripts in SL are single-threaded. If you know what you're doing there are some /very specific/ instances where you might be able to take advantage of multiple scripts to do many things at once.

4. Code reuse.

This is a bit limited, but you could also use a separate script for doing things you might want to do on a regular basis in different scripts, and use it as a sort of library. "give a nice dialog to someone and let them select another person in the same region" is one that I have a separate script for.

Edited March 10, 2021 by Quistessa

[Rolig Loon]

1 minute ago, LissomePrey said:

I tend towards a single script but just wondered if I was affecting performance, lag or anything else.

For me, the biggest concern is my own performance.  The more things I need to pass from one script to another (or one state to another), the more likely I am to forget one of them or to overwrite it accidentally, or to create some sort of race condition.  I know my own failings well enough that I am afraid of creating a chaotic cloud of instructions that are working at cross-purposes.  Especially if a script has to keep updating important lists, I prefer keeping them all in one place where I can see them and know what they are doing.

[Qie Niangao]

1 hour ago, Quistessa said:

3. Parallelism.

All Scripts in SL are single-threaded. If you know what you're doing there are some /very specific/ instances where you might be able to take advantage of multiple scripts to do many things at once.

A special kind of "parallelism" is avoidance of artificial delays built-in to functions. This used to be necessary for simple prim manipulation, until llSetLinkPrimitiveParamsFast() got rid of the 0.2 second delay. Earlier today I was reminded of this while looking at the scripts in the Moles' SLRR "Switch Stand" which use multiple llRemoteLoadScriptPin() calls, each of which suffer from a 3.0 second delay, so it's crucial they run in separate scripts.

In general, though, I try to keep to the fewest scripts possible. If there may be many copies of a scripted object present on a sim simultaneously, it really can matter if there are one or two scripts in each copy, given the way the script scheduler works now, with measurable overhead time for each running script even without active events. Also, for simple multi-link objects, script count can affect Land Impact.

[Innula Zenovka]

I always try to limit myself to one script if I can and, unless I have to for one of the specific reasons mentioned above to do with multi-threading,  I split them only if I run out of script memory or if the logic becomes too hopelessly complicated otherwise (though that's normally a sign the script needs rewriting rather than simply splitting, even though I might not immediately see how to organise things more elegantly and economically).

[Kyrah Abattoir]

7 hours ago, Quistessa said:

1. Separating functionality for easier development.

Due to the lack of optimization done by the LSL compiler, this should never be considered a priority. We do have script pre-processors to assist with code clarity.

[animats]

1 hour ago, Kyrah Abattoir said:

Due to the lack of optimization done by the LSL compiler, this should never be considered a priority. We do have script pre-processors to assist with code clarity.

Yes. I use Firestorm includes extensively. My in-prim scripts just read "#include FILENAME". All the content is in files stored on Github.

A nice feature of Firestorm includes is that un-called functions will not be included. So you can have a file of library functions that are included into many scripts. Anything not needed is not pulled in.

I've had to divide things into multiple scripts to stay within the 64K limitation. My NPCs have 12 scripts sending messages back and forth in JSON. It's not fun.

To me, the biggest annoyance about script memory limits is that the stack is included in the 64K limit. You don't have full control over how much stack space you use, because you have to use stack space for incoming messages before you know how big they are. That can cause unexpected stack/heap collisions. You can tell how much heap you're using and take appropriate action if you're getting low, but the stack problem means you have to allow a big safety margin.

[bobsknief Orsini]

Don't forget functions that have a delays or timers. If you have a script that is constantly working and needs to send for example im messages. Adding a additional script to send out the im message prevents the main script from sleeping for 2 seconds.

In regards to timers it mainly depends what it does. Its generally better to have one script that constantly runs some "small code" then putting everything into one script running a "large code" constantly.

[Profaitchikenz Haiku]

I will often develop a large project into several smaller scripts, where different functionality can be assigned to a single script, which makes testing a lot easier. If a small script has nothing but a link_message event it's not going to add massively to the region load.

Small scripts with little data can be LS rather than Mono, (old argument here about how much difference in memory it actually makes, I know), and this reflects in the scripts information you get in the about land pane saying how much memory is being used by the scripts.

Once I'm happy with a small script it might get merged back into the main one, it's a judgement call here.

There's also a case for splitting out data storage into other scripts, again using link_messages, and should one of the scripts run out of memory and stop responding, the others may still be able to carry on, and phone-home to tell me that such and such a script hasn't completed a handshake.