CPU load

[Killswitch]

Up to 650 loons active when the mission is running? You, Sir, need bn880's excellent "AI on demand" system.  ;D

This lets you put groups that are currently not involved (ie near the player) in "stasis". That way, they are removed from the game world until they're needed again. They are brought back based on conditions chosen by you. It can be as simple as a boolean variable determining  their reentry or a more complicated conditional expression.

A common example of the latter is having AI groups be brought back to life as the player gets closer than a set threshold distance from one of their waypoints.

bn880's "poster child" mission for this system is the multiplayer "Bastige Island", presented here: The Bastige Island 6.

The latest (of this writing) source AIOD scripts are available here: CoC AIOD rev. 36

NB: Once brought back, the AIOD-governed groups are there for the duration of the mission. The system can't bring them back into stasis again after "re-animation".


On event handlers
The event handler system is great for many things, but also something that too often is so misused it makes me cry. Examples of the horrors people do:

* Use the fired event to exec a heavy .sqs script. <-- this should really trigger FADE on the originator's computers...bloody 'eck...  
* Use the killed event to spawn off a "body cleanup script", one per loon killed leading to oodles of .sqs:es running. :-X

(Keywords for solving #2 there: array, queue, 1 singleton monitor script...well duh...)

[THobson]

Killswitch:

Thank you.  The problem with puttung the ai to sleep is that things are meant to be happenign all over the island, including soldiers setting off to find the player - that could not happen is they were asleep.  No I need them all corpus mentis.

[Mikero]

Putting my C++ hat on, I certainly agree with HateR, more to the point, he's 100% on the money

Event handlers are interrupts. They don't in themselves contribute to lag except the small amount of crunch time they use, when used. You wont do a thing to reduce lag by removing them because the internal workings that check if an event handler is 'registered' is still going to check if an event handler is 'registered', there, or not.

What you can do tho is make 100% sure that the very first thing you do at top of script is to get the hell out of there. Even at the expense of some very convoluted code.

The reason is the engine interprets all syntax on the fly, it doesn't have a 'compiled' version internally, it interprets scripts each time, every time (with some minor adjustments to an internal syntax and stucture, but, 'MyBestLoon' remains as 'MyBestLoon', not,  binary[45723]-> to something.

Obviously preventing an event script from happening by removing it altogether, is going to reduce lag, but you'll do nothing to remove the need to check for one. If as you say, everything more or less funnels into one of three events, then making sure that script exits real fast, is the best option, combined with Barron's statement that don't put anything in that exit condition that relies on complex (engine) math.

I would do this

if permanent simple flag get the hell out of here

do lots of stuff

if lots of conditions, set permanent flag.

Ie reduce all the complex test stuff to a simple top of script, flag and exit.

Edit:

@KillSwitch

Precisely. If authors understood the nature of an interrupt, that it's operating in 'real time', they'd hopefully be more circumspect in what they wanted to do, real time. At least their expectations would be a bit less dramatic and they'd then only have themselves to blame, as in DUH!

[bluehand]

Thinking about Killswitch's suggestion.  Instead of creating a group on the other side of the island and giving them a Move order to some place, why not just remember where they're supposed to be, and only create them if the player gets close to them?

You could have an array of locations for these units (current + destination) and speeds.  Once every 10 seconds a looping script could simply make the current-location closer to the destination.  Also in the loop, check distance to player, and if <500m create the unit and put it in the other array that you probably use already.

When the "current location" reaches the destination, fire your other script to pick a new destination as currently.

Ok, so it's not precise. It won't create traffic jams as batallions of trucks bump into each other.  It probably won't slow things down as loons get in and out of transport or move up hills & through forests.  Groups would fly across the sea rather than going round the bay, and so on.  But it would surely load the CPU less than using actual groups, precisely because it would ignore all that stuff.

[THobson]

Bluehand:
Nice idea, but not for my mission I am afraid.  To work it would require that I knew where each group was supposed to be and when it was supposed to be there.  Possible (maybe) for a mission that lasts 20 minues, but not one that can easily last 20 hours.

[Wadmann]

I am not familiar with your mission (shame on me for not playing it already), but I assume that you are using one or more scripts. If this is the case then this may help some although others have debated the merits of this theory.

This was directed to a different simulator that begins with a "V", ends with an "S" and has a "B" in the middle so it may not be totally correct in regards to OFP. The premise is to amend scripts so there are fewer lines of code but they are longer. An example:

Example 1.
#start
_i = 1
_i = _i + 1
_i = _i * 22
_i = _i + 1
goto "start"

Example 2.
#start
_i = 1;_i = _i + 1;_i = _i * 22;_i = _i + 1;goto "start"

Example #2 would be more effecient than #1. Again, there are some that disagree with this theory. As another OFPEC poster stated on the "other" forum that "the engine allocates time to the scripting system on a per-line basis".

The only reason that I think that the theory has merit is that the "other" sim just had a series of patches and one of them re-formatted the mission.sqm to a format similiar to example #2 as opposed to the "classic" OFP style of the sqm. More to the point it eliminates most of the blank spaces found in the OFP sqm by displaying the code from the border while listing addons in a format like example #2.

Just some food for thought but I would be interested to hear what others have to say about this concept.

Wadmann

[Mikero]

>allocates time to the scripting system on a per-line basis

As far as I'm concerned the engine would allocate time on a per command basis. semicoloned or otherwise. Not on lines, or any other device.

The only 'evidence' for this theory is that a scripter thought this new layout looked more 'professional'. Debatable in itself. I've never seen a benchmark proving or disproving it.  Am happy to declare it an old wives tale till proved wrong. Not that you are wrong to mention it, all comment is good comment, to nail this mother of a problem.

[Mikero]

@THobson

putting 1 and 1 together to make 11 I've been told, and/or discovered the following:

The engine does *not* retain a compiled version of a script. It process it on the fly.

The engine (afaik) does not use THE script again after first encounter, but rather an internal copy of it (which ends up in the fps file). For this reason, you can't edit sqs files middle of the mission, and expect them to work the new way.

Some mission.sqm's (among other things) are so-called 'encrypted'. Which isn't encryption at all, just an internal, tableised view of the script. It is this 'encryption' I believe is the internal structure of any sqs file eg. I already wrote a decrypter, thanks mostly to hard work done by Bas, but if I reversed it to 'encrypt' various script files, it might make a peformance boost.

This would come about only if there were an intermediary stage that the engine goes through in converting scripts to table entries each time, every time, before using them.

I'll contact you via pm for this, as it may be long and painfull, but am mentioning it here in the hope some kind soul can slap me down quickly before I run up a long dark tunnel.

[General Barron]

The engine (afaik) does not use THE script again after first encounter, but rather an internal copy of it (which ends up in the fps file). For this reason, you can't edit sqs files middle of the mission, and expect them to work the new way.

**buzz** Wrong. I don't know if this changes after you package the mission into a .pbo, but if you are working in the editor, you can start a mission, run a script, edit the script outside of OFP, and then run the script again, and you will get the changed script.

This only works if the script exits and then is started again. I believe OFP loads the entire script into memory, then reads it line by line, and then gets rid of it once the script exits (this checked by editing a script while it is still running and seeing if it changes in OFP).

For this reason, one way to reduce memory load by a little bit is to use the smallest variable names possible. So instead of something like _man, use something like _a. Of course, this makes it difficult to keep track of what is what when writing the script. To fix that,  MachoMan had made a tool for the ECP that will take a script and convert all local variables into _a, _b, _c, etc. You might wanna PM him to see if you can use it.

if I reversed it to 'encrypt' various script files, it might make a peformance boost.

I would be VERY interested in such a tool if it indeed worked.

[h-]

Indeed...
If that 'encryption' really does give a performance boost, I would also be very intersted in it...

EDIT:
About the semicolon stuff...
I really doubt that putting the code on one line separated with semicolons would be any more efficient than putting all in separate lines ending with a semicolon...
The same thing more or less... me thinks.

[THobson]

So variable names like:
_MGPatrolVehicles
HoudanWoman_Clone
_knownInfantryGroups

Are probably not a good idea?

Bugger!

I have the same experience of being able to edit a script within a mission being run from the editor and so long as the script had exited the revised script will be used.

I have assumed that when a script (in a pbo version of the mission) exits then OFP unloads it so, for example, all the local variables would then cease to take up space (and name slots).

In my mission I have tried to minimise the number of sripts permanently running it the background.  There is one for the weather; one for the fog; four instances of a script that detects if the lead vehicle of group has got screwed up and fixes is; two instances of a script that moves a couple of triggers with each convoy and controls the disembarkation and embbarkation of the infantry on board; about 44 instances (one for each armoured unit) of script that generates the burn effect when they die; and one script that does the housekeeping - running all the other scripts at set intervals.  I also had 33 instances of a script that dected when  a flag carrier died and passed the flag to the new group leader - but I have removed that functionality.  Even with these 33 instances running that is hardly exorbitant.

I will now have a look at the numbers of variables and the variable names I use in the scripts, especially those that run continuously.

[Mikero]

>Buzz wrong

One of those rare instances in human nature where I'm thrilled, to be wrong.

>on exit

that's the key I missed.

>string names.

Complete furphy. This is ram overhead only, and insignificant at that. Definately the wrong dark tunnel chasing labels to improve performance. Arrays yes, mutliple and profuse variables, yes, but not whether one has 1 or sixteen characters attached. The storage alone to hash and index them would take more space. Drop it.

>Semicolons

no engine in the world can handle immeasurable lengths of string. the command, and command alone is the definition of what's processed, not the line, not the white space, nor //comments nor embbedded brace{} (except each brace alone is considered a 'command' for the brief time it's processed)

