Delegation vs Script Lag

heyas;

im working on a project that has lots of options that can be turned on and off. in order to reduce lag to the lowest possible levels, i figured the main brain could just turn the 'extras' scripts off when not in use.

but then i was wondering, when all those little ancillary scripts are running... would that be MORE lag than just having one big, ponderous script handling most everything and checking flags for what is on and off?

any opinions? or, has anyone done anything like this and knows the results?

It would really depend on what the scripts are doing. If each script would end up with it's own timer doing something regularly, then it's probably best to wrap all of that into one script. If each script handles a particular function that only gets called a specific times and remains idle the rest of the time, then an ancillary script would be ideal, assuming you needed the extra memory. But for the most part, it comes down to 1+3 = 2+2 = 2+1+1 = 4. No matter how you split up the load, it's going to be the same amount of load.

Checking a flag is negligible, so the only real reason to split things up would be if you needed the memory, or if you wanted it to be truly modular, with certain modules being optional and removable by removing their related script.

For my wristwatch - ha ha, yes that again - it has proved necessary to delegate for aesthetic reasons as well. It has a multitude of hands and it just looked silly when, on the minute, they moved sequentially. By giving each hand the reponsinilty for it's own floating point arithmetic and movement they all snap together at the correct time. And having given each hand it's own script for that it also became logical for them to perform their own cosmetic functions.

The main script has had to be split into four for memory reasons as well as for performance. One acts as the main timer loop, sending messages to the hands every second (or minute or hour or day or month or year) without hindrance. One script generates the menu dialogs, but the responses - because there are so many - have to be handled by two different scripts. One deals with time functions and the other with the appearance. Another script is used to flash the alarm signal using its own timer loop. And a fifth script, which is modifyable, can be used to allow the user to customise an AO overrider, turning their AO on and off when the "glance at watch" animation is triggered.

I mention this to give every one the opportunity to criticise my methods and to suggest better ways of doing things

________________________

Yes, good point, there are physical layout reasons for multiple scripts, I neglected to mention that.

Your structure seems sound to me.

hmmm...

my project is rideable animals.

so the animation script runs on a short fuse timer. but then something like the random sounds shouldn't be going off 4x every second :X so a longer, random timer is ideal for that. and since the main timer is so fast and it has to deal with so many things.... well, i dunno, in the grand scheme of things.


so i'm looking at something like this:

timer: 0.25 seconds
check standing still, or walking, or running, or jumping, or flying, or landing
if doing animations
do standing, or walking, or running, or jumping, or flying animtions
if doing sounds
do walking or running sounds
if doing random stuff
oh, and check if we should do a random thing this pass or not.


or leave off the last bit and just have a separate script that does:
timer: random several minute interval
do a random thing
... unless not doing random things, then just turn off.



oh well, i will get my script timeslice whatchacallit tester to look at some variants tonight.

thanks guys!

maybe i will just consider doing it the way that is easiest for me. ;D