What happens in this Tick here?

I was fairly sure I understood everything now, the flow and order in what things happen in a Tick in the Event List.

Today I was using the Debugger, because of an unwanted result, to see if I could find something there, without any real clue. But I noticed something else, that I found strange.

First let me give You the Events (in order, top to bottom, as they appear in the Event List, excluding unrelated Events inbetween) related to this:

If MouseKeyboard PressButton 'F' -> Set Attack = 1

---------ELSE------------------- -> Set Attack = 0

If Attack = 1 -> Set Animation 'Attack'

If AnimationPlaying 'Attack' -> Set IgnoreInput = 1

If AnimationFinished 'Attack' -> Set IgnoreInput = 0

(IgnoreInput just ignores input for movement)

Now in theory what I thought should happen (After pressing 'F') is this:

Tick 1:

• During the duration of this Tick, Attack = 1.
• Animation is set to 'Attack'.
• Now I don't know about this for sure, but since Animation has been set to 'Attack' in this Tick above, IgnoreInput should already be = 1, unless AnimationPlaying is only registered for the next Tick, when it has actually been finished rendering. (The AttackAnimation is only 1 Frame right now, placeholder)

Tick 2:

• IgnoreInput = 1 or 0, Depending on how Animation is registered by the program, as I said above.
• We see the AttackAnimation for the 1 frame it has.

But this is what I see in Debug Mode (after 'F' has been pressed):

• Attack = 1
• Attack = 0; IgnoreInput = 1
• Attack = 0; IgnoreInput = 0; Animation = Attack

After pressing 'F', Attack is first set to 1.

Then exactly as Attack = 0, IgnoreInput = 1.

Then exactly as IgnoreInput = 0, we see the Animation.

Could someone please explain to me how and in what order the Events are being read and executed and values assigned?

Thank You very much.

EDIT:

Weird, I just tried to replicate this behaviour with the Event Flow I described, in a new .cap. Now it behaves exactly as I thought. It must have something to do with other Events interfering then.

Ah, good to see your edit. I was just about to tell you I couldn't reproduce it.

Btw, when checking visuals and values using the debugger, especially when using a very low fixed frame rate (like 1 fps), you might get confused because of the parallel processing.

What you see is the result of the tick before, not the actual tick. While the graphic card processes the results of tick n, sent by the cpu, the cpu processes tick n + 1.

Okay, I found out what was happening.

It's a similar or the same bug I had a good while before, and I think I reported too.

One of the Events I used to trigger the SetAnimation to Attack, had an OR condition sandwiched in the middle, and it was in a Group.

When I moved the whole Event out of the Group and into the main Event List, it worked exactly as expected. Very weird behaviour though. I mean with the Bug.

And thanks for Your reply, tulamide. Yes, I was thinking about exactly that, how the previous Events' frame is being rendered in the present processing and what delays there could be. But knowing all that made it even more weird. How it could even set the Animation to 'Attack?, and IgnoreInput to 1, while Attack is playing, when that is only possible while Attack = 1. And since Attack only has 1 Frame, how could IgnoreInput be set to 1, when Attack = 0?