It would be a far stretch to assume any amount of whitespace (newlines, comments, tabs) contribute anything significant to parsing the text. Even visual basic can rattle through this stuff at a rate of knots.

Will start working on an encrypter. Hope people realise it's the wrong choice of words, it's just a hash tableiser.

[General Barron]

>string names.

Complete furphy.

Heh, I guess I'm guilty of just passing along rumors I heard elsewhere .


Anyway Thobson, if you want to know the source of 99% of the lag in your mission, it is going to be the units you have. I seriously doubt that you are going to be able to get much of a performance boost by changing around anything else.

I made a mission with about 150 units and very few scripts/triggers, and it lagged me worse than other missions using much less units but much more scripting. It's just a case of the simulated objects taking way more CPU power than any script or trigger, and you having a ton of those objects. Makes sense when you think about how much stuff the AI must have running thru it's head at any given moment. Then multiply that by x groups, and you get the picture....

Have you tried the disableAI command on all the units yet? I'd be curious just to see if it has any effect, even if you didn't end up using it.

-----------

One thing I would suggest though is using either the benchmark command or an options dialog that would change the effects settings based on the player's computer.

A fire script on armored vehicles might be nice, but not if your computer is already lagging. And having a script that monitors the damage of a vehicle to play a fire effect at 80% damage isn't as good as just using a killed EH if your computer could still use some help. If his computer runs the mission fine, then it isn't a problem to add in the full effect (Although an even better way to do it might be to use a "hit" eventhandler that checks to total damage value after each hit. If the damage is too low, it exits. If it is high enough, then it plays the fire effect and removes the EH).

You could then add back in your flag effect for computers that can run the mission smoothly. And then you could tailor any future effects you wanted to add in a similar fashion.

[THobson]

Anyway Thobson, if you want to know the source of 99% of the lag in your mission, it is going to be the units you have. I seriously doubt that you are going to be able to get much of a performance boost by changing around anything else.

I think you are right and referring to an earlier post of yours I think specifically it is live armour units.  The OFP seems smart enough cut down on its own work on these if they are some distance from the player so lag happens when there are a lot of them in a smallish space.  Your comment about them becoming static objects and so less laggy when they are dead is supported by my recent experience, a very laggy location when left for a while became quite okay.

I could try a Hit EH on the vehicles.  I was reluctant to do this because with men a hit EH doesn't capture all damaging events, explosions for instance.  The problem with using a killed EH on a vehicle is that vehicles can to all intents and purposes be dead, but not actually dead.  Anyway I ran a test on Malden using 5,000 armoured units all with the script running and as long as I couldn't see any of them the lag was not detectable.  Again leading me to the same conclusion that you have - it is units not scripts that is doing it.  So I may even put the flag swapping back - but see the third paragraph down from here about a threshold.

I have found the benchmark command not to be a reliable indicator of a machine's performance.  From the comments of some of the beta testers machine that are lower spec than mine perform less well, but can have a much higher benchmark.  So I really don't know what is going on there.  A dialogue is a good idea.  I avoided that because from the start of the intro I wanted the player to be completely immersed.  I could try and put the dialogue at the start of the intro though, or as a Plan B I could create a separate pbo file for lower spec machines.

Disabling the AI would be an interesting experiment.  Forgive me if I don't do that soon.   I first need to create a reliable way of generating lag in somewhat less than the 1 to 2 hour of mission time that it currently takes.  I do have ideas about how to do that though.

