AGK is a bit quirky due to lack of boolean type. It is integrated with the integer type, rather than being a proper type by itself.
So 0 and 1 can also be read as false and true respectively. Which can cause trouble with eval statements, such as in if, while and until. Infact, anything not 1 will be read as false unless you throw in an eval operator like =, < or >.
And there are more gotchas for new players. And/or operators concatenate evals. Think of each eval as a dimension. The more you throw in, the more complicated it gets.
Your first example reads as:
if <false> and <false> and <false>
// do stuff
else
// do something else
endif
Three false eval do not make a true eval, and since all three evals need be true for the if statement to return true, it'll do something else.
Your second example reads as:
if <false> or <false> or <true>
// do stuff
else
// do something else
endif
One of the evals return a true, so the if statement will read as a true and do stuff.
What you need do is have a proper eval on each variable (unless using as a pseudo-bool 0/1 variable naturally) - so your two examples should read:
if a = 5 and b = 5 and c =5
// do stuff
else
// do something else
endif
and
if a = 5 or b = 5 or c =5
// do stuff
else
// do something else
endif
Easier to read and reason over. In the first, all need equal 5, in the second any one need equal 5. Which is another thing to keep in mind - write code to make it easy to read. It may be a bit more verbose, and use a few more lines, but when you get back to it in a month or two you won't go "WTF?!" every two seconds reading it. Code quality is measured in "WTF?!" per minute - fewer is better.
