The controllers are the bricks that collect data sent by the sensors. There are eight ways to process the input:
When a sensor is activated it sends out a positive pulse and when it is deactivated it sends out a negative pulse. The controllers’ job is to check and combine these pulses to trigger the proper response.
Controller Comparison table
This table is supposed to give a quick overview of the controller types. The first column, input, represents the number of positive pulses sent from the connected sensors. The following columns represent each controller’s response to those pulses. True meaning the conditions of the controller is fulfilled and the actuators it is connected to will be activated, false meaning the controller’s conditions are not met and nothing will happen. Please consult the sections further down for a more detailed description of each controller.
It is assumed that more than one sensor is connected to the controller. For only one sensor, consult the “All” line.
|Multiple, not all||False||True||False||True||False||True|
The AND controller is the default type when you create a new controller. This is because it is the most common controller and it works well for just pass a sensor directly to an actuator (which cannot be done without a controller).
An AND controller activates the actuators it is connected to only if all the sensors connected to it are positive. If only one sensor is connected to it, the actuators will be activated as soon as the sensor is triggered. If more sensors are connected they all have to be activated at the same time. This is where the name comes from. If there are two sensors, “
sensor1” and “
sensor2”, connected to the controller both
sensor2 have to be active at the same time.
You want to make a menu button. When the player clicks the button he is transferred to the next scene.
On the menu button you set up two Mouse sensors, a Mouse over sensor and a Left button sensor. Both are connected to the same AND controller, which is connected to a Set Scene actuator. This means the player has to both hover the mouse over the menu button and click to get to the next scene.
An OR controller activates the actuators it is connected to if at least one of its sensors is activated. If just one sensor is connected to the controller it will pass on the positive pulse when that sensor is activated, if more sensors are connected, only one of them need to be activated. OR is not exclusive, which means it works like an AND controller too: if all sensors are activated the OR controller will still pass the pulse. XOR controller is an exclusive or controller.
You want both the Esc and the Q keys to quit your game. You set up two Keyboard sensors, one with Esc key and one with Q key. Both are then connected to an OR controller which is connected to an Quit this game actuator. If one of the two sensors is activated the game will then quit.
XOR controller is an Exclusive OR controller. Exclusive means that one, and only one, of the sensors has to be positive. If there is only one sensor connected to the controller it will activate its actuators when that sensor sends a positive pulse. If more sensors are connected the controller will activate its actuators only when one, no matter which, of the sensors is positive. If both sensors are positive, it will not activate.
NAND is short for Not And. In logic, not negates the outcome, Not And is therefore the opposite of an AND controller. An AND controller activates actuators only when all sensors are triggered, a NAND controller does the opposite. Whenever not all the sensors are true, actuators are activated. If only one sensor is connected to the controller, actuators are activated when the sensor is not triggered (behaving like a simple NOT logic gate).
NOR is a Not OR controller, it is the opposite of an OR Controller. A NOR Controller will only activate actuators if none of the sensors are triggered.
XNOR is an Exclusive Not OR controller. While sounding confusing it just has the opposite output of a XOR controller. XNOR activates actuators when more or less than one sensor is triggered.
A confusing controller that’s very functional in special cases.
In this case the Expression controller checks that the sensor's signal, called “
sensor”, is true and that the value of a property called “
prop”. is equal to 1.
See also this page.
The Python controller is a controller that checks the input using a user-programmed script, a.k.a. a Python script or any other file containing Python code. Python controllers have two modes: Script or Module. Both can be written in the text editor and stored inside the .blend file, or they can be external script files.
More information on Python inside BGE can be found here.
The API for Python in the BGE can be found here.
In Script mode, the controller is linked to a script, the whole script will be executed before the logic moves on. Everything in the script will happen at the same frame, if the same value or attribute are changed more than once, only the latest will be visible in the game because of this. If for example the position of an object is changed first to (100.0,100.0,100.0) but later in the same script changed to (0.0,0.0,0.0), then only the (0.0,0.0,0.0) will be visible to the player because the move to (100.0,100.0,100.0) happened on at the same frame.
Since Blender 2.49 the Python module controller was added. Simply choose Module instead of Script on your Python controller drop-down menu. Then you define a function on that module and call that function from the controller. Instead of writing “
myScript.py” on the script edit box, you’ll write “
myModule.myFunc” on the module edit box. This function will run every time the controller is called. But other functions and variables outside of
myFunc’s scope will only run once. This is good for optimizing your code when you want to initiate variables only once then use them later.
The Python module controller supports any number of attributes, this means packages are supported automatically. As well as “
myModule.myFunc” you can do “
myPackage.myModule.myFunc”, nested packages work too, as does method calls on class instances like: “
myPackage.myModule.myInstance.myMethod”. The python controller is passed to the python function as an argument for functions that take one arg.
This allows live editing of scripts, learn more about the Python module controller at:
*Thread http://blenderartists.org/forum/showthread.php?t=156672 *Video http://download.blender.org/apricot/live_bge_edit.ogv