I don't get it. Are you saying it's working as intended? That seems unintuitive/illogical for a parent event to always make a child event (which requires no object picking because it's a singleton) false.
? No, not at all. I say that Start Loop messes up the object selection, so it should not be used in the actions of a parent event (because the object selection is propagated to child events, and this is done after the last action of the parent event). Fixing this is a bit tricky and might cause performance issues, so I'm not sure this will be fixed. You should move the Start Loop action from the parent event to an Always line as first child event, so that the object selection is modified only in this new line and doesn't interfere with object scoping in other child events.
It's a similar issue to the known one when you use Start Loop with other actions, sometimes you have to move Start Loop to a new event line if it modifies the selection of the objects used in other actions.
Instead of the object picking being reset, it keeps the object selection but none of them qualify so it's like a list of 0 "Player Flag"s now being tested. In the first example, I make a condition designed to pick (Fixed Value = *) and instead of looking at all bullets, it checks a list of 0 bullets and finds none. Is that really how it's supposed to be?
Maybe, not sure if I understand what you mean either. And no it's not supposed to work like that, it's due to the Start Loop action which doesn't preserve object scoping.
Let me take your example:
* onJump of Player Controls = 1
+ Hanging of Player Flags = 1
Special : Start loop "TryUnduck" 1 times
Special : Send Str$(Hanging( "Player Flags" )) to output window
+ Hanging of Player Flags = 1
Sound : Play sample click1. First line selects the Player Controls object that have the onJump value equal to 1.
2. Second line selects the Player Flags object that have the Hanging value equal to 1, and runs the actions:
=> when Start Loop returns for some reason the Player Flags selection list is cleared, so zero Player Flags is marked as selected.
=> Send Str$(Hanging( "Player Flags" )) to output window will seem to work because IIRC in expressions if no object is selected the engine takes the first instance.
=> after callind these actions, the engine saves the current object scoping that will be used in each child event.
3. Third line, as it's a child event it takes the object selection saved after the parent actions => no Player Flags is marked as selected. So the "Hanging of Player Flags = 1" will be false.
If you move Start Loop to a new line, this works the normal way, as the Start Loop issue doesn't interfere with the other child ev:
* onJump of Player Controls = 1
+ Hanging of Player Flags = 1
+ Always
Special : Start loop "TryUnduck" 1 times
Special : Send Str$(Hanging( "Player Flags" )) to output window
+ Hanging of Player Flags = 1
Sound : Play sample click1. First line selects the Player Controls object that have the onJump value equal to 1, no change.
2. Second line selects the Player Flags object that have the Hanging value equal to 1. No action, so it just saves the current object selection, i.e. one Player Flags object is selected (and if the Player Controls object is used in child events this one is also saved).
3. Third line, the Always event line. The object selection saved above is restored, and the actions are executed.
4. Fourth line, the object selection saved above is also restored before the conditions are evaluated, in this case there is one Player Flags object selected, so the condition can be evaluated and is true.
Hopefully it's more clear.
