What happens with activated trigger?

[zapat 56]

I have a trigger made by a script, activation set to ONCE.

What happens to it, once it gets activated?

It should stop checking since it is not needed anymore. But does it?

What I know is that it is not deleted after activation (since I can get its attributes later on) although it is completely useless to keep it.

I ask it, because I create maaaany triggers on-the-fly in my dynamic mission, which are used once, and then they are just garbage. The number will depend on how long the mission is run, thus can be thousands of those.

Should I delete them manually? Or is there a garbage collector for them?

Or should I leave them as is, since they are harmless once activated?

[twirly 11]

You can use this to delete them.... it's probably the best thing to do.

deleteVehicle [i][b]triggername[/b][/i];

Edited November 7, 2011 by twirly
Clarity

[CarlGustaffa 4]

What you want to do with them depends on the nature of the trigger. If I know it's useless after activation, I tend to delete them myself. If not for the speed, maybe for the memory (I also try to nil out unused variables). Depending on what they hold they can be very slow and use quite a bit of memory, but by now I've usually switched to written scripts and functions. I can have 600-800 sound triggers that aren't felt at all wrt fps (no, not placed manually :p), or a single complex engineer trigger with object search running, pretty much halving my fps.

I can't imagine a garbage collector would automatically delete triggers, unless you made it yourself and specified it to do so. I.e. a church_chime sound trigger, that starts at 0800 and plays a sound from there on once an hour (using the sound class timers). Should it be deleted once activated? Once you delete the trigger the sound goes away (well...).

What if you in scripts want to reference the triggers list or position data? That being said, I try to avoid triggers as much as possible, as they clutter my code and/or messes up the editor screen. For flow (in a SP mission), I like the new outline used in BIS own missions - fsm with debug branches, where I first have tried out the major parts on their own. Fsm editor is however only adequate for this, and its "script editing" features are way below par.

So it's pretty much the same as any other script. You evaluate the overhead created and take action on that if needed.

[zapat 56]

Thanks a lot for the answers!

What you want to do with them depends on the nature of the trigger.

They are dynamically placed for checking player's distance to various positions. If player enters radius, a script is called. Once the script is called, the trigger is not used anymore. If it is needed again (the player leaves and I need to check if he returns), the script places another one.

by now I've usually switched to written scripts and functions. I can have 600-800 sound triggers that aren't felt at all wrt fps

If you have an idea for my purpose, I'd appreciate it! I tried several things, but triggers seemed the easiest to implement although I agree that you can have greater control by using custom scripts.

Should I put the checks into the FSMs that are run when the trigger activates? Then there is only one distance check running for monitoring player's distance.... I thought that trigger checks are fewer than FSM condition checks, thus eating less performance. I've never used triggers before, and I am starting to see that there is more going on with triggers. :)

I can't imagine a garbage collector would automatically delete triggers ... I.e. a church_chime sound trigger...Once you delete the trigger the sound goes away

I thought, a trigger is only for triggering, but it seems stuff is attached to it. It behaves like an object then, is it? Thanks for clarification!

You evaluate the overhead created and take action on that if needed.

Yes, but for this you need to know, how things really work. Not only how to use them, but what do they really cause once used.

Edited November 7, 2011 by zapat

[CarlGustaffa 4]

They are dynamically placed for checking player's distance to various positions. If player enters radius, a script is called. Once the script is called, the trigger is not used anymore. If it is needed again (the player leaves and I need to check if he returns), the script places another one.

Again, depends if you want accurate results or can live with delays. Many triggers like that won't cause that much of a performance hit, but they may fire accurately. A huge number of triggers might cause a performance hit, and looping over an array of data to check against may be wiser but may not fire as accurately. Consider this array:

myArray = [

[pos1, radius, scriptindex],

[pos2, radius, scriptindex],

[pos3, radius, scriptindex]

];

With that you can have a single script file looping over everything with as much delays as needed and have things remain smoother than 3 triggers checking. Try both approaches to create your own expected numbers, and see it affects performance and size of savegame (if SP), of course with a lot more than three entries.

One thing to keep in mind is that a script with delays are scheduled, which means they are prone to slowing down if overall mission load is high. I don't think triggers suffer this problem, but no guarantees.

I thought that trigger checks are fewer than FSM condition checks, thus eating less performance. I've never used triggers before, and I am starting to see that there is more going on with triggers. :)

Yeah you're probably right on FSM checking more often, but I was thinking more of structuring a mission flow using a single FSM rather than trying to maintain current on a whole bunch of triggers.

However, if you've never worked with triggers (how? :p), then better get started and get acquainted with them. There are stuff that only triggers can do, so it's good to know about their possibilities.

I thought, a trigger is only for triggering, but it seems stuff is attached to it. It behaves like an object then, is it? Thanks for clarification!

Yes, a trigger is "just" an object, but obviously with different properties.

Yes, but for this you need to know, how things really work. Not only how to use them, but what do they really cause once used.

You don't really need to know how things work, only be able to setup a test for it :) As mentioned my "true" sound triggers doesn't seem to cause much overhead at all. A normal "player in thislist" may have different cost than attaching/grouping all trigger to player - I don't know because I never tried. And complex trigger "on activation" fields calling huge functions may be too much for any system to handle.

[zapat 56]

Thanks CG, you gave me very good ideas!

My problem with the list checked by one script has always been dynamism. The list is always changing as the player moves (entering areas, leaving others, troops moving, objectives changing), thus I would need to apply array manipulation via sqf, which is slow.

And it is scheduled too, which is a good point (thanks for it) in triggers versus sqf distance checks.

In my tests I am okay with like 1000 triggers, they are sitting on my map without dropping 1 fps.

What I don't kow is, what happens, if those starting to get activated and then left, and new triggers come into place. Total trigger count stays at 1000, but can the already activated triggers cause problem, as their number grow?

Are they only an object, or do they keep checking (creating thislist and stuff) inspite of having been activated?

Anyhow, savegamesize makes me want to delete them after use... :)

About not using triggers before: editor -being static- has never attracted me, programming dynamism has always. Thus editor features are missing in my development. :)

Edited November 7, 2011 by zapat