Does a Loop of type Conditional respect Wait?

  • Imagine a Wait behaviour is directly connected to the bottom of the Loop Behaviour.

    Is the Loop Behaviour going to respect this Wait Behaviour?

  • @Deeeds No.

  • @Deeeds try it and find out! Stuff like this is easy to make🤷‍♂️

  • @iTap-Development

    Firstly, that's ridiculous.

    This is a tool.

    I shouldn't have to try things like this to find out.

    It's beyond disdainful of users to expect that everything about a tool of even moderate complexity be learnt through osmosis and trial and error. Programming languages of ANY sort (even this simple and retarded) are things of innate intricacy and complexity that needs to be explained.

    This engine and its language border on the barren side of documentation, far past scarce.

    That's rule one for tool creation. Given this engine stems from the source inspiration for Action blocks, it's a peculiarity that the loops don't wait for actions, nor wait for wait actions.

    Secondly, anyone making a programming environment should be able to explain how it works in an introductory documentation that covers how to THINK in the manner of the language and its facilities, so that any ideas can be translated into this new language within its scope of abilities in a conceptual manner before ever embarking on anything.

    How this particularly pair of devices interact should be a high priority in any explanations of the design of a game and interactivity creation tool.

    This is what every single language designer has done before... they write entertaining and incredibly informative introductions to the capabilities, concepts and constructs of their language so new users can get a quick oversight and insight into how/what/why/where/when. Some have even included quite a bit of their historical insights and experiences (wisdom) in with this stuff, explaining their choices, the compromises made and their recommended ways to use their language.

    This is a language! Someone created it, and then forgot to tell people that choose to use it about how and why it is the way it is, let alone explain their choices and articulate their suggestions on how to get the most from something that they know and understand better than anyone else.

    Second rule... when a larger than average percentage of what I've tried has been odd, peculiar, broken, suspect, weird or otherwise not exactly as I might otherwise have experienced or perceived it to be, I'm not sure what I'm seeing is what others are seeing. So I ask if this is true of others.

    You can be sure I've already tried, and am unsure of both what I'm seeing and WHY I'm seeing it.

    Similarly, I've asked about ropes and springs in this engine, because they seem VERY peculiar here. I'd dare say broken, but it doesn't seem anyone else has complained. The documentation fails to understand what damping actually is. This suggests there's something very weird going on and that it might not have been finished being implemented, nor ever tested or used by anyone in a normal way.

    Damping is the force that reduces oscillations of a spring, it is not the force coming back from the other side of a spring relationship. The numbers I've tried suggest something is very wrong with the spring and damper of hyperPad. I can't get any of the responses I'm familiar with from springs, and ropes are weird, too.

    Third rule... leave a trial of breadcrumbs for the future flounderers. if I only try this, learn what I need to know and move on, and don't ask this question, there's no record for everyone else wondering about this same sort of peculiarity. I'm leaving cookie crumbs for the next persons coming through... whenever there's an influx of new users... And I think this is just plain common sense with engines as fundamentally different and targeted at different people (that don't have the benefit of SO and other languages etc). Add to this the lack of documentation and record of experiences, no list of known issues, etc etc... it's just common decency to leave this kind of stuff behind.

  • @Deeeds you seem to like to over complicate things!
    And as for springs, i used them to make a monster truck with suspension one time, and (as the info in the behavior tells you).......
    I spent time testing, and(at least at that time) that is how springs work.

  • @iTap-Development That's not how damping works.

    As I said, damping is the force that reduces oscillation. If it was a force coming back from the other object it would (at the very least) sustain oscillations, if not increase them in the perfectness of a physics simulation.

  • @iTap-Development said in Does a Loop of type Conditional respect Wait?:

    you seem to like to over complicate things!

    Believe it or not, the process I'm talking about is that of reducing complexity in the communication of capability and capacity.

    The larger the audience the more effort must go into the process of making something appealing, generally applicable, insightful, comprehensive and understandable.

    Most successful creative software puts enormous emphasis on this channel of empowerment and engagement with their audiences. Take a look at Codea's documentation on your iPad, for an example of an exemplary effort. That's just a tiny team of guys that made that, and articulated it in that way. Why? Because they realise the empowerment of their users is the most important thing they can provide within their product.

    Similarly, the big companies (think Autodesk as an example) expend incredible effort making their most complex features comprehendible and enjoyable.

Log in to reply