I may be completely wrong in this but the feeling I have about OFP is that there is some threshold of ‘load' beyond which performance deteriorates rapidly.  Rather like a windows machine where the swap file goes beyond what can be held in RAM and starts paging to the hard drive.  I am not suggestion there is hard drive paging in OFP, just that it feels like there is a similar threshold.  Something happened around v1.2 of my mission that reduced performance significantly at certain times.  Or it seemed to, it might be that threshold is psychological and is in my head, what was just acceptable was fine, what was just not acceptable was horrible.  Anyway around v1.2 I added about 20 triggers, 15 of these are deleted early on, certainly long before I hit the main lag, the reminder are for environmental stuff like bird noises etc. that could go and no one would notice the lack.  I also added a few small groups of infantry one large group of resistance and one large group of civis.  All of that was for environmental feel.  I did nothing to the armour or the chopper count.
Any thank you for all your help.

[Terox]

havent read all of this, so my excuses if this has already been mentioned.

Reducing lag when having max no of units on the map

1) Use COC's AI on demand system
This places all the stipulated units in stasis until required.
There re initialisation can be brought about by comparing the distance of their position to the nearest enemy unit or by a boolean
(Group waypoints are also seen as a possible position of these "In Stasis" units)
I've use it, its very good although sometimes you do see a slight stutter as these units are re introduced)

2) Place units in cargo in a vehicle and then when ready setpos the vehicle, unnasign them units from the vehicle and delete the vehicle. Very low cpu intense method

hope that helps

as was said before reduce triggers to a bare minimum, and if you need a lot of west knows about east or activated by west type triggers then simply use the one trigger and setpos it to each location every second or so

3) Place all your commonly used global variables in ram memory by stating them in a .sqf which you run once at the start of the mission.

Place any commonly used script or segments of (That dont have "wait until" or "goto" statements in them) into functions and then call these functions from scripts

an example

The following system is made up of a looping script that calls a number of functions every so many seconds
(forget the content, its basically monitoring conditions that a bunch of triggers used to do)

My method in my scripting is to have where possible ONLY 1 looping script. Which i call my monitor script
It looks for certain condition and then when true runs a linear script (Non looping) which runs it commands and then exits

In the example below i check a lot of endgame conditions,
Check the blue line out, this runs the checkA function

The beauty of this is, the function, which is basically a linear script is already in memory, it doesnt require the hard drive to be accessed or data written across to ram, its much more instant and therefore a lot less cpu intensive

the looping script

?!(local server):exit
~ 3 + random 1

#INIT
_a = 0
  #START
    ~1
    if(tx_StopSqs)then{goto "END"}
    _a = _a + 1
    if((_a == 3)&&(({alive _x}count tx_destroy)==0))then {call loadfile "tx_sys\server\CheckB.sqf"}
   if(_a == 4)then {call loadfile "tx_sys\server\CheckA.sqf"}  
   if ((_a == 5) && (count tx_damcon >0))then{{_x setdammage 0} foreach tx_damcon}    
    if(_a >=5)then{_a = 0}
    goto "START"      
       
#END
;; does some boring end of mission stuff then exits
exit

checkA.sqf

if((((tx_EatStart - tx_Enow)/tx_EatStart)* 100)>=tx_Ecaslimit)then{tx_Ecashigh=true;tx_StopSqs=true;tx_Efail=true; {Publicvariable _x}foreach["tx_StopSqs","tx_Ecashigh","tx_Efail"]}
  else
    {if((((tx_WatStart - tx_Wnow)/tx_WatStart)* 100)>=tx_Wcaslimit)then{tx_Wcashigh=true;tx_StopSqs=true;tx_Wfail=true; {Publicvariable _x}foreach["tx_StopSqs","tx_Wcashigh","tx_Wfail"]}
      else
        {if((((tx_RatStart - tx_Rnow)/tx_RatStart)* 100)>=tx_Rcaslimit)then{tx_Rcashigh=true;tx_StopSqs=true;tx_Rfail=true; {Publicvariable _x}foreach["tx_StopSqs","tx_Rcashigh","tx_Rfail"]}
     else
            {if(time >= tx_timelimit)then{tx_StopSqs=true;tx_timeout=true; {Publicvariable _x}foreach["tx_StopSqs","tx_timeout"]}
       };
        };
    };

The above stuff is used in a template for A&D missions, when the template is bug free all the long variable names will be changed to a much smaller string length

as am sure many have pointed out before in this thread

few more tips


try never to use @

better to use


#start
~0.5
?(condition):goto "SKIP"
goto "START"

#SKIP

the refresh rate for the @ command is that of a trigger

also think about reducing setviewdistance

or smoothing of the terraingrid

for some reason boats use a lot of cpu, probably because the system has to keep recalculating their height as the waves come in.

Infantry patrolling through woodland is also cpu hungry

long distances between waypoints is another

use of lots of drop commands is another, eg campfires, flares, anything that burns or gives of light basically