Deactivating an END2????

[ZNorQ]

@macguba

I've been following you and other great contributors in the community and want to thank for your work. It is therefor with great reluctance I have to disagree with you on two points;

#1 The initialiaztion part; I agree with most of your comments to NightJay0044, but as for the initalization of the boolean variable IN THIS CASE I do disagree. The variable isn't in fact 'false' - its 'scalar bool-something-something' in which case the !objective1Complete would work. The thing that matters is that the objective1Complete isn't TRUE.. Am I right? (I don't wanna argue with you, cus I'm abit uncertain on this point )

#2 There is logic in using 'switch' in his trigger - if he uses the !objective1Complete as we told him. Thats because if he managed to do objective 1 before seen, the enemy would start chasing him down (oh, well, if he uses waypoints and sycronizations right - that is).

Comments?

ZNorQ

[macguba]

Lol you should never be reluctant to disagree with somebody's answer, they are wrong sometimes and I'm not exception.    Anyway, we're discussing, not arguing.  

On the variable initialisation.    If the objective has not been completed, then the variable must be in one of two states:  either false or undefined.     If it is false, that's fine, that's what we want:  when west is detected the trigger will fire.    However, if it is undefined (i.e. not initialised) then the whole expression ("this and objective1complete") will return false.   Therefore the trigger won't fire even if west has been detected and the objective has not been completed.

As for the switch trigger, all I meant was that if a trigger effectively ends the mission then it doesn't matter if its type switch or not because the groups it is switching won't be able to do anything before the mission ends.    But yes, you're right, the objective1complete trigger that doesn't end the mission should indeed be type switch.

[ZNorQ]

Hehe, yes I'm saying it with a tad of irony to it .

Anyway, I see your point on the initialization bit. You might be right. If it wasn't for this work - I'd be poking the puter @ home and trying it out for myself. Hehe.

As for the switch trigger; Yes - an end trigger without any exceptions - I agree - no need to make that a switch trigger.. But NightJay0044 said he wanted (correct me if I'm wrong here) the alarm to go off no matter what - but it wouldn't end the mission if he already completed objective one. In which case the switch would make sence.

Basically, we agree with each other, macguba..  ;D

ZNorQ

[h-]

Actually, I'm a bit with ZNorQ on this, but also a bit with macca...

It is true that boolean variables do not necessarily need to be initialised, but it's safe to do that as all of you know that OFP uses what I like to call 'The Murphy's Law' engine which means that anything that can go wrong goes wrong (and sometimes even the things that can't go wrong, go wrong...)..

As for what macguba said about that sentence returning false is also true:
When AND/OR or IF/THEN/ELSE are used all the variables in that sentence need to be of some value, not for example that "xxxcoeefe blah blah" (it's not a value, it's a string)...
When numeric variables are used (as I like to do, 0=false, 1=true) the variables must always be initialised or else they won't exist.

I can say for a fact that for example in this particular mission the endmission variable is not initialised, but when set to true it triggers the endmission trigger...

So, when booleans are used alone they don't need to be initialised, but it is very wise to do so...


The type switch on a trigger does only apply when used on a waypoint.
I have tried huge amounts of different things with type 'none' and then with type 'switch' and only difference between them seems to appear only when synching them with waypoints...
Of course, I can be wrong...

[ZNorQ]

Yes, I do also think that the best thing is to initialize variables. Actually, I like programming languages that requires variable declarations before using them.

As for the switch type triggers - afaik (thx macguba for explaing that word - comes in handy now  ;D) switch is used only for waypoint; ie. a waypoint loop where you move a group from one point and back to the start using MOVE and CYCLE waypoints. Then add a SEARCH AND DESTROY type to another location. Only way (afaik (i just love that word)) to break the loop is to include a trigger of type switch. The strange part is that you have to sync it with the CYCLE - NOT the S&D waypoint... Where is the logic in that...?

ZNorQ

PS! Just remembered that there are script commands that can force change of waypoints...

[h-]

switch is used only for waypoint; ie. a waypoint loop where you move a group from one point and back to the start using MOVE and CYCLE waypoints. Then add a SEARCH AND DESTROY type to another location. Only way (afaik (i just love that word)) to break the loop is to include a trigger of type switch. The strange part is that you have to sync it with the CYCLE - NOT the S&D waypoint... Where is the logic in that...?

Quite.
But some people seem to have quite a few misconceptions about the type 'switch'...
So those test I made (were a loong while ago) because I wanted to make sure myself that it has no effect on anything else than waypoints

And for the logic, well, there are quite a few of things in OFP that have no logic what so ever.. ;D
Switch trigger usage is just one of them...

[NightJay0044]

Hi everyone, thanks a lot for your answers..I finally got it to work thanks to Hater_kint... Appreciate it, and you can find my mission under "beta missions" in these forums under my old post the i had of "conclusion.....Thanks again.. ,  ;D