Blender controllers (logic circuits)

In the Blender game engine you can create logic circuits in logic editor. I saw some unnecessarily complicated logic circuits so I decided to write something about the controllers.

Blender has logic gates in middle pannel. The gates are: AND, OR, NAND, NOR, XOR, NXOR. You always use that, when you need to do some logic of the character or AI or something.

The logic circuits can by minimized with Karnaugh map, but it is for bigger circuits. On the output of the logic gates can by logic 1 or logic 0.

Logic gates

AND: The output of AND gate is logic 1 only , if all entrances of the gate are logic 1.

OR: The output of OR gate is logic 1 only, if at least one of its inputs is logic 1.

NOR: The output of NOR gate is log.1 only, if the all entrances of the gate are logic 0.

NAND: The output of NAND gate is always logic 1, if at least one of the input of the gate is logic 0.

XOR: The output of XOR gate is log.1, if the inputs A and B has different levels. In other words, the output of XOR gate is log.1 only, if at least one of its inputs is logic 1. (similar to OR gate), but if not logic 1 on both inputs simultaneously (exclusivity).

More details about Logic gates you can find there:

http://en.wikipedia.org/wiki/Logic_gates

And about Karnaugh map you can find informations there

Sorry for poor english:spin:

I know the beauty of a Karnaugh reduction.
But I think if you have that much controllers for an actuator your logic needs a redesign ;).

You have the option to use an Expression controller too which allows much more complex logic operations.

Hey thank you for a great explanation on what they all mean! Really cleared it out for me at least :slight_smile: (and at last)

What the expression controller do? What is his function?

the expression controller can do what the simple controllers can’t. You can enter complex logical expressions. It is not PYthon but a Python like syntax.
It provides access to the sensors states and property values. The expression should result in a True/False value.

E.g. “Delay and prop = 1”
You can use the names of properties and the name of sensors.
as operation you can use the usual logic operations and >, <, =, ==, !=.
Strings should be surrounded by "

I do not use them very often but they can become quite handy (e.g. when checking property values for limits like “timer > 3”)

Heres some examples that I have from tinkering in the game engine. They transition between the idle, walk, and run states without getting stuck. With just WASD, Shift, and some logic bricks it would stay in run as long as W/A/S/D were held even though I let go of shift. I’m pretty sure I could have done it with the logic bricks but it would be huge, messy and probably slow.

(INIDLESTATE) => if ((wKey = True OR aKey = True OR sKey = True OR dKey = True) AND leftShift = True, True, False) => (TOWALKSTATE)
(INWALKSTATE) => if (wKey = False AND aKey = False AND sKey = False AND dKey = False, True, False) => (TOIDLESTATE)
(INWALKSTATE) => if ((wKey = True OR aKey = True OR sKey = True OR dKey = True) AND leftShift = True, True, False) => (TORUNSTATE)
(INRUNSTATE) =>
if (wKey = False AND aKey = False AND sKey = False AND dKey = False, True, False) => (TOIDLESTATE)
(INRUNSTATE) => if ((wKey = True OR aKey = True OR sKey = True OR dKey = True) AND leftShift = False, True, False) => (TOWALKSTATE)

Like Monster said the usual Blender logic applies; and, or, etc. Brackets add variability, in my last example I break it up so that even if I’m holding a WASD key, it will change to WALKSTATE as soon as I let go of shift.
So to clarify a bit if (sensor/equation/property = expectedresult, controllerstateiftrue, controllerstateiffalse)

Just for info:

if x == True: 

is a waste of space and processing time. If you expect boolean values (True/False) check it directly:

if x:

as expression just x (example: Always AND prop)

Logic bricks are NOT slower than a Python controller! The BGE (including the bricks) is already compiled code. Why should it be slower then an call to an Interpreter? Just use whatever fits most.

So instead of “if (wKey = True, True, False)” it would be “if (wKey, True, False)”?

I didn’t mean the logic bricks are slow. Maybe slow was the wrong word. Inefficient might be better. Anyway, I meant that two controllers to determine whether to switch to “idlestate” or “walkstate” is faster than a big-tangled-mess of logic bricks that may not even have worked properly.