Found another instance of the loop bug and I isolated it completely. This might be useful for solving it. The requirements for triggering it seem very strange and specific. SameBug.mfa
While installing the latest version on Steam, \Data\Runtime\Unicode\ssrt.exe gets marked as a trojan by Microsoft Security Essentials. Is this a known false positive?
So the problem was not due to the optimization I talked about yesterday, it could have happened with previous builds too, I guess you were just lucky the object selection was ok.
An immediate solution for you is to insert an Always event as child event just below the parent event and move the actions of the parent event (especially the Start Loop action) to this line (line #51 in your previous example).
I'm checking if I can do something in this case (= when you use a Start Loop in actions of a parent event), not 100% sure I can fix it. EDIT: no easy fix and no fix that wouldn't possibly affect performances, so you have to use the solution above.
The object selection is saved at the end of the actions of the parent event, and restored before each child event line. So if the selection of the Player Flags object gets cleared before the child events are executed, the conditions on this object in child events will be false. And this is what happens after the loop is executed, because when I go through the child event line with a debugger the code says "no object selected => condition is false".that example is all singletons so what's being picked?
Your second example doesn't work in previous builds, I've checked.Nothing like this happened with previous builds
In your first example it was working because the fast loop was evaluating all the "On Loop" conditions of the frame and for some reason that I've no time to check right now the selection was OK after the last On Loop was evaluated. In the new build this no longer happens: thanks to the optimization / fix that was done only the On Loop conditions for the given loop name are evaluated and this revealed the problem.
Ok I have run into a VERY obscure issue. Essentially, at some point this summer, Valve upped the number of significant digits in Workshop item ID's from 8 to 10. This has put those values into a whole other unsigned 64-bit integer RAM bracket, and Fusion can't read them. Normally when loading in a ContentID value, they'll roll over into the negatives, and if I'm lucky I'll get something like 2496e+10^9 or whatever. This means the Steamworks object is unable to download Workshop items and likely won't ever work again.
Is there any any ANY chance the number of significant digits Fusion can read can be upped from 8 to 16? Mondrian is heavily reliant on user generated content and this bug could basically kill the game and nearly force me to remove it from market.
Edit: I've read this over and over and I think I get what you're saying, maybe? 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?
This morning it seems there's been a new definition update since, and scanning the file doesn't trigger any issues now.