Understanding Behaviour Priority...
-
In the following example, I'm curious, does hyperPad interrupt the sequence of behaviours if another message is received to activate the top most behaviour, and start again without finishing?
Or does it try to finish each run through of any given sequence of behaviours regardless of re-activations?
Is this (whatever the answer is) by design?
-
It does not interrupt the children until the child gets triggered again.
If Set Color 785 is 0.5 seconds in, and 784 gets called again, 785 will get restarted at 1.5 seconds. So it will not complete the first iteration.
This is by design.
-
@Hamed said in Understanding Behaviour Priority...:
It does not interrupt the children until the child gets triggered again.
If Set Color 785 is 0.5 seconds in, and 784 gets called again, 785 will get restarted at 1.5 seconds. So it will not complete the first iteration.
This is by design.
@Hamed Sorry, I need to be very clear about this, as it's influencing a stack of things I'm doing.
Should this line:
It does not interrupt the children until the child gets triggered again.
be:
It does not interrupt the children until the parent gets triggered again.
???
The second time through, you're saying that the partially completed 785 triggers, but with a reduced timespan based on how much it got through the last time... why is this?
Why don't they all start over? And if you're crimping time from a partially completed Behaviour, why aren't the previously completed Behaviours skipped altogether in subsequent restarts?
-
@Deeeds when a behaviour with a duration activates while it is running it will get interrupted and restart.
It can run multiple parts of the branch at once, for example activating 784 while 786 is running will not interrupt it immediately. However, if 785 finishes before 786 does it will reach 786 again and interrupt it.
Basically, a single behaviour with a duration can't be running multiple times at once, but multiple different behaviours can be.
-
@Jack8680 argh. Thank you!!!
This definitely explains what was happening to a series of branches I was treating as "action sequences" and seeing them get out-of-sync issues I couldn't otherwise explain.
THANK YOU!!!
Is there any way to ensure that a branch of behaviours can be treated as a whole sequence, so any calling of the first behaviour in the branch stops the entire branch sequence (and any one of its active members), right then and there?
-
@Deeeds I think the only way to stop an already running behaviour is to turn them all off. I had this exact same problem with a sequence of attacks running on my player.
Maybe a nice feature would be the option of a dynamic behaviour off so we can loop through a list of behaviours to turn them off.
-
@Jack8680 I'll find some time to map out how a basic animation editor might look, with blocks for sequencing, grouping and repeating. Solve all the problems at once.
-
@Hamed Does this also mean that in this situation, all on the same object:
Message Receiver XYZ -> Set Colour (to blue) duration 5 seconds
2 seconds later...
Message Receiver ABC -> Set Colour (to red) duration 1 second
On the same object, the second Set Colour doesn't ever get activated, because it's not permitted to cutoff or otherwise interrupt the other first Set Colour?
If so, how do I interrupt this first Set Colour?
How do I interrupt it if I don't know what it's called, because there's (let's say) 5 different random set colours on the same object, and whatever one is currently running, I'd like to interrupt it?
-
@Jack8680 I just tried this. But then can't turn them back on without them all running at that moment when I turn them back on... I just want to put them into a standby mode, because if I have a tree turning them on, that can't be turned off... without turning them all off. And on and on it goes. An endless loop just to get interruptible animations.
FUCK!!!!!!!!!!!!!!!!
-
@Deeeds can you use behavior on, with the skip events toggle off?
-
@iTap-Development No. It isn't possible to get them to stop and stay in sync with other objects. So it's not possible to restart them, and keep sync, either.
These are all workarounds for the lack of sprite sheets, the lack of bitmap fonts and the lack of image swap transitions... oh, and the lack of referencing and addressable instances.
