Im pretty sure this line of code is not working correctly, but I have been wrong before.
Set Allow to (AutoLR XOR LOCAL)
Allow is a boolean local variable
AutoLR is a boolean global variable
LOCAL is a boolean local variable
When AutoLR = F and LOCAL = T
Allow is set to F by the statement Set Allow to (AutoLR XOR LOCAL)
I don't know about RM, but "false" and "true" are both valid values for Boolean variables. So it seems reasonable that AutoLR would take the first valid value received (which in this case is "false").
I agree that (0^1) = 1 in general... Maybe a bug...
I can reproduce this behavior. My simple test case was this:
This produces the unexpected result:
myTestVariable gets set to
false in both cases (I tried two in case operand affected the results) where as it should get set to
true under the conventional interpretation of XOR, which it looks like @JasonJoel also thinks.
But then I dug deeper.
I tried a plain
OR, which under any reasonable interpretation should set
myTestVariable to true in the above. But instead:
Identical results as with XOR: false in both cases.
For fun, I tried NAND just in case this was a general problem with the type of action I was using:
This produced the expected result. Then I tried something that I knew should give a
false result, like AND. That worked as expected, so then I tried a "weird" operator again, XNOR, that should have also resulted in
@bravenel, I think there might be problems with at least a few of the logical operators in the "Set Variable" feature of RM when used like this (or with at least a few other operators besides XOR):
FWIW, XOR (the most unusual operator I have the option of choosing there ) appears to be fine when used in conditionals:
There is indeed a bug in Rule with respect to this. It's an uninitialized variable bug. Fixed now:
Now four sets of logs for all possible values of true and false for A and B: