Does Behaviour Off not work instantly with duration Behaviours?
-
@Deeeds Looks like duration behaviours like to finish what they are doing even after they are spurned off, but I do know one thing that can stop/interrupt them: running another duration behaviour on the object while the previous is still running.
E.g for stopping a set colour duration instantly:
Instead of turning Set Colour off, add a Get Colour and then Set Colour to the Get Colour with a 0s duration.EDIT: Did some testing and this actually doesn’t work. Set colour really wants to finish what it’s doing, but I found a different way to stop it. Disabling the object that is changing colour over a duration will stop it from continuing to set colour. After disabling it, I think you could just re enable it instantly (just don’t have the Enable Object inside the object being disabled).
-
Here’s a weird way to do it....you could have the duration be from a box container(or value of your choice), then when you want to interrupt, have your “interrupt event” set the duration to 0, get the color and retrigger the set color with it, then set the duration back to whatever it was before.
-
Behavior on doesn’t (seme) to Work after a wait behavior if it means anything.
-
@Aidan-Oxley these are spawned objects, meaning I don’t know how to control them externally with a disable object, or re-enable, because there’s no references and a disabled object can’t receive messages.
-
@iTap-Development I've just tried this. It doesn't work.
I've also tried inserting a stop behaviour, and using an execute behaviour instead of a behaviour on. None of them make a difference.
I'm using Set Input Fields to update the value in the Box Container, so they should be instant.
I think it's practically impossible to interrupt a Set Colour with duration.
-
@Deeeds You could try putting all the spawned objects in a tag, then just whenever they disable themselves they trigger another object to enable the tag again (with restart behaviours turned off), shouldn’t make any difference to those already enabled.
-
Lemme do some more testing, if I come up with something I’ll post a test project link.
-
@Thecheater887 Behaviour On, for Set Colour, doesn't seem to work even without having a wait behaviour anywhere in the mix. I have to turn it on, and then fire an Execute Behaviour to get it to work.
Making a lie out of this bit of the documentation:
"Behaviour On: Enable any disabled behaviour on your screen and cause it to execute immediately".
-
@Deeeds if you have “skip events” (I think that’s what the toggle is called) on, it will execute immediately.
-
@iTap-Development You surmise.
Not true.
-
@Aidan-Oxley said in Does Behaviour Off not work instantly with duration Behaviours?:
@Deeeds You could try putting all the spawned objects in a tag, then just whenever they disable themselves they trigger another object to enable the tag again (with restart behaviours turned off), shouldn’t make any difference to those already enabled.
I’m pretty sure turning on a behavior that’s already on will actually trigger it, just like an execute behavior.(as long as skip events is on, or it’s not connected under other behaviors)
-
@iTap-Development Read up a little...
Behaviour On, for Set Colour, doesn't seem to work even without having a wait behaviour anywhere in the mix. I have to turn it on, and then fire an Execute Behaviour to get it to work.
Making a lie out of this bit of the documentation:
"Behaviour On: Enable any disabled behaviour on your screen and cause it to execute immediately". -
Look at the screenshot at the start of this thread:
https://forum.hyperpad.com/topic/763/understanding-behaviour-priority
or it’s not connected under other behaviors
-
@Deeeds said in Does Behaviour Off not work instantly with duration Behaviours?:
Making a lie out of this bit of the documentation:
"Behaviour On: Enable any disabled behaviour on your screen and cause it to execute immediately".
In reply to this statement. http://bit.ly/2iFDIDv
Surmise? Surprise! -
@iTap-Development Have you read above? Stayed up on the thread this extends from?
-
@Deeeds I made the project because of this statement... “Making a lie out of this bit of the documentation:
"Behaviour On: Enable any disabled behaviour on your screen and cause it to execute immediately”.Have you played the project?
-
This looks like a bug. If you guys find more behaviours that don't turn off immediately, Make a new thread with a list of them and please just reply with another behaviour that doesn't turn off immediately.
-
@Hamed A holistic approach to this is that all behaviours be interruptible, from anywhere, anyhow, anytime, on any given object.
There's a better way than the current "restart on restart of same behaviour" approach, and that's an object specific and behaviour type consideration, that instantly overrides any behaviours of the same type on any object.
An example, so that this can make some sense:
A rollover, in a game, that scores when the player's character moves over it, and lights up, has four basic states
-
Untouched
-
Touched
-
Touching
-
TouchEnded
Due to the lack of states and a bunch of other issues (no referencing or addressability of objects), the best way (that I've found) is to communicate with the rollovers via Broadcast and Receive.
This is particularly true if spawning a dozen or more rollovers into positions within the game world.
A message is sent to the rollover, from the hero's contact filtering, to say the touch has ended, and the rollover begins an animation to show that it's no longer being touched. This animation might be made up of a scaling effect, a couple of Set Colour changes, maybe even a blend mode change, and a slight positional "hop" and other visual "effects", perhaps its own sound etc etc... All of which are created to get around the lack of spritesheets and bitmap fonts...
However, having left the rollover behind, the hero character could turn around and reTouch the rollover while the TouchEnded animations are still running. Meaning that all of these animations and events need to instantly stop so that the Touched Animations can state and be instantly entered, in their right initial states, visually correctly.
This, currently, can't be done because Set Colour, amongst others, aren't interruptible.
Similarly, the visual effects that mark the touching state need to be instantly torn down and interrupted when the player's character moves off the rollover, from touching to TouchEnded.
If a given type of behaviour is evoked on an object, anywhere, anyhow, anytime, all behaviours of the same type (on that object) instantly stop, and the new behaviour starts from there. This is the most basic sort of interruptibility, and what I'd assumed would happen.
Because there's a lack of states in hyperPad, this most basic type is the most egalitarian way to provide interruptibility.
-
-
@iTap-Development Don't be ridiculous. Stay in context. Please.
-
@Deeeds @iTap-Development Would you two bury the hatchet? I hate having to duck every time the two of you are in a thread together.
