Non-repeat trigger keeps checking condition after activation

[jarni 3]

I have a trigger (main_trigger) which checks it's own simple condition (player present in area) as well as activation of other trigger. So, it's condition looks like following:

this || triggerActivated some_other_trigger

My first problem has raised when some_other_trigger has not yet been created (I do create triggers dynamically in scripts, but with fixed, predefined names). triggerActivated some_other_trigger returns nil and whole expression returns nil. Trigger is never activated (well, until that other trigger is actually created). To solve this, I wrote a small function orTrigger which evaluates an array of triggers taking into account non-existent triggers (taken as false). During debugging that function I see that it is called, even when the condition has evaluated to true (triggerActivated main_trigger starts returning true).

 

My expectation was: if Repeat check-box in trigger attributes is un-checked, the trigger stops evaluating it's condition after evaluating to true for the first time. I know that documentation says that it simply stops calling OnActivation code after first time. But still, it looks non-logical. It also means that tons of triggers continue consuming resources even when their value already know and will never change. Deleting trigger can't be used in my case because I need main_trigger value for other triggers. I ended up simply disabling simulation for it.

 

Do I miss something? Do I understand the logics or usage wrong?

[Harzach 2517]

1 hour ago, jarni said:

I need main_trigger value for other triggers.

 

You could set a variable on activation then delete the trigger.

[jarni 3]

Yup, as one of the workarounds it'd do.

 

[Harzach 2517]

And yeah, conditions continue to evaluate after activation, which is why it is recommended to keep them as simple/optimised as possible. You could also stagger/increase eval times, but a half-second is already a long time.

[jarni 3]

1 minute ago, Harzach said:

And yeah, conditions continue to evaluate after activation

