Page MenuHome

Initial Delay option for Always Sensor
Closed, ArchivedPublicPATCH

Description

This patch creates an option to set an initial delay option for the Always Sensor.

The only think is not coded yet is the option in the readfile.c to set the delay in the always sensor to 0 for blender versions older then 2.48.

If I set it now it crashes Blender since my current svn version is 2.47 itself ...

I don't see any reasons to make this a global option for other sensors since the always is generally the only one you need to delay.

Event Timeline

This option is wonderful if one needs to time a sequence of events, without the hassle of timer properties and python scripts.

I'm also sending a patch against the Blender 2.47 branch. For same reasons the other patch doesn't work for the 2.47 branch.

(and I also got away of my attempt of readfile.c changes (since it was not working and crash Blender))

Assigning to ben.

This is really useful functionality. Even though the same functionality can be achieved with timers, this ends up being confusing if you have to set teh timer before a state is entered.

Also, if you want 5+ of these. you end up with too many timers, or abusing timers that were added to be used elsewhere, making the logic bricks hard to understand.

For apricot I have some actuators called something like "abuse_jump_timer".

By contrast, an actuator that has this as a setting can remove the need to 2-5 logic bricks as well as an extra timer.

New patch.

Working here (including the readfile.c)

I'm updating blender subversion to 1, if you want to skip it don't merge the BKE_blender.h file.

But every time you reopen the file you gonna reset the initial delay.

Looking at the patch and my preference would be to have a new "Delay" sensor that has options for Delay and Duration. This could be reset on entering a state when level option is enabled.

A small fix:

In readfile.c:
- if (main->versionfile <= 247 && main->subversionfile < 1) {

+ if (main->versionfile < 247 || (main->versionfile == 247 && main->subversionfile < 1)) {

I also prefer having a new delay sensor with delay and duration parameter and a repeat option. With the repeat option off, there would be two triggers: one positive at the end of the initial delay and one negative at the end of the duration. If the duration is 0, there will be no negative trigger (always on). With the repeat option on, the delay automatically restart at the end of the duration or at the end of the delay if duration is 0.
This way we get a method to generate on/off triggers at precise timee.
With the pulse standard option, multiple positive triggers can be fired during the on duration.
Combined with the state system, the delay sensor would reset when entering the state. The Python API would also allow resetting the sensor at any time.

I prefer this to a modified always sensor. With a new delay sensor, you don't have the problem of converting older files.

strongly agree with benoit's implementation ;)

Dalai, do you have the time to modify the patch along these lines? If not I can take care of it.

first I also strongly agree with benoit's implementation.

My only question is if is better to use the standard pulse implementation to send multiple positive triggers, or to use it as a loop duration.
(e.g. initial delay 10, duration 10, pulse 30 ... that way after the duration we reset the sensor and come back to the initial delay/duration/pulse...).

I don't have time until Tuesday, and this will be a busy week for me. If you (Benoit) can code it, will be a pleasure to take a look at your code and learn how real programmer would implement that :) (i.e. go ahead :D )

About the standard pulse option: it is implemented in the common sensor section and is not under control of each sensor individually. The trouble with the standard pulse option is that the triggers are not precisely timed. The delay sensor with repeat option will be helpful to generate train of ON/OFF pulses with precise timing.

The standard pulse option is still useful to get a burst of ON triggers during a limited time.

I've implemented the delay sensor and commit it in revision 16136

Benoit Bolsee (ben2610) changed the task status from Unknown Status to Unknown Status.Aug 16 2008, 10:51 PM