Jump to content

So simple, but never worked it out before


AUS_Viper

Recommended Posts

I just worked something out that is so simple, yet has eluded me for a while.

Many may already know this, but hopefully it's news to some - as it was to me. It certainly made the "penny drop" and helped a lot of other things fall into place. It regards the use of triggers in the editor.

We all know how to set up a trigger that is set off by BLUFOR present. Simple stuff. You check all the right boxes ie activation BLUFOR present, type switch...yadda yadda yadda. I won't go into further detail for the fear of being condescending....

We also know that if we take that same trigger, hit F2 and drag a line from the trigger to say...the player, that this trigger will now be activated by him only (the activation box automatically changes to vehicle - which is both men and vehicles in VBS / OFP). Nothing hard here yet......

But what if you wanted this trigger to be set off by the player only after some other condtion was met first? For the sake of explanation, lets say after objective one is complete and the player stumbles into this trigger you want a counter-attack to occur. Obviously, you don't want this counter-attack to occur if he stumbles into the trigger before objective one is complete.

What I used to do is change the condition field from the default "this" to your condition variable. Again, to keep things simple, lets say after objective 1 is completed the variable "one" is set to true (one=true). Therefore, you would replace the "this" in the condition field with "one".

Seems logical enough. The trigger is still set to BLUFOR present and the condition field has "one" as it's variable. So you would think that this would be set off after one has been set to true AND the BLUFOR player wanders into the trigger zone.

WRONG.

I have used this many times before and once the variable is set to true, the trigger's activation executes regardless of whether our BLUFOR player has entered the trigger radius. Now for the cool stuff.

It all revolves around the default value in the condition field...."this".

I never spared a thought on what this meant, but now I understand completely - it's so simple! "This" means "this trigger". Think about it for a second. It's the activation field and it has "this" as the default value. Why? Because you have already set the activation parameters in the above sections...ie BLUFOR...present.

"this trigger will activate if BLUFOR is present".

So if you want the trigger to activate if BLUFOR is present AND if condition "one" has been set to true, you don't delete the "this" and replace it with "one", you would type:

this && one

Which means, the variable one has been set to true AND (&&) this trigger's conditions have also been met (ie BLUFOR present).

I hope I haven't lost anyone in the translation......

Anyhow - I think this is pretty important stuff as it has made me look at triggers in a whole new way, now I understand what "this" really means. It could help with objectives, ending missions etc etc etc.

If this is old news for the seasoned OFP scripters - then I apologise for my unashamed excitedness. But then again, judging by the amount of condition fields that are left with the default "this" in missions I unPBO, I'm tipping it's something most have dismissed.....

Anyway - I'm certainly happy about it as it fixes a LOT of issues I have with multiple-condition-based triggers.

Cheers

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...