Else if is broken
-
@Aidan-Oxley That's not how it works. If you set up anything with a duration in a branch, you'll see that it jumps from left to right as fast as it possibly can, only downward movement through a branch is stalled by the durations.
Similarly, anything that takes a long time to create a result isn't worried about, either... I think.
I'm pretty sure that calls across (left to right) are blind, as fast as can be done... so far as I can tell.
-
@Deeeds That’s different. I’m talking about behaviours with no duration at all. As soon as they have a duration and behaviours connected underneath them, stuff changes. But still, I tested it, and it works. Idk about the more power hungry behaviours, maybe we should test that out too. But I’ve never ever had a behaviour to the right in a row activate before one to the left finishes (other than behaviours that have a duration).
-
@Aidan-Oxley I don't think so. I think you're just getting lucky, that the conditionals are happening fast enough (in this case) to get to the behaviour off before calling your Else behaviour. Push this hard, 100x, with others things happening, and I'm reasonably sure that you're going to get a few false elses firing...
@hamed any chance of this? Or do you have some kind of filtering that's making sure branches complete before moving from left to right?
-
@Deeeds Getting lucky? I’ve used hyperPad for like 5 years, made hyperPad super laggy, done all sorts of stuff, behaviours ALWAYS execute left to right.
-
@Aidan-Oxley I don't doubt they execute left to right, I'm doubting that they wait for their branch to finish before going further right to make the next call.
Are you 100% sure?
As to making it laggy... I can do that with ease. I think anyone can ;)
-
@Deeeds Left to right, completing the whole branch before moving on to the right. Unless the branch has some sort of intentional duration. It worked in my test project, that’s enough to convince me. Could try put some loops in there and see what happens.
-
Just tried this:
HyperPad froze for a second to do the Loop. The label turned out to be 2, so it did wait for the first (left) branch to finish before moving to the next (right). -
@Aidan-Oxley
You're officially qualified as a programmer.
Finding the cheapest, quickest, easiest, narrowest way to prove a hypothesis; that's exactly what programmers do. Every.single.time...
Drop the loop into a node one lower. Call a (for example) behaviour bundle first, that then calls the loop.
If that works as you expected, then drop the behaviour bundle's calling into a conditional (if) that chooses to call the bundle based on external criteria.
If that's still performing as you expect, then nest that inside something else, that does something else.
Keep going until your find something that breaks your expected result and hypothesis.
Then make a new hypothesis, and begin thoroughly testing that. And consider yourself to have graduated from programmer to coder.
-
@Deeeds I agree that elseif is super useful....but @Aidan-Oxley is right, if you really have to, you can get by without them in many situations.
Not ideal, but works. -
@Deeeds I’ve had else’s stop working too....I think it happened when I duplicated and rearranged ifs and elseifs a lot of times.
But I’m looking froward to their updated else’s! -
Behaviours are depth first. ie, it will finish the chain (unless it hits a duration behaviour) then go on to its sibling to the right. @Deeeds can you please stop arguing for the sake of arguing? Thanks.
-
@Hamed Where is this in the docs?
-
Its not in there. Should be but we overlooked it sorry.
-
@Hamed It is not for the sake of arguing.
it is to ascertain something as fact because I don't want to waste more time guessing what's not documented, and navigating around bugs and other things that are unknown and speculations.
Just like you, my time has a value.
-
Well until our documentation catches up to usable standards, the guys and girls on this forum know what they're talking about. I trust them, you should too. If something is blatantly wrong, I'll jump in and correct it.
-
@Hamed yet I've noticed one person, in particular, making one false claim after another, often for the sake of arguing (with me).
I will continue to question any claims to my satisfaction, because I've spent an inordinate amount of time working around bugs and undocumented oddities and unknowns.
Don't really know how to add up the time spent discovering the incapacity of the graphics facilities (for example) of hyperPad, and then attempting to work around them, only to find that the next choice doesn't work, either. And so on...
You've not even bothered to reply, at all, to those threads. So I presume nothing is being done about the sprite sequence importing, sprite sheet importing, plist importing for sprite sheets, etc etc...
-
Focusing on the huge bug list first then will tackle features.
-
@Hamed I'm not asking about new features. I'm asking about sprites... any capacity to get sprites into the engine, at all.
-
Sometimes we have to remove features when they're really broken. Scrap it and try again. We will get spritesheet importing working again asap.
-
@Hamed As I've said somewhere else before, sprite sequences would be a better stop gap, if they're easier. As I imagine they are... you can do your own packing, however you like, without needing to fiddle with the gazillion ways texture packer might have done something. And you can do a very rudimentary packing, too.
