What does a controller do when it recieves NO pulse from a sensor?

The documentation on logic bricks is not very clear to me. A sensor can send either a positive pulse, a negative pulse, or no pulse to a controller. What happens when a sensor sends no pulse? Is it treated as a negative pulse? Or does the controller ignore it completely? Thank you.

Hi,
Controllers evaluate TRUE or FALSE for every logic tick that a sensor is connected… no pulse would be the same as a negative pulse, or FALSE, unless the output is inverted…

So let me get this straight. If a controller receives any pulse from any sensor(positive or negative), it is triggered and executes. If it receives no pulse from any sensor, it is not triggered. When a controller is triggered, it will evaluate the sensors that are connected to it. For the purpose of the binary logic controllers(AND, OR etc), a sensor that has not sent a pulse during that logic tick is considered to be False(unless the output is inverted, in which case it will be considered True). A sensor that has sent a negative pulse is also considered to be False. A sensor that has sent a positive pulse will be considered True. Am I getting this right? It’s quite confusing to me.

This is correct. It is also important to note that when a sensor fires, it sends both a positive pulse and a negative pulse.

For example: I have a keyboard sensor mapped to the spacekey and I have it set to tap mode (only fires once, not continuously) attached to a controller. I press the spacekey during runtime. The sensor sends two pulses to the controller: a positive and a negative. Therefore, the controller will technically run twice. This isn’t as important to note in pure logic brick setups but when/if you are dealing with python.

I did not say they evaluate whether or not a sensor is connected…
I guess i worded it wrong, but a controller will not recieve anything if there is no sensor attached to it…

I did not want to offend you. I just want to make this clear as it is really important to understand what happens.

You are right a controller can only be triggered by connected sensors.

Laser Blaster you are mostly right. The easiest way to understand this is to keep status and trigger separate.

A sensor has a status that is evaluated at each frame. The status can be True or False. So at any given time the Sensor is True or False.

A sensor triggers a controller when:
A) the status of the sensor changes (True to False or False to True)
B) a Pulse mode is active and the according Status matches

This is very basic and does not match all configurations. As said, please read the above guide for more details.

A controller does not care the status of the sensors to be executed. It only cares it it gets triggered.

The Sensor status takes place on the result of the controller. There are three results:
A) Activation signal
B) Deactivation signal
C) No signal

The exception is the Python controller that can act as actuator too.

I would just add that don’t assume that no pulse and false pulse = the same thing.

A False state is just as meaningful and useable as a True state.
No pulse might cause logic to seem to be behaving like you want it too, but its kinda like a dead state.

An ‘Always’ sensors by default will fire only once and falls into a dead state unless manipulated with pulses or logic.
A ‘Keyboard’ sensor set to the “W” key is always True or False , and False doesnt mean no pulse because linked to a ‘NAND’ controller it gives us logic that we would only get by creating another sensor that was “W” inverted.

Thanks, I get it now.

Monster, your suggestion to mentally separate the trigger from the sensor status was very helpful. You might consider editing your guide to the GameLoop to include what you’ve told me in this thread. I think it would probably be helpful to others, too.

In your resources you have a link to a wiki page that explains sensor pulses; it mentions that sensors can send both positive and negative pulses, which I find to be a confusing way to explain it. Since it’s open for editing, I’ll take a shot at improving it with what you’ve told me. Eh… on second thought, I don’t really feel confident in changing that wiki page. Perhaps you could update it? I just thought you might like some feedback on your resources, you don’t have to if you don’t want to.

Laser blaster you are right the wiki does not make it clear these are two different things.

BTW. I prepared the wiki page based on a game engine book. Good feedback!

… changed in Wiki