Blender Game Engine - Trigger something to happen in the future

Question

I'm somewhat new to BGE. I've read some doco and played around a bit.

What I want to do is have an action trigger an event that happens in the future. The task I was working on was to make a button that moved inwards a little when it was clicked (pressed), but then it popped back up again some time later.

I have no trouble moving the button-block down when activated by the mouse sensor, but I'm not sure how to get the button to move back up again (i.e.: "un-press" itself) after a short time.

The common form of this problem, is how to trigger something to happen in the future? For example: how does one make an automatic door that opens when triggered, but then closes itself a few seconds later?

So far I've looked at all sorts of logic blocks, and python programming. I'd really like a "Delay Controller" so I can catch the sensor-action, delay for /N/ frames in the controller, then invoke the actuator/whatever. Using this idea, I could trigger both the door opening and closing (with delay) at the same time.

The only way I can think to do this is to run a python program every frame and check on counters or the system clock, etc. But this doesn't feel like the correct approach for BGE.

Answer 1

There are many ways to implement "event in future".

The basic concept is you start something that takes a while and triggers an event later.

Animation based

This is pretty common as it starts a process and it presents progress to the audience. The animation is the cause rather than the effect.

When you play the animation with the action actuator (and it does not run in an endless loop) you can measure the end with the actuator sensor.

Be aware it measures when an actuator is active, but you want to know the opposite. Also keep in mind any actuator will start deactivated that will trigger the sensor too.

Counting frames

This is also a common practice. It provides you full control when to start and when to end. Unfortunately you have to implement a continuous process to run this behavior (not really efficient).

The implementation is simple:

Define a property with a start value e.g. 0

You start the delay by setting a value above zero (e.g. 10 to measure 10 frames).

You observe this property with a property sensor. When the property is above zero you decrement it by 1 at each single frame [True Level Triggering]. When the property reaches zero the time is up and you trigger your event (e.g. by sending a message).

Automatic property

You can use a timer property. The timer property counts the seconds automatically.

You start the delay by setting a value below zero (e.g. -10 to measure 10 seconds).

You observe the timer property with a property sensor. When the property gets above zero the time is up and you trigger your event (e.g. by sending a message).

Be aware the timer property will continue counting and never stop. You can set any value at any time (e.g. to start another delay).

Delay sensor

This is not so common as there is a small but important obstacle a lot of BGE users stumble across. You need to know how sensors work.

The delay sensor start measuring when the object gets created!

This means it is perfectly fine to measure a time frame since scene start.

It is also fine to add the object and get a delayed event after creation. This way you can establish a sort of timer, just b adding such an object.

But there is more:

The delay sensor also pops when you switch the state of the build-in state machine (from a state without the delay sensor to a state with state sensor).

You start with a state without the delay sensor. You start measure by switching to a state with delay sensor.

You measure the delay with the delay sensor.