"Else condition" not working with Custom dt pause toggle

I'm working on setting up a custom pause feature built around tracking current and past dt values. This why I will have an easier time - I believe - at controlling what I want paused and what I want to continue to function. (I am aware that there is a way to manipulate the individual timescales of objects, but I seem to remember a long time ago that this did not serve my purposes...it's a bit beside the point at the moment, I think.)

The issue I'm having right now is that the Else condition event line seems to be activating even when the boolean test condition above it is true. What should be happening is that event line 6 tests if the condition is true. If it's true, it skips event line 8. If event line 6 is false, it skips to event line 8 and runs the Else-condition actions. It's one OR the other.

But because of the sub-event at event line 7, the sudden change of the boolean value seems to prematurely trigger the Else condition into thinking that event line 6 was false after all. Because the Else checks for the true or false outcome of the conditions laid out in the previous parent event line I would THINK that the change in the value of the boolean in a sub-event wouldn't matter.

Am I missing something?

Your logic is backwards. On-pressed is a trigger - it's always best to have triggers at the very top level, since they occur outside of the regular event loop. Just check for on-pressed first, and then decode your variable.

A simple-enough update. Not a problem, and thank you! :)

Though, I don't see how my logic is off, per se, given that Else conditions - so I thought - only worked in relationship to the previous event condition of the same level. So long as event line 6 was true, Else gets ignored entirely, regardless of what happens later in the sub-events following line 6. But if that's not the case - or if a trigger alters that - then Else events are, to my thinking, not so clear as they should be.

Your Else understanding is fine - triggers are the things people stumble with. My rule is to ALWAYS have triggers at the top (or possibly in a group), and decode any standard logic inside the trigger.

Those uppity triggers, man. You'd think they'd play by the rules. :P

I think I'll try to adopt your rule about triggers, myself, just to save on future issues.