Start Particles Behaviour waits?

[Deeeds]

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.

[iTap Development]

@Deeeds

Idk if you saw this, but it gives a general idea🤷‍♂️

[Deeeds]

@iTap-Development

Yes, I've seen these.

How did you, by way of example, learn what these things mean?

[iTap Development]

@Deeeds you get the idea once you read a couple.

[Deeeds]

@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]

@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]

@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]

@Deeeds wait, so you weren’t complimenting me?😭 I’m so sad!

Maybe this would make it more obvious?

[Deeeds]

@iTap-Development

"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!

[iTap Development]

@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?

[Murtaza]

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.

[Deeeds]

@Murtaza

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]

What should we rename it to?

[Deeeds]

@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.

[Thecheater887]

@Hamed Play Particles?

I don’t think child behaviors execute on a lopping particle, so this I feel may fit.

[Deeeds]

@Thecheater887 Play suffers much the same problems as Start.

Activate
Initiate
Launch

All 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.