CPU load

[THobson]

I have made several changes to my mission based on the asumption that once I have used a trigger a

deleteVehicle triggername

will completely remove the trigger and there will be no residual load on the processor.  Does anyone know if this is the case ot not?

Similar queston on objects.  If an object is in the editor with condition of presense set to false, I assume it does not exist as far as the game is concerned and so does not contribute to lag.

[Fragorl]

I would say both things are a safe bet, but I have no way of being 100% certain.

[General Barron]

I have no idea about the first question. An easy way to test it yourself would be to make a trigger, activation "anybody present", on activation "hint {trigger is here!}". Set it somewhere that you have to walk to get to.

Then, in your init.sqs or elsewhere, delete the trigger (after a few seconds delay). Run the mission, wait for the trigger to (supposedly) be deleted, and then walk into its area of effect. If you get a hint, then you know the trigger can't really be deleted.


I would bet my firstborn's soul that you are correct on the second question. I don't see how the game could keep track of an object if it never created it...  unless it creates the object, and then hides it?  

[THobson]

General Barron;

Sorry if I was not clear.  I do know that a deleted trigger will cease to work.  I have done this a lot in my mission, when a trigger is no longer needed I delete it in an attempt to cut down on CPU load.   I checked this works by making them repeating triggers and in deed after deletion they do not fire.  

I am suffering some lag and am looking for a cause.  It is a long shot but  I was wondering if a trigger that is deleted still contributes to cpu load.  I have strong suspicions that a fire once trigger does continue to require the cpu after it has fired (my data for this is the fact that thislist for the trigger will continue to be updated after a fire once trigger has fired).

[h-]

Maybe this has something to do with the thislist array getting updated:

Array assignment

Assignment used on arrays assigns only pointer to the same array to the target variable. When b is an array, after executing a = b both a and b represent the same array. When b is changed, a is changed as well. One particular situation that can lead to this behaviour is aList = list sensor_name. You can force creating a copy of array by using unary operator +Array

Try using something like testArray=+thisList and see whether the thislist array gets updated after the trigger is fired/gone...

Well, this actually probably has nothing to do with the case at hand... :tomato:
(which G. Barron/UNN will soon point out ;D )

I would bet my firstborn's soul that you are correct on the second question. I don't see how the game could keep track of an object if it never created it...  unless it creates the object, and then hides it?

I concur...
Although I think OFP doesn't hide the object, it deletes it :beat:

Anyway, I'm pretty sure the type of object also has it's impact in this scenario since if it's some object that has many animations etc. OFP has load those anims (and probbaly even pre-render something else??) and I really doubt that OFP then 'flushes' the unneeded anims out once it has noticed that "oops, prob. of presence was that, me better delete this object"...

[THobson]

Interesting.   I am trying to slim down a mission, but having spent ages putting things in place I am lothe to delete them, in case I later chage my mind.  So I am setting their condition of presence = false, but it may be that some animations etc are not being removed.  I can see the logic there.

Bye the way

Well, this actually probably has nothing to do with the case at hand...

You are correct.  
The fact that thislist is being updated implies that the condition in even a fire once trigger is still being actioned long after the trigger has fired.  Hence my tactic to delete triggers once used.  

[456820]

i think it gets rid of it as in one of my missions when i delete a teigger wich is syqronised to some tanks when the trigers deleted the tanks go on to their next waypoint so im guessing yes

[General Barron]

I assume this is for your Abandoned Armies mission, which is going to stress the cpu no matter what you do (since it has so damn many units doing stuff at one time). This might be getting off the topic at hand, but it is about reducing CPU load, so here goes:

One suggestion would be to get rid of triggers ENTIRELY. The only triggers you MUST use are ones that update an array of units, and radio triggers. EVERYTHING else can be simulated via scripting, with a large delay loop.

Another suggestion has to do with scripting commands. Always try to get by with whatever the least-CPU heavy command you can use is. A common one for me is the "distance" command, which I tend to need a lot. It is pretty CPU heavy, since it works in 3D. If you only need to find the 2D distance between 2 units/locations, then just calculate it via trig. Better yet, if you don't need to find the actual distance, and only need to make > < comparisons, then don't square root. I use this function extensively:

GENB_distancePosSqr = {(((_this select 0) select 0)-((_this select 1) select 0))^2 + (((_this select 0) select 1)-((_this select 1) select 1))^2}

Just some stuff that the ECP has run into in trying to reduce lag.

[THobson]

In deed it is Abandoned Armies. There are a lot of units, probably around 650 loons in total (it is random each time), but nowhere near the 63 groups per side. I need to spend time  cutting down on CPU load and I am looking to where I am likely to get the biggest bang for the buck.  I was originally very careful about triggers, only using them where I needed some thing to hapen that was either time or spacially critical.  Recently I have added quite a few thinking 'its okay they will be deleted soon'  I then had a worry that maybe they still drain the cpu.  I guess I am jumping at shadows.

Good tip on the distance command, thanks.

I have tried to get a feel for what causes lag.  As a test I had an empty Malden on which I put 5,000 BMPs each running the smoke script I use.  
That is 5,000 @ getDammage _veh  > 0.98  commands all running at the same time.  Providing I could not see the BMPs there was no discernable lag.  If I could see them then the lag was deadly

Replacing the @ command with a loop also generated a lot of lag even when they were not visible.

I keep reading that static units create lag.  I tried to create lag by placing alot of the white wooden fences on the map.  I gave up at 30,000.  I just couldn't create any lag - mind you I couldn't put them close enough together that I could see that many of them either.

The lesson for me from all this is that I could spend a lot of time making changes that do nothing.

Multiple mobile units in the same viscinity, even if they are dead seem to cause some problems.

I'm rammbling now so I'll stop.

[General Barron]

I keep reading that static units create lag.

This is a crock. Static objects have about the smallest effect on lag possible, as you have seen from your experiments.

Islands have thousands and thousands of static objects placed on them, and they don't usually "lag". OFP was designed to handle $%#-loads of static objects like that. Otherwise we wouldn't make missions on huge islands, when we normally don't use 1/5th of the island for any one mission (since all the other static objects on the map would "cause lag", so for efficiency islands would be much smaller).

The biggest lag causers are just plain units I think. They seem like they would take the most CPU power to keep track of, since they have AI and can do more than any other object. Once bullets and explosives start flying, those have a huge effect on lag as well, if there is a sizeable amount at one time.

Here's an idea I just had: try disabling the AI on some or all of the units. Maybe then OFP won't run ~650 AI routines, which might considerably reduce CPU load. Use this command:

unit disableAI "target"

That will disable their combat movement AI (such as flanking). The change might not be noticable to the player. In fact, the AI usually isn't that noticable since they can't see past their noses.

[Mikero]

>since all the other static objects on the map would "cause lag", so for efficiency islands would be much smaller

Voila. Says it all.

Do you think this applies also to camCreated static objects? Certainly should do.

>explosions and movement.

there's the issue imho (with a very large H). Folklore says that choppers are the worst offenders and this would certainly make sense. Explosions would be the largest movement lag of all.

[General Barron]

Multiple mobile units in the same viscinity, even if they are dead seem to cause some problems.

Dead units are turned into static objects after a minute or so. So I doubt they would contribute any more to lag than any other static object. I bet you didn't wait long enough in your tests for them to be turned static.

Do you think this applies also to camCreated static objects? Certainly should do.

I would assume so. Actually, I think ANY object that is camCreated is "static". Try camcreating a soldier--all you get is an empty shell that can't "do" anything.

[THobson]

This is getting helpful.  Thank you.

I have also read that the number of groups is more significant than the number of units - so 10 individual loons each in their own group will cause more lag than 10 units in a single group.  I have not tested this, but in my mission I have kept group count down and loon count up where I can.

Dead mobile units becoming static after a while would explain why lag diminishes in and around the battle field over time.  

There is something though I feel about the visual representation of placed static objects vs those already on the island.

How about Event Handlers?

All my west loons have killed EH that says - was I killed by resistance if so set a flag, was I killed by east if so set a different flag .  Similarly for all the east loons.  I use one EH for each of these test - not knowing any better at the time.  Now I do know better I could do both test in one EH.  Only three kills are relevant in the mission.  The first east killed by resistance, the first west killed by resistance and the first kill of east v west (it is the same flag).  In fact this flag over rides the other two.  I had contemplated taking out all these EHs once they were not needed, but haven't yet.

Any thoughts would be great appreciated?

[h-]

EventHandlers are not loops.
I don't believe they cause any lag themselves...

Well, they might some sort of loops on some level if you wanna be pedantic and go insanely deep into C++ coding (or whatever OFP is written with)

[THobson]

That was my logic too.  But when a battle is going on these EHs are firing for each loon killed, mostly unnecessarily, so with all the bullets flying, explosions happening as well it might be area to cut down on the load.