only one action when event loops - why does order matter?

[Volnaiskra]

This works:



But this doesn't work (hitting tab does nothing):



I don't understand why. I would have thought they should both work identically. Is this a bug, or is there some logic at work that I'm failing to understand?

[Pixelthief]

MMF2 will not repeat the action if that condition was reached in the previous event cycle. Whenever MMF2 reaches an event, it reads the conditions from top to bottom, and if any return 'false', it stops reading further conditions. So the "only one action when event loops" returns false if that condition was reached in the previous frame, not if the whole event was true and executed- if you want it to only check for execution of the event, you can logically put it at the very bottom of the conditions.

With the way you structured your code, in the top example, it will first check "Upon pressing Tab". This is only true when tab is first pressed on a downstroke, and not when held. On every other cycle when tab is not being pressed, or is being held, it will return false, so MMF2 never reads past that condition and checks the loop clause. In the bottom example on the other hand, every cycle it reads through the event editor, it will first read the "only one action when event loops", and theres nothing to stop it from reading that besides maybe event groups being open/closed and frame changes. Thus that line of code will only be active for the first cycle of a frame, and won't work for every check afterwards

[mobichan]

So you are saying it is pointless to use an "upon key pressed" condition with "only one action when event loops" after it? That functionality is already part of the logic of "upon key pressed" anyway.

[danworth]

I would say yes there would be no point adding it, as upon pressing a key would only be triggered 1 time each key press.

Volnaiskra are you trying to prevent the object from being made invisible when it has already been made invisible? You could add if visible to the condition. However I wonder if that would actually have more overhead than just making it invisible regardless of its state. In the same way that in C:

if (value > 0) value = 0; has more overhead than just
value = 0;

I remember when I made a project in MMF1.2 years ago and had an event that would make something invisible when overlapping. It crippled the game so had to check for the visibility before making it invisible. However when I moved the project to MMF2.0 It worked fine without the visibility check so maybe events like this checks are performed for you by the runtime. Making it actually better just having its visibility set on each press (at an optimisation point of view). I guess the CT Dev's can confirm this.

[Volnaiskra]

So you are saying it is pointless to use an "upon key pressed" condition with "only one action when event loops" after it?

I wasn't saying that at all. My question was about why the order of those two conditions - in otherwise identical events - makes such a difference.

So the "only one action when event loops" returns false if that condition was reached in the previous frame, not if the whole event was true and executed

Thanks for elucidating that. I must say I find it hard to comprehend why it would work that way though. It just seems....crazy. At the very least, it's poorly named. Surely almost everyone would assume that it works the latter way, rather than just checking to see whether that one single condition (and only that single condition) was read. Especially since it has both the words "action" and "event" in the name, and doesn't even mention "condition".

.....However......, I'm not sure what you're saying is true..........because if I'm understanding you correctly (and I might not be!) then shouldn't this:

.......it will first read the "only one action when event loops.........Thus that line of code will only be active for the first cycle of a frame, and won't work for every check afterwards

apply equally to the following code?



And yet the above code works fine. It successfully cycles through that code 98 times (each time checking the "only one action when event loops" condition and finding it negative), and then on the 99th, it runs through it again, and executes it fully (I can confirm that the Active object disappears off the screen at that point)

[mobichan]

My reply was aimed at Pixelthief, not you, Volnaiskra. I agree that some combinations of things in MMF really are confusing, especially when they either are redundant (as in this case) or simply incompatible but are allowed to exist together. My OCD has always forced me to put the "Only one action when event loops" condition as the last condition of an event line, so I guess I was just lucky to have done it the right way. And I do mean "right" way when I can't really see why anyone would want the other behavior.

[Pixelthief]

Hrmm yeah maybe that doesn't do what I thought it does
I can confirm that replacing the 'upon pressing' with a 'while pressed' changes the behavior, so I can only assume its something to do with the immediate condition ordering being different

[KLiK-iT]

I agree,.I always put "Only one action when event loops" condition last. It's always worked doing it that way for me.

[nivram]

I have also put "Only one action when event loops" condition last, for as long as I've used the product.

Marv

[Volnaiskra]

@mobichan: Sorry for misunderstanding your post

Hrmm yeah maybe that doesn't do what I thought it does

On further reflection, I think what you were previously describing was, in essence, the behaviour of the "Run this event once" condition. As far as I can tell, that works exactly as you were describing the "only one action when event loops" as working.

My OCD has always forced me to put the "Only one action when event loops" condition as the last condition of an event line

I agree,.I always put "Only one action when event loops" condition last. It's always worked doing it that way for me.

I have also put "Only one action when event loops" condition last, for as long as I've used the product.

Well, I guess this is the safest route to take. But I don't like it at all. Judging by these comments, and if I may be so presumptuous, even those of you who put it at the end don't fully know why you do it, other than because it just felt right to you and that's how you've always done it. There doesn't seem to be any easily discernible logic to it, but rather it's just something we're supposed to remember and do (without the software ever explicitly telling us about it, or even hinting at it), even if it doesn't fully make sense to us.

I guess if this only affects the combination of "upon pressing a key" and "Only once action when event loops" then it doesn't really matter, since - as people have rightly pointed out - the two are redundant when together. But it makes me wonder if there are other hidden no-go combinations like that out there. I don't like that every time I add a condition to an event that has an existing "only once action when event loops" in it, I now have to remember to move it back to the bottom of the order, lest my code stop working for some unclear reason.