Home   Help Search Login Register  

Author Topic: one big or many small...  (Read 776 times)

0 Members and 1 Guest are viewing this topic.

Offline bedges

  • Administrator
  • *****
    • OFPEC The Editing Center
one big or many small...
« on: 26 Mar 2005, 21:52:30 »
i'm currently working on a few scripts which will be running constantly in the background every minute or so. i have the choice between running one long script running every 60 seconds, or lots of wee scripts running separately at about the same rate.

the question is, will the single script running all at once cause more lag than several separate scripts running more or less in sequence?

Offline dmakatra

  • Members
  • *
  • Better known as Armsty
Re:one big or many small...
« Reply #1 on: 26 Mar 2005, 22:00:42 »
If I'm not misstaking the advantages of one script is that it loads into the memory and then it stays there for as long as you want, whilst several scripts loads in, forgets, loads in, forgets, loads in, forgets.

But on the other hand, the smaller scripts will use less memory space as long as it stays there...

I'd personally go for 1 long script because then you'd lose all the inits all the time, and thus saving a tee-bit of memory. But of course, it depends a lot of how your script is designed. I think, I don't really know this stuff. :P

Conclussion: If it's just a handful of scripts just fuck it, doesn't draw that much CPU/memory. Rather remove one or two soldiers or whatever. ;)

:beat: *Gets Shot* :beat:
« Last Edit: 26 Mar 2005, 22:00:54 by dmakatra »

Offline Sui

  • Former Staff
  • ****
    • OFPEC
Re:one big or many small...
« Reply #2 on: 27 Mar 2005, 01:41:50 »
If you're going to have a looping script continuously running, I suggest having only one :)

Try to incorporate everything into it, as you can do a lot with a looping script.

I tend to have one in every mission I make. You can substitue a hell of a lot of triggers with one script. Un-depbo Facile Ground and have a look at trigs.sqs to see what I mean.

Offline General Barron

  • Former Staff
  • ****
  • Semper Fi!
Re:one big or many small...
« Reply #3 on: 27 Mar 2005, 03:01:42 »
A script would, of course, take some CPU power to start up. However, if you are only executing a script every few seconds or so, then I think it would be entirely negligable. If you have a script executing every 0.01 seconds or so, then you may be better off having that script just stay running...

But I'm with Sui; better to have one single, large loop than many smaller ones. For one thing, it makes things simpler to keep track of on your end (and update, debug, etc). For another thing, if you have lots of local variables in lots of different scripts, then you can run into the savegame bug. I believe Thobson or someone ran into the savegame problem, and was able to fix it by combining all his little loops into one big loop (that and combine his global vars into a few global arrays).

Of course, it takes quite a bit of variables to run into that bug, but since you seem to be nitpicking about performance, I assume you are having lots of scripts. :)

HANDSIGNALS COMMAND SYSTEM-- A realistic squad-control modification for OFP
kexp.org-- The best radio station in the world, right here at home! Listen to John Richards!

Offline THobson

  • OFPEC Patron
  • Former Staff
  • ****
Re:one big or many small...
« Reply #4 on: 27 Mar 2005, 09:05:48 »
I was going to mention the large savegame bug, but felt it might be pretty rare in the absence of ECP so I wondered if there may be other considerations.

I started by having a lot of scripts sitting in the background - and I do means sitting (and I do mean a lot), each had a loop with a delay of up to many minutes.  So they were all sitting their waiting then every few minutes they would do their stuff for a millisecond or so and then go back to waiting.  The result was that when I did a savegame all those irrelevant local variables needed to have their values saved and I hit the large savegame bug.

My solution was to remove the loop from each of the scripts where that was possible, so that each script would do its stuff once then exit.  I then set up a single script that called each of the individual scripts at an appropriate interval.  That way at most only one of these individual scripts would be running when a game is saved.

This master script looks like:

Code: [Select]
_i = 0
#loop

;Start of the approximately 5 minute loop
_i = _i + 1
run a script
~61
run a script
~61
run a script
~61
run a script
~61
run a script
~61
run a script
~2.3

if ((_i % 3) > 0) then {goto"loop"}
;Get here every approx. 15 minutes
~2.3
run a script
~2.3
run a script
~2.3
run a script
~2.3
run a script


if ((_i % 9) > 0) then {goto"loop"}
;Get here every approx. 45 minutes
~2.3
run a script
~2.3
run a script
~2.3
run a script
~2.3
run a script


if ((_i % 18) > 0) then {goto"loop"}
;Get here every approx. 90 minutes
;Reset _i so it does not get too large no matter how long the script runs
_i = 0
run a script

goto"loop"

(I use prime numbers in my delays to minimise any patterns of scripts running sumultaneously with other scripts that would not work in this way.)

So I have kept all my individual scripts, but I don't have them running all the time.  I very much prefer it this way.  It comes from learning to programme in Pascal and its derivative Modula 2.  I like everything modular.  Each script is a piece of standalone code that is aimed at doing one or two specific tasks.  If I had put all the code for all the scripts into the single large loop I would have had concerns about unintended interactions between them, and anyway it would have been less help with the large savegame bug as I would have still had a lot of local variables active all the time.  As it is only the local variables for one script are active at anyone time, and then only for a millisecond or so every approx. 1 minute.  

So, my view is - the approach above minimises the likelihood of hitting the large savegame bug - which is pretty low most of the time anyway - but also I find it easier to keep track of stuff and de-bug etc by keeping everything modular.  You pay your money and make your choice, whatever is good for you.

I agree with Sui.  Using scripts can make an enormous difference to the numbers of triggers you need.
« Last Edit: 27 Mar 2005, 09:14:44 by THobson »

Offline bedges

  • Administrator
  • *****
    • OFPEC The Editing Center
Re:one big or many small...
« Reply #5 on: 27 Mar 2005, 12:38:00 »
understood. many thanks for the tips.

Sui - i took your advice and had a wee look at the script you mentioned, and that's pretty much the way i'd intended going. however, the modular approach favoured by THobson is the way things are set up at present, as that's the way i've been trained to do things too ;)

i think perhaps a mixture of the two will work just fine. there aren't really that many scripts or variables to be of concern, as the general pointed out. i was just curious as to which approach would be the more efficient, but it doesn't seem to be that much of an issue until things get very big or complex, neither of which appears to be the case (so far...)

it's a communications script, for those interested - inspired by the 'whole island' concept seen in THobson's 'Abandoned Armies', i'm using radio towers as a significant part of the mission, dictating just how much and how quickly information is shared between garrisons. it's tricksy, but coming along like a fluffy omlette.

cheers once again.