Logical operators?

[Storsorgen]

Hello there!

I'm trying to make a comparison with a direction, but I can't figure out what the logical operator for "is not" is.
Usually I'd try != like in C++ or python, but that doesn't seem to work here. Does anyone know what it is?

[King_Cool]

You could right click the Condition and 'negate' it, but as i remember negating directions like this are kinda buggy and can produce some strange results, but its wort a try.

I think your best bet is to do 'direction <> [direction value]'

[Storsorgen]

<> couldn't be applied due to the nature of the event, but negating the condition worked! Thanks

[ProdigyX]

FYI Negating events are not buggy. Its essentially the same as changing from X = 5? to X <> 5 except with boolean values. So instead of checking for a condition is true, u would be checking if a condition is false. Nothing buggy/iffy about it. And in nearly all cases, the Negate is the '!=' operator used in c++

[King_Cool]

Glad you got iy sorted Storsorgen

I said negating directions might be buggy, i remeber having troubble compairing to a direction/ muliple directions ( using Direction Wheel ) before.
There would be a significant lag before the condition kicked in, but that was a long time ago ( i think ) and its probably not an issue at all now

[LB]

Negated events do not always handle object selection properly, you may notice some oddities. The true/false nature of conditions that select objects has always been...odd.

[Storsorgen]

Do you have any specific examples of when it might be buggy?

[EE]

Glad you got iy sorted Storsorgen

I said negating directions might be buggy, i remeber having troubble compairing to a direction/ muliple directions ( using Direction Wheel ) before.
There would be a significant lag before the condition kicked in, but that was a long time ago ( i think ) and its probably not an issue at all now

I believe that is due to the nature of comparing to multiple directions. When comparing with the direction wheel the condition picks one of the selected directions and compares it, in this case comparing if the direction is not the opposite of the one picked. If you have 16 selected directions to compare to it can take up to 16 loops before it compares to your desired direction, therefor the lag.
//EE

[Nifflas]

Do you have any specific examples of when it might be buggy?

The only case I know about is overlap checks. The condition [Negate] A overlaps with B returns:

True if neither A or B exists
False if A exists but B does not
True if A does not exist but D does

It's not necessarily a bug, maybe it's something with MMF2's object selection. It's clearly inconsistent and a design flaw though. However, other than this, to me negated conditions work quite well all the time and I use them a lot. I don't think anyone should be afraid to use them. If something doesn't work, just make a simple test like this and you'll know how to deal with it

[MuddyMole]

I believe that is due to the nature of comparing to multiple directions. When comparing with the direction wheel the condition picks one of the selected directions and compares it, in this case comparing if the direction is not the opposite of the one picked. If you have 16 selected directions to compare to it can take up to 16 loops before it compares to your desired direction, therefor the lag.
//EE

That's exactly what I thought (and nearly posted yesterday) - but then I tested it out to make sure, and it seems that isn't the case at all (I figured I must have just imagined it). I wonder if that's another thing that Clickteam have changed somewhere along the line?

And yes, negated collision checks certainly used to behave very strangely, even when both objects exist.
I'm currently using build 251, which doesn't filter objects properly when performing negated collision checks - they become simple on/off switches, just like when you use "compare two general values" instead of directly comparing object values.