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:
But this is what I see in Debug Mode (after 'F' has been pressed):
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.
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.
Develop games in your browser. Powerful, performant & highly capable.
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?