[Bf-committers] Init Delay for BGE Sensors, ideas and support pls

[Dalai Felinto]

Campbell,
as you know the patch in the track is already working fine as an
initial delay to the always sensor.
http://projects.blender.org/tracker/?func=detail&atid=127&aid=17472&group_id=9

So far I'm thinking about your idea of replace it with a delay sensor.
What kind of delay sensor does Apricot need?

What I thought is two options:
- Initial Delay
- Duration

If you want to make it a loop you just trigger it. If you select a
pulse bigger then InitialDelay+Duration you have a kind of post-delay.
That way you can't control how many loops you will have but you can
make it looping.

How about that? I was planning to code it only next week (Tuesday). It
will be simple since most of the code is already done and working.
If Apricot need it early let me know.

Dalai
http://blenderecia.orgfree.com


2008/8/11 Campbell Barton <ideasman42 at gmail.com>:
> A problem with using option 2,
> There are a number of cases where I have wanted to change a state and
> have one of the sensors wait a while before starting.
> Say your using a timer and you want it to be 1.0 before activating a sensor.
> Setting the timer to 0.0 on entering the state will not work, no
> matter what order its done in the stack.
> The timer needs to be set before entering the state, This gets tedious
> if there are multiple entry points for the state.
>
> Heres a blendfile showing the problem.
> http://members.optus.net/~cjbarton/timer_problem.blend
>
> options 1 and 3 would work fine but seem obscure.
>
> The nice thing about an always delay is its very obvious whats
> happening, no need to check elsewhere to see in what state a timer is
> set. or look inside scripts.
>
> - Cam
>
> On Sat, Jul 26, 2008 at 9:15 PM, Benoit Bolsee <benoit.bolsee at online.be> wrote:
>> Hi,
>>
>> Adding a delay option to the always sensor is an interesting feature but
>> not strictly needed. You can achieve the sequencial result that you're
>> looking for in various way:
>> 1) use sequential states to activate scripts in sequence: each script
>> will set the state to the next in the sequence.
>> 2) use a timer property and several property sensors set on increasing
>> values of the timer property: they will trigger the controllers
>> sequentially at well specified moments.
>> 3) use a global counter in GameLogic: the first script checks that the
>> counter is 0 et set it to 1 after executing, the second script checks
>> that the counter is 1 before executing and set it to 2, etc. For this to
>> work you will need a single always sensor in pulse mode that triggers
>> all the controllers.
>> 4) if you have multiple scripts that must run in sequence, why not
>> having one large script that will do the all the work in sequence.
>>
>> /benoit
>>
>> -----Original Message-----
>> Date: Fri, 25 Jul 2008 19:09:45 -0700
>> From: "Dalai Felinto" <dfelinto at gmail.com>
>> Subject: [Bf-committers] Init Delay for BGE Sensors, ideas and support
>>        pls
>> To: "bf-blender developers" <bf-committers at blender.org>
>> Cc: Mike Pan <madonions at gmail.com>
>> Message-ID:
>>        <b8ebc13a0807251909y57f5abbdp251776268fa895ef at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hi.
>>
>> We are using different sensors from different objects to initialize and
>> run some Python scripts in BGE. Sometimes we need a specific script
>> initialization order, and we are having some troubles with the way
>> Blender handle it.
>>
>> One idea we have so far was to implement an option in the Always Sensor
>> to delay the beginning of the scripts in a specific number of pulses.
>>
>> Today I start coding it, and so far I have the GUI working, and I'm able
>> to save/read Blender files with the settings of the Always Sensor. So
>> far I can skip the first pulse for the AlwaysSensor, and make it runs
>> only after the next trigger pulse.
>>
>> Beside that I realize that I can implement a counter system in the
>> SCA_AlwaysEventManager.cpp to create a delay system for all individual
>> Sensors.
>>
>> So I have three questions:
>>
>> 1) It is better to have a generic init delay system for all Sensors or
>> it is useful only for the Always Sensor?
>>
>> 2) I'm not sure how can I delay it only for the AlwaysSensor. Apparently
>> I can't configure it only changing the SCA_AlwaysSensor.cpp.
>>    Initially I can think in two ways:
>>      a) code the AlwaysEventManager to check if the event is Always and
>> if it is try to delay it.
>>      b) add an option in SCA_EventManager.cpp to receive as an input
>> (int or short) in some of its methods and use it to add the initial
>> delay to the frames.
>>
>> 3) I'm not sure how the EventManager works. Does anyone have any
>> tips/suggestions/comments to help me in this matter, please ...
>>
>>
>>
>> The patch so far to implement the GUI option for the AlwaysSensor
>> http://pasteall.org/1722/cpp . The patch so far to implement the GUI for
>> the Always Sensor + a general delay for all sensors (the delay came from
>> a inpu in the console) - http://pasteall.org/1723/cpp
>>
>>
>> Thanks for your time and assistance.
>>
>> Best regards,
>> Dalai Felinto
>>
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>