OFPEC Forum
Editors Depot - Mission Editing and Scripting => OFP - Editing/Scripting General => Topic started by: Bremmer on 10 Sep 2002, 21:00:43
-
Hello
I've run into a little trouble with the @ command. It doesn't seem to recognise the OR command (or ||). In fact it seems to treat these like AND, which just adds insult to injury.
Has anyone had any luck with getting an expression like the one below to work properly?
@ (condition1 or condition2)
:-\
-
that's weird...in my experience the @ works almost exactly like a simulated trigger condition line ; wait 'til the condition is true, then continue. Thus, all ANDs and ORs should work just dandily....humm. Haven't used it all that much, but I've never run into this problem.
Damn. What am I replying for...OFP isn't working so I can't check it. Is it a RES problem? In that case there are two reasons I shouldn't get involved ::) Arrgh, symphathy reply!
(going to bed now... :-X)
Wolfrug out.
-
Yeah, there is a bug here, both in RES and 1.46 (and probably since the beginning).
I usually run into it when combining a simple boolean variable with a boolean expression, such as:
@(playerready or timer > time)
There is a workaround, although it's not for the timid:
OR condition:
ConditionArray = ["playerready", "timer > time"]
@"_X Count [0] > 0" Count ConditionArray > 0
AND condition:
ConditionArray = ["playerready", "timer > time"]
@"_X Count [0] > 0" Count ConditionArray == Count ConditionArray
When the basic expression fails, put your faith and expressions in ConditionArray your way shall be clear.
-
Nice work around Dinger. My solution was rather cruder. Instead of:
@ (unitready leader _run or groupdead)
I used:
#loop
~1
? groupdead : goto "groupdead"
? (not unitready leader _run) : goto "loop"
Nasty, but effective :( I think I'll contact BIS about this - hopefully they'll sort it out in the next patch.
Cheers
ps. Thanks for the sympathy Wolfrug - it's much appreciated :-*. I'll leave this topic open for a little longer to see if anyone else has any ideas.
-
Hmm... works fine for me ???
I was using something like:
@ _variable < 1 or not (canmove unit) or not (alive unit) or (fuel unit < 0.2)
That wasn't it exactly... but the point was I had strung a hell of a lot of conditions together, and every one of them worked... hmmm
-
RalphWiggum over at the official forums pointed out the command works as long as the variables are both declared false prior to the command.
This is quite interesting, as the only other place I've found the need to declare variables is when checking a not cond type statement, in which the statement is not true if the variable is not defined. So why in this condition (@ cond1 or cond2) does this matter? If one of the conditions becomes true surely it shouldn't matter that the other is undefined?
???
I'll leave this open for comments for a while, but I guess the problem is 'solved'.
-
That's a different issue.
Any boolean expression containing an undefined variable will be false.
So
@(undefined or !undefined) or true
will always be false (providing undefined is undefined), and never continue.
If you must deal with undefined variables, the workaround I listed above will work.
As far as the multiple conditions thing goes, well, I've encountered it before. In fact I had a script that would wait for a variable (that was already defined) to reach a certain value or for time to pass a certain point. When I had the or time>timer part in, the script would hang and refuse But now I can't duplicate it, so it may not actually exist; or it may have been fixed in 1.75.
-
Being a bear of very little brain I cracked the "undefined" nut with a very blunt sledgehammer. List all the variables that could theorectically appear in an expression before they were defined in init.sqs and set each one to true or false as appropriate. That way you get round the whole problem.
It's ugly, but it works.
-
That's exactly what you should do... define all your variables in your init.sqs
To my understanding, a variable was neither true nor false until it had been defined.
However I've never really mucked around with it to be sure as I generally define my variables just to be on the safe side ;)