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:
- 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)
- 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.
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.