Build 293.1 - Release version

[dustingunn]

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

[LobsterKing]

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?

[Yves]

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?

Must be new. I'll submit it to them. Thanks! (PS: for info this file is the runtime used when you build a screen saver)

[Yves]

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

Thanks, I think it's an object selection issue. The Start Loop action has always been known to not preserve the object selection. As you use it in the actions of a parent event, it can modify the object selection in the child events.

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.

[Yves]

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?

Must be new. I'll submit it to them. Thanks! (PS: for info this file is the runtime used when you build a screen saver)

Actually I can't reproduce it here, maybe they fixed it in the meantime?

[dustingunn]

Thanks, I think it's an object selection issue. The Start Loop action has always been known to not preserve the object selection. As you use it in the actions of a parent event, it can modify the object selection in the child events.

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.

I don't really understand what you're saying. Nothing like this happened with previous builds and that example is all singletons so what's being picked? The condition is true as shown by the debug send and I never rely on object picking that happens before a loop to carry over. That fix did work but it doesn't make sense to me, logic-wise.

[Yves]

that example is all singletons so what's being picked?

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".

Nothing like this happened with previous builds

Your second example doesn't work in previous builds, I've checked.

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.

[dsilvers]

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.

[dustingunn]

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".



Your second example doesn't work in previous builds, I've checked.

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.

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. I get that loops clear object picking. I coded around that. The child events shouldn't need any picking.

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?

[LobsterKing]

Actually I can't reproduce it here, maybe they fixed it in the meantime?

This is likely, as I updated the definitions yesterday night to be sure and it still quarantined the file while Steam was downloading it (while it's in the Steam\steamapps\downloading folder). I've restored the file so Steam could proceed with the update.
This morning it seems there's been a new definition update since, and scanning the file doesn't trigger any issues now.
Thank you!