Start Particles Behaviour waits?
-
@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".
-
-
"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.
-
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.
-
What should we rename it to?
-
@Hamed If you're going to take any time to reconsider naming, start at the point where someone decided to name all nodes "behaviours". That's the fundamental flaw.
-
@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.
