Trigger activation by waitpoint completion.

[Muzza 0]

I tried from the OFP FAQ thread

How do I make a trigger activate when another trigger is activated and a unit is in the trigger area?

If you want the second trigger to be activated by a specific person or group, group the trigger to them. Then type in the ACT. field on the first triggerCode Sample

t1=true

Then type in the second triggers Cond. field Code Sample

this && t1

This insures that the triggger won't activate until the first trigger is activated and your group is in the second triggers area.

By putting on act in thw waitpoint t1=true

And in the trigger's conditions this && t1

Hoiwever im getting no joy, can anyone point out where ive gone wrong?

[Op4 BuhBye 0]

That wont work. If you want a specific unit to activate a trigger you need to group the trigger to the unit. Set it to vehicle present and set a publicvariable in the OnAct field to set off another trigger.

In the condition field of the trigger put this and variablename == 1

Then it will look for the unit and the variable present.

Make an "init.sqs" and define the variable.

variname = 0

publicvariable "variname"

[fasad 1]

what are you trying to do? Do you need a trigger at all?

[Op4 BuhBye 0]

After reading this again I see what hes doing wrong.

You have the right Idea but you need to define the variable like I did in the above example. You cant just set a variable like dead = 1 in a trigger.

Im not sure what that does in ArmA but I think in OFP doing that made it a localvariable which wouldn't do you any good in that application. Define it like I said and it will work.

[baddo 0]

Official Command Reference for Operation Flashpoint 1.85 states that if a boolean variable used in a condition statement is undefined, the result is false.

Quote[/b] ]When undefined value is encountered in field where boolean value is expected, it is converted to false.

And it actually works like that in Operation Flashpoint. I bet, without specifically testing it in ArmA, that it works the same in ArmA too as I see there is no reason for BIS to change this behaviour. And global variables can be initialized in triggers.

We don't know if this is for single player or for multiplayer as the topic starter doesn't say it.

If we get more information from the topic starter we could maybe see where the problem is. Now that I look at the first post, I really can't say what is going wrong.

[CarlGustaffa 4]

I expected this behaviour too, in ArmA, but ended up with problems. In an End trigger I checked against some boolean value being true, and it activated when it was true.

However, another end trigger checked against the same value being false, and it never activated. I had to initialize the value to false; I used a trigger to initialize, but I've seen boolaens being initialized to false in some default missions.

Then, and only then, would my second end trigger work correctly. So I don't think undefined variables defaults to false.

But it's kind of logical to me now; how would ArmA engine know that a variable was to be a boolean if not initialized, since we don't actually have to declare them? Not sure if this is related to the problem though, but Baddo should check out some default scripts and/or some external scripts made out by others. I.e. the ubran patrol script (ups).

[Bobobski 0]

I don't think you need additional global variables if you want specific objects to activate triggers, we already have global variables that we can attach to objects in the form of an object name (player1, unit1, etc.).

For example, to get a unit named 'unit1' to activate a trigger when it enters a trigger area put:

unit1 in thisList

in the trigger condition field. If you also want the activation of this particular trigger to be dependant on a second trigger being active at the same time, then give that second trigger a name also, e.g. 'T2' and now add that to the first trigger's condition line thus:

(unit1 in thisList) && (T2)

That should work, and I don't think you need the brackets, but I like to add them anyway to visibly separate out conditions.

[baddo 0]

But it's kind of logical to me now; how would ArmA engine know that a variable was to be a boolean if not initialized, since we don't actually have to declare them?

Well the Official ComRef says for OFP 1.85, that where a boolean value is expected, undefined value(variable) results as false. That can be understood only in one way, and that's what I explained in my previous post. I can say for sure when testing for a true condition this works in OFP. The trigger will not execute until the variable is introduced and given a value of true.

I can't access ArmA now but I will verify this to be true for ArmA too when I have the chance to do so.

About looking at other peoples' scripts: it is, from time to time, great to look at what other people are doing. But about initializing all global variables in mission start, it really is not necessary for me to start learning about it from others. It is a good practice (sometimes even technically required, but not always) and I actually learnt how to do that without reading it from some other peoples' scripts. I've written all mission-specific global variables into top of init.sqs and by the way, I put comments next to them about where their values are changed and where their values are checked. That makes editing a mission quite a lot of easier, as I can look at the mission one year from now on and immediately know where the global variables are used.

[ColonelSandersLite 0]

CarlGustaffa's thing would actually depend on how exactly you do it.

Assuming you never initialised it:

Var == true results in: false

Var == false results in: false

Var == 52 results in: false

Why? a null value never equals anything.

If you did this though, it would work:

Var != true results in: true

not(Var == true) results in: true

I must advise against doing that though. Doing only that can mean a bit of a nightmare debug to figure out what's wrong.

[Op4 BuhBye 0]

I was always under the impression that when you use a variable of any kind you have to define the type and the value. If you just say, like he did above

t1 = 1 without defining the start value and the type in the init.sqs (Public, Global or local). How would the engine know what type of variable its using or the start value?

Every time I use a variable I define it in the init:

dead = 0

publicvariable "dead"

Then in game, when I change the value in a trigger or script, I re-define it:

dead = 1;publicvariable "dead"

I found in OFP that if I changed a value like dead = 1 and I didn't follow it up with publicvariable "dead". Some times it would work and some times it wouldn't.

[baddo 0]

If you are scripting for single player, then the publicVariable is completely unnecessary. It broadcasts the variable over network to other computers in a multiplayer session.

To get terms straight, a type of a variable is not one of public, global or local. A type of a variable is for example boolean, array, float and so on. Public, global and local are about where your variable is visible. Scope of a variable as so to speak.