Coding concept: Multi-Script vs Multi-state

I've been working on a secure access item that has 3 paths of security: access from group, access from those listed on a note-card, and temporary access stored in the script's memory. Each type of access gets different options, and can be toggeled on or off. Right now I have it set up so that the object has 5 scripts: one script for each of the access types, a controller script that coordinates the results of the 3 access types, and the script that does the desired action.

I have figured out a way to do this all within two scripts using state changes (one for the access permissions the other for the desired action), but am wondering if there is any real advantage to consolidating the scripts together like that. The way I see it, using my multiple scripts may be less sim resource efficient than putting it in a single script, but I also don't risk as much of a chance with stack-heap overflow errors.

For my application the code doesn't have to be super fast in execution, it just needs to return it's output in a reasonable fashion, which is working just fine with my multi-script implementation. Would consolidating the scripts speed up or possibly slow down this process? Granted the execution speed would be greatly effected on how I went about implementing the consolidated code.

As to why I'm thinking about consolidating scripts that are already working fine, there was a scripter's group discussion (well, flame war) about multiple scripts vs multiple states and it made me wonder which would be better for my current application.

One thing you may run into with combining things into a single multi-state script is the 16k stack heap collision.

There is a post in this forum somewhere that talks about optimizing code. An important consideration would be maintaining the script and understanding it later. The multiple script may be better in the long run and maintaining if LL changes something.

One of the big lag causes is lots of scripts in a sim even if they aren't doing anything, so in general the fewer scripts the better. However, you can also turn your scripts on and off in a prim, that is you can have a bunch of scripts, but make them inactive unless you need them to run. When inactive, they don't seem to cause lag.

So bottom line... If you can shut them off and it's easier to code and/or you're running out of memory, multiple scripts in a prim may be better. If you need to keep them running though, you're more sim friendly with fewer scripts.

This has been discussed here, and i see it everyday in the estate debug tool : idle scripts (scripts with no event in queue to process) takes CPU. So the fewer the better, especially if we consider that a large number of scripts spend 99% of their time idle.

Multiple scripts generally result in cleaner, more modular (= readable = maintenable) programming. That depends, however, on how loosely ot tightly scripts are coupled. If you have to return values from inter-script calls (pseudo external procedures), it may turn quickly to a mess of PROCx_CALL and PROCx_RETURN all falling in a single link_message handler with an ugly dispatcher, loosing all the benefit of modularity.

Mixing both (multiple coupled stateful scripts) may be fatal. The event queue is flushed when changing state, so link messages may be lost depending on the actual scheduler's algorithm (we are supposed to ignore).

Another advantage of multiples scripts is persistent storage of data while upgrading other scripts in the same application.

Like said by Jacques 16k limit is always a problem, but if by all means if you can have a script take the place of a few please do. less scripts is always better for our lovely sims. If you follow a good formatting and descriptive variables, functions, and states a large script can be very easy to follow and debug.

16k does not seem like much but is amazing how much you can do with it.