Triggers & performance

[monotwix]

Hi Dudes and Dudesses.

I wonder if you could enlighten me, I don’t know if the number of triggers and trigger zones make a significant impact on processing and computing performance in multiplayer missions.

I would like to know if that’s the kind of resource I should be conscious about when creating a mission and sustain a good performance?

[Grimes]

Unless you have a bunch of continuous triggers executing something graphical every second, you aren't going to see much of a performance impact. The number of AI has a far bigger impact than triggers ever could.

[monotwix]

Thanks Grimes, my primary concern was that adding multiple trigger zones and making them linked to a number of AI and/or Players would substantially increase the processing.

I understand that a SAM site is not graphically visible unless it’s in sight range and its detection and firing has its process.

If there are three Aircraft linked to three Trigger Zones, would that be equivalent to three SAMs in that respect or is that not the case to be concerned about?

 

Edit:Sorry, those SAMs, I’m referring to the detection radius in zones and processing, not the actual SAMs.

Edited August 5, 2012 by monotwix

[Speed]

Thanks Grimes, my primary concern was that adding multiple trigger zones and making them linked to a number of AI and/or Players would substantially increase the processing.

I understand that a SAM site is not graphically visible unless it’s in sight range and its detection and firing has its process.

If there are three Aircraft linked to three Trigger Zones, would that be equivalent to three SAMs in that respect or is that not the case to be concerned about?

 

Edit:Sorry, those SAMs, I’m referring to the detection radius in zones and processing, not the actual SAMs.

 

Not sure what your question is (there is no way to "link" trigger zones to anything, you just use them to detect certain conditions). Just understand: don't worry about triggers slowing down the game. Just don't. Make whatever triggers you need, and as many of them as you need. Triggers are incredibly simple compared to any AI algorithms.

Edited August 10, 2012 by Speed

[Grimes]

I echo Speed's statement. However to clarify my original comment, I meant the triggers related to illumination flares, explosions, smoke, or colored flares, in that all of those cause your computer to render something. Where-as checking if flags are true or if a unit is in a zone has virtually no impact on your games performance. For example you will see an impact if you have 500 explosions occur at the same time, but not if you check if 500 units are in a zone.

[monotwix]

Thanks for the replies fellows.

What are your thoughts about the number of active units not to exceed for practical MP performance? Lets assume 20 clients.

[Speed]

Thanks for the replies fellows.

What are your thoughts about the number of active units not to exceed for practical MP performance? Lets assume 20 clients.

 

Once you exceed around 700 or 800 units, you might start to have a problem. Sounds will stop working, dcs.log will begin to approach 10, 100, even 1000MB in size (filled with "invalid sound source" errors), and the server host will probably crash eventually.

[Habu23]

Operation Bactria uses 184 triggers, 30 of which are continuous with no degradation of performance whatsoever. Occasionally sound files are cut short as of v1.1.1.1 of DCS: A-10C. In my experience the lowest FPS in missions comes not with mission triggers or frameworks, but rather excessive units at airfields and large battles on the ground. Another thing to note is that large concentrations of static objects (50+) in small areas lead to FPS drops whenever you look in that direction.

 

Habu

[monotwix]

Speaking of dcs.log Speed has mentioned. Is that a temporary file?

I have recently discovered the DCS multiplayer tracks folder and that was loaded with tons of tracks which I couldn’t care less about, but if I forget to delete them, it will run into many Gigabites/GaGa over time.

With Tacview you have the option to what and when to record whereas the option for the study SIM is yet to be einsteinetised.

Edited August 11, 2012 by monotwix

[Ripcord]

Once you exceed around 700 or 800 units, you might start to have a problem. Sounds will stop working, dcs.log will begin to approach 10, 100, even 1000MB in size (filled with "invalid sound source" errors), and the server host will probably crash eventually.

 

Speeds, thanks for this.

 

Is that 700-800 units within a relatively small radius, say along the front line? Or just 700-800 units period, even those that are far far away from the hostilities.

 

What if I had 200-300 units spread out literally all over the map -- primarily in the form of SHORAD and AAA/SAM units -- near FARPs and airports, plus 400 or so combat units that are actually involved in the fighting going on at the front. As long as nobody in MP goes off way outside the intended battle area, then those 200-300 units would never actually DO anything.

 

I just didn't want a situation in MP where a human flight could just go fly off over bad guy territory and go totally untouched just because he had managed to avoid the front lines and all the combat engagements going on there.

[Speed]

Speeds, thanks for this.

 

Is that 700-800 units within a relatively small radius, say along the front line? Or just 700-800 units period, even those that are far far away from the hostilities.

 

What if I had 200-300 units spread out literally all over the map -- primarily in the form of SHORAD and AAA/SAM units -- near FARPs and airports, plus 400 or so combat units that are actually involved in the fighting going on at the front. As long as nobody in MP goes off way outside the intended battle area, then those 200-300 units would never actually DO anything.

 

I just didn't want a situation in MP where a human flight could just go fly off over bad guy territory and go totally untouched just because he had managed to avoid the front lines and all the combat engagements going on there.

 

That is 700 or 800 total, including units that are not even activated yet. It's not a hard limit either- 700 to 800 is just the results of my own personal experiments, and I've seen some folks claim they had not problems with missions with over 1000 units (though I could not verify their claims myself).

 

You know you are having a problem when you start seeing a lot of "invalid sound source" errors in dcs.log. Just keep an eye on that.

 

I have, however, thought of a work-around for missions that have a large number of randomized units, where the final number of units, after randomization, is less than the unit limit:

 

1) Place ALL air units and player units on a mission start + 1 second start time. Maybe place ALL units on mission start + 1 second start time.

2) Use MISSION START type triggers to randomly deactivate units you will not use. DEACTIVATED units are removed entirely from memory, and thus do not count towards this 700-800 unit limit.

 

Now, when you spawn aircraft and allow players to spawn 1 second after mission start, the mission no longer exceeds the maximum unit limit, and there are no problems. Due to this issue http://forums.eagle.ru/showthread.php?t=91884 , it is desirable to have triggers that explode any players that force their way into an aircraft before 1 second has elapsed in the mission. I put in the brief, "DO NOT JOIN AN AIRCRAFT UNTIL 1 SECOND HAS ELAPSED IN THE MISSION!". If they still join an aircraft anyway, they get exploded, and sent the message "The Defense Department regrets to inform you that your sons are dead because they DIDN'T READ THE BRIEFING."

Edited August 11, 2012 by Speed

[Ripcord]

That is 700 or 800 total, including units that are not even activated yet. It's not a hard limit either- 700 to 800 is just the results of my own personal experiments, and I've seen some folks claim they had not problems with missions with over 1000 units (though I could not verify their claims myself).

 

You know you are having a problem when you start seeing a lot of "invalid sound source" errors in dcs.log. Just keep an eye on that.

 

I have, however, thought of a work-around for missions that have a large number of randomized units, where the final number of units, after randomization, is less than the unit limit:

 

1) Place ALL air units and player units on a mission start + 1 second start time. Maybe place ALL units on mission start + 1 second start time.

2) Use MISSION START type triggers to randomly deactivate units you will not use. DEACTIVATED units are removed entirely from memory, and thus do not count towards this 700-800 unit limit.

 

Now, when you spawn aircraft and allow players to spawn 1 second after mission start, the mission no longer exceeds the maximum unit limit, and there are no problems. Due to this issue http://forums.eagle.ru/showthread.php?t=91884 , it is desirable to have triggers that explode any players that force their way into an aircraft before 1 second has elapsed in the mission. I put in the brief, "DO NOT JOIN AN AIRCRAFT UNTIL 1 SECOND HAS ELAPSED IN THE MISSION!". If they still join an aircraft anyway, they get exploded, and sent the message "The Defense Department regrets to inform you that your sons are dead because they DIDN'T READ THE BRIEFING."

 

Hey, I like it. Thanks Speed!

 

I have, for instance, 200 or so units in around Tbilisi, at airfields, at FARPs, at various posts and camps and locations and another 100-200 units up in Russia proper - again, many of them are SAM sites and SHORAD units - that simply WOULD NOT get involved whatsoever in a mission where the battle is in an around the central valley south of Tskhinvali or the Pankisi Gorge or Abkhazia or someplace. I want them there in case some nut MP pilot goes off on a wild tangent just to see what happens. I suppose there would be no trouble ACTIVATING them again should some flight get within range, eg,. enter a big trigger zone.

 

EDIT: If I really do not require the random aspect of selecting which units need to be deactivated, would I even need to use a trigger at mission start to deactivate them? Any reason why I would not simply just deactivate them from the beginning and use the trigger zones to activate them later during the mission if somebody gets close enough?

Edited August 11, 2012 by Ripcord

[Speed]

Hey, I like it. Thanks Speed!

 

I have, for instance, 200 or so units in around Tbilisi, at airfields, at FARPs, at various posts and camps and locations and another 100-200 units up in Russia proper - again, many of them are SAM sites and SHORAD units - that simply WOULD NOT get involved whatsoever in a mission where the battle is in an around the central valley south of Tskhinvali or the Pankisi Gorge or Abkhazia or someplace. I want them there in case some nut MP pilot goes off on a wild tangent just to see what happens. I suppose there would be no trouble ACTIVATING them again should some flight get within range, eg,. enter a big trigger zone.

 

Once deactivated, units cannot be reactivated again, sorry. Deactivated units are erased from existence.

[Ripcord]

Once deactivated, units cannot be reactivated again, sorry. Deactivated units are erased from existence.

 

Aha -- this is a pretty important detail. Thanks Speed!

[Speed]

Aha -- this is a pretty important detail. Thanks Speed!

 

Yea, the ME has a lot of unwritten or unclear rules you just have to figure out for yourself with experiments. These rules make the ME a bit trickier to deal with. For example, here's some more I can think of:

 

-Unactivated units are alive

-Deactivated units are dead

-UNIT OUTSIDE ZONE functions as (UNIT ALIVE AND OUTSIDE ZONE) OR UNIT DEAD

-ONCE, SWITCHED, CONTINUOUS trigger types are all continuously evaluated (unless tied to an event), but conditionally (based on trigger type) executed

-Because of continuous evaluation of all other trigger types, it is often best to use the RANDOM condition with the MISSION START trigger type, which is only evaluated a single time

-All flags are initialized at mission start to FALSE

-SWITCHED -> (False condition) will not work at mission start, as the previous value of the condition was non-existent.

Edited August 16, 2012 by Speed

[monotwix]

It’s so logical to Yea or No, True or False...

If a Client unit died in zone, is it alive outside the zone?

I think the triggers mustn’t go into a loop, time since and flag off may keep it from crashing.

[Speed]

It’s so logical to Yea or No, True or False...

If a Client unit died in zone, is it alive outside the zone?

I think the triggers mustn’t go into a loop, time since and flag off may keep it from crashing.

??

I don't follow :huh:

[monotwix]

Loop? Is when there is a feedback or contradiction between true or false.

What’s is the state of a unit in terms of ON/OFF when 1=ON and 1=OFF.

[Grimes]

It’s so logical to Yea or No, True or False...

If a Client unit died in zone, is it alive outside the zone?

I think the triggers mustn’t go into a loop, time since and flag off may keep it from crashing.

 

No, if the client unit isn't spawned (or is dead) then it has no position in the 3D game world, therefore the definition of it being inside or outside a zone will always be false. With the trigger system, I dare say it is impossible to put a PC into a logic loop which causes the sim to crash.

[monotwix]

Interesting, I’ve got something going on in certain DCSW single player missions that causes the game to crash every time and some other DCSW missions never crash. I suspect it has something to do with the triggers because the units shouldn’t crash a mission by themselves.

 

As I recall reading some thread in which some one described his attempt to add a Radio Item with continuous trigger which resulted in the whole screen being populated with Radio Items. hehe.

[Druid_]

Interesting, I’ve got something going on in certain DCSW single player missions that causes the game to crash every time and some other DCSW missions never crash. I suspect it has something to do with the triggers because the units shouldn’t crash a mission by themselves.

Not necessarily so. In fact I am definately more inclined to believe ground unit AI behaviour and weapons are responsible for game crashes rather than trigger logic.

 

If you are having problems with a .miz then please post it up along with your crash file. You never know you might have something we are yet to detect.

[monotwix]

This mission always crashed after a few seconds from the start when I played as Ground Force Commander but yesterday after 5 attempts to run it, it had crashed 3 times and twice appeared stable for long enough to complete the mission.