Start Particles Behaviour waits?
-
It seems the Start Particles Behaviour waits until the particle has finished playing until "falling through" to the next behaviours (those underneath it) on a branch are executed.
Is this the case, by design?
If so, I think this should be renamed, at the very least, and some documentation provided that highlights this 'behaviour'.
Similarly, playing a sound seems to do the same thing. Also in need of a documentation and renaming to make this instantly understandable by those both using and considering using these behaviours.
I'd suggest, generally speaking, that every single behaviour that waits be clearly identified as doing so, and every behaviour that doesn't, also be clearly identified as such, so that no user is ever left guessing the rate of flow of execution down a branch.
@Deeeds
Idk if you saw this, but it gives a general ideaš¤·āāļø -
@Deeeds
Idk if you saw this, but it gives a general ideaš¤·āāļø -
Yes, I've seen these.
How did you, by way of example, learn what these things mean?
@Deeeds you get the idea once you read a couple.
-
@Deeeds you get the idea once you read a couple.
@iTap-Development I get that you're of the opinion this is expressed well and that hyperPad is sufficiently clear in its documentation.
I also understand you like using trial and error to discover things.
You value your discernment skills.
Got that, too.
-
@iTap-Development I get that you're of the opinion this is expressed well and that hyperPad is sufficiently clear in its documentation.
I also understand you like using trial and error to discover things.
You value your discernment skills.
Got that, too.
@Deeeds I agree it could be more detailed, but itās not THAT hard to understand.
Yes, I do enjoy trial and error to a degree...that why I spent most of last night making my ālike finderā project. (Yep, I actually fell asleep while using computer today with the mouse in my hand....at least I didnāt āsleep walkā around the computer)
Are you saying I have discernment skills? Uh, thanks. Iām used to yadda yadda yadda laced with criticismš¤£ -
@Deeeds I agree it could be more detailed, but itās not THAT hard to understand.
Yes, I do enjoy trial and error to a degree...that why I spent most of last night making my ālike finderā project. (Yep, I actually fell asleep while using computer today with the mouse in my hand....at least I didnāt āsleep walkā around the computer)
Are you saying I have discernment skills? Uh, thanks. Iām used to yadda yadda yadda laced with criticismš¤£@iTap-Development Everyone has discernment skills. To a degree.
You missed the crucible sentence in my initial post, and the most important word:
"to make this instantly understandable by those both using and considering using these behaviours."
What exists now is barely a reminder service for those already "in the know".
-
@iTap-Development Everyone has discernment skills. To a degree.
You missed the crucible sentence in my initial post, and the most important word:
"to make this instantly understandable by those both using and considering using these behaviours."
What exists now is barely a reminder service for those already "in the know".
@Deeeds wait, so you werenāt complimenting me?š Iām so sad!
Maybe this would make it more obvious?
-
@Deeeds wait, so you werenāt complimenting me?š Iām so sad!
Maybe this would make it more obvious?
"Delay" is non specific, in the extreme.
"Can" does not indicate will.
The timer icon is never defined or otherwise explained in any documentation I've seen.
"Start" does not indicate anything more than a call to.... well, START!
-
"Delay" is non specific, in the extreme.
"Can" does not indicate will.
The timer icon is never defined or otherwise explained in any documentation I've seen.
"Start" does not indicate anything more than a call to.... well, START!
@Deeeds I agree, delay should be defined for the behavior...like, āwhen particle is finishedā.
āCanā what about can?
Time icon seems self explanatory. Especially with description in behavior.
What about start? -
https://hyperpad.zendesk.com/hc/en-us/articles/115003341106-Start-Particles
"This behavior will trigger an event after a delay (when the particle is done playing it's iteration)."
The in-app references are for quick references. On our manual we go into a little more detail.
First pass is matching the behaviour reference (and including some extra info)
second pass is additional info,
third pass is adding tutorials/samples for each behaviour.We're currently on the first pass.
-
https://hyperpad.zendesk.com/hc/en-us/articles/115003341106-Start-Particles
"This behavior will trigger an event after a delay (when the particle is done playing it's iteration)."
The in-app references are for quick references. On our manual we go into a little more detail.
First pass is matching the behaviour reference (and including some extra info)
second pass is additional info,
third pass is adding tutorials/samples for each behaviour.We're currently on the first pass.
This behavior will trigger an event after a delay (when the particle is done playing it's iteration).
Removing ambiguities (a first draft):
This behaviour triggers subsequent behaviours only on completion of its particle system's duration.
// One problem: a particle system's 'duration' can be infinite, hence the need for "only". If the Start Behaviour for infinite duration particle systems flow straight through, that's something else that needs to be described.
The naming problem is still an issue. Yes, it does 'start' a particle system, but it also loads it and places it and plays it in entirety (without pause or speed controls), and waits for the duration of the particle system's duration. So "start" is not nearly the best word choice, since it conveys the idea that this behaviour simply "starts" the particle system and then continues on down the branch.
It also adds the mental capacity for consideration of stop, pause fastforward and reverse, since the word 'start' comes with builtin context of its own. None of these things are available for particle systems, further removing "start" from being an ideal word choice.
Whatever word is used should be congruent with whatever word is used/chosen to load, activate and wait for an audio file, since these behaviours behave in a similar manner, and perform similar operations.
Since both of these behaviours suffer from a caching issue the first time they're used (loading and then playing their respective particle system or sound on first call), there's that to consider, too.
-
@Hamed Play Particles?
I donāt think child behaviors execute on a lopping particle, so this I feel may fit.
-
@Hamed Play Particles?
I donāt think child behaviors execute on a lopping particle, so this I feel may fit.
@Thecheater887 Play suffers much the same problems as Start.
Activate
Initiate
LaunchAll suffer the same problem.
They convey a false sense of an instruction having been sent and that's it, that's all.
But that's not it, not all and fails to come close to conveying the extent of what's going on, and what this behaviour is doing, and will do.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better š
Register Login