Unfortunately, this is not mentioned anywhere in documentation :(. Would have gone with the hashtable of evaluated triggers right from the start.

[sarogahtyp 1108]

A trigger has to check the condition after activation to recognize if it reaches deactivation state and run ondeactivation code. Thats the logic u missed.

 

Edit: It should be like I described above but sadly it is not... see @pierremgis post below.

[pierremgi 4886]

12 hours ago, sarogahtyp said:

A trigger has to check the condition after activation to recognize if it reaches deactivation state and run ondeactivation code. Thats the logic u missed.

 

It's totally useless for a non-repeatable trigger. There is no deactivation (code) and condition checks for nuts! deleteVehicle thisTrigger could be added at each end of activation code in this case. A pity BI didn't code that for non-repeatable trigger.

[sarogahtyp 1108]

52 minutes ago, pierremgi said:

 

It's totally useless for a non-repeatable trigger. There is no deactivation (code) and condition checks for nuts! deleteVehicle thisTrigger could be added at each end of activation code in this case. A pity BI didn't code that for non-repeatable trigger.

 

Yeah, I tested it now. You are absolutely right and its totaly nuts.

[Harzach 2517]

2 hours ago, sarogahtyp said:

 

Yeah, I tested it now. You are absolutely right and its totaly nuts.

 

You weren't wrong, though. It does continue evaluation, it's just that there is no purpose to it in a non-repeating trigger. 

[mrcurry 505]

4 hours ago, pierremgi said:

deleteVehicle thisTrigger could be added at each end of activation code in this case. A pity BI didn't code that for non-repeatable trigger.

That deffo is an appropriate workaround.

Having the game by default delete the trigger seems like it could cause issues. The trigger can still be useful for defining areas or presence-arrays. And what about MP? Should only the local trigger be deleted or should all machines be affected?

Seems like a can of worms better left for the mission editor to open.

 

Info about this behaviour should be in the docs though.

 

Curious question, can a non-repeat trigger be made to trigger again by updating it with setTriggerActivation?

 

 

 

[pierremgi 4886]

5 hours ago, mrcurry said:

That deffo is an appropriate workaround.

Having the game by default delete the trigger seems like it could cause issues. The trigger can still be useful for defining areas or presence-arrays. And what about MP? Should only the local trigger be deleted or should all machines be affected?

 

 

You're right, a trigger is also an area. Deleting it may delete the area as well. You can also thisTrigger enableSimulationGlobal false on it, that will stop the condition check.
In MP, deleting a trigger works fine. There is no error on deletion, global or local (server) (you can delete the same object on server only or globally without fails). For simulation, use enableSimulationGlobal for server only triggers and enableSimulation for non-server-only ones.

 

5 hours ago, mrcurry said:

Curious question, can a non-repeat trigger be made to trigger again by updating it with setTriggerActivation?

 

Yes you can!

You can change what you want by script: activation, interval... by setTriggerXXX commands.

 

Note (about trigger's locality for further readers) :

Spoiler

 

We are usually speaking about edited triggers, "server only" or not, "repeatable" or not. These triggers are like any edited objects, present on each PC (server and clients).

The reason why non-server-only triggers may spawn what you need * nbr of PCs in game! Just because we are using createVehicle (or equivalent) with global effect (so everywhere).

Such spawning assets should be done by server only triggers... (or somewhere else locally like headless client, but it's not possible by editor).

The other way is to write a code creating a trigger.  createTrigger command has a parameter for setting "effect" (read activation/deactivation codes) locally or globally (for everyone).

Now, think about:

- where the trigger is present (editor, local script, server script, everywhere)?

- what does the condition check. Preset like BLUFOR PRESENT should fire everywhere the trigger is present, with small delay by sync perhaps? But local condition exists (using player inArea thisTrigger for example)

- if scripted, is it a local or global trigger (isGlobal parameter)? local triggers have "independent life" even if the same condition fires everywhere. May be useful if you want to apply a code locally and not broadcast anything (setTexture for example)

- finally, do the on act/ on deact. codes use global or local commands?

 

 

 

 

[fawlty 30]

With regards to delete this trigger

If you sync a trigger to a show module for example and have a 'delete this trigger' in activation is there ever a chance the trigger could be deleted before it activates the module?

[Harzach 2517]

You could spawn the deleteVehicle command with a sleep if you are concerned about it. 

[jarni 3]

On 9/12/2022 at 8:24 AM, pierremgi said:

There is no deactivation (code) and condition checks for nuts! deleteVehicle thisTrigger could be added at each end of activation code in this case. A pity BI didn't code that for non-repeatable trigger.

Thank you for confirmation. In the end, I do delete non-repeatable triggers after activation, storing their state to a hashmap for fast checks. I don't need their area anymore when they are done, so I can delete them. Otherwise, I'd just simply disable simulation for them. This stops checking, but doesn't remove area related calls.

 

Another trigger related question, partially related to this one. Trying to optimize load I tried to prolong intervals between trigger checks to 30-60 seconds, but, I actually received an opposite result, trigger checks started to run faster. My findings are:

Trigger intervals x in range [0, 10] -> 1:1 ratio -> check every x seconds

Trigger intervals x in range (10,600] -> 1:0.1 ratio -> check every x/10 seconds with very non-regular timing (for example, if set to 600, the check condition is done in range of 57-63 seconds)

Is this a know feature/bug? Again, I don't see it anywhere in documentation for triggers, for setTriggerInterval particularly.

[pierremgi 4886]

2 hours ago, jarni said:

Trigger intervals x in range [0, 10] -> 1:1 ratio -> check every x seconds

Trigger intervals x in range (10,600] -> 1:0.1 ratio -> check every x/10 seconds with very non-regular timing (for example, if set to 600, the check condition is done in range of 57-63 seconds)

Is this a know feature/bug? Again, I don't see it anywhere in documentation for triggers, for setTriggerInterval particularly.

 

Yes confirmed. You can open a ticket here.

[jarni 3]

14 hours ago, pierremgi said:

You can open a ticket here.

Done. That's the third ticket in 2 days :(. I'm curious if Reforger is of the same "quality".