Closest object with ForEach

That's a nice and efficient example! Though I'm not sure why you insist compressing your .mfa's with some (proprietary) archivation format. It's a 50KB .mfa file.

Nice example, thanks

I agree about 7Zip i use it all the time now. I was hoping it would be added to the Archive Object as the dev said more formats would be added but i think it is currently only zip still.

Sorry for the late reply Tiles.
The reason this does't work is because in the C++ version of the extension, when you start the foreach loop is doesn't actually get started until all the other actions within that event are completed. This is because the ForEach object affects what other objects are selected and so could mess up any other actions that need to occur after the foreach loop action from that event (in this case it would be the recursive action of setting the active's AltVal A).
Starting an action at the end of the event like this is not possible in the Flash runtime, so a foreach loop gets executed like any other action.
So, in the flash version the object's AltVal A is not being reset on all the actives because your 'On foreach loop xyz' conditions are changing what is selected from that original calling-action and event.
If you take out the Always action that starts the foreach loop, and put it into another Always event, then it works fine in both runtimes.

Nice example!

One suggestion: since you're always looking for the closest object, in order to avoid situations where moving objects could get in a distance greater than 10000, I'd set that value -instead- to the alterable value A of one of the active objects.

To achieve this you'll have to move the "Set counter" action to:

-> Pick one of "Active"
++ Set counter to Alterable value A of "Active".

Also take into account that calculating square roots is an expensive operation so I wouldn't use it "Always" but every T time, instead.

I have deleted my previous post in which I explained a trick to save some computations, but I decided to upload an example for better understanding (and it also works ok in Flash).

Changes:

1) There's only one loop (since the calculation of alterable values "A" is now inside the fastloop),
2) Sqr operation is not executed for all active objects (a trick that spares computation time), and only for the closest one (just to set the visible counter), and
3) It allows you to customize the start of the fastloop; if you have thousands of active objects maybe you decide to do calculations once every T time (instead of "Always").

Lol ... they do (trust me)

While you're at it, remove the "on foreach loop" in the last condition too

Done

I couldn't get the idea out of my mind that the extra time to evaluate the expression within the additional "on foreach loop" would cause a greater slowdown than the speed gained from the fact that BHGames soltion doesn't calculate the square root for every distance, so I tried some benchmarking. I set up both examples so that they try to default to a frame rate of 500hz, and try to find the closest distance 1000 times per frame instead of one.

On my machine, with Tiles' example I get a framerate of 28fps. With BHGames' I get 14fps.

However, if I modify BHGames' example so that the expression (X( "Active" )-X( "lookatclosest" )) pow 2+(Y( "Active" )-Y( "lookatclosest" )) pow 2 isn't within that additional "on foreach loop" condition, so that it works more like in Tiles example, I get an average of 29fps, which is of course a difference too small to really matter.

I guess the lession is that to optimize, worry about the event structure before worrying about maths.

No, you got my explanation wrong. The original example has an additional "For each" loop since it calculates it for all objects and then it traverses all objects again to find the closest.

By moving that calculation to the ForEach condition, there's one loop.

Now, talking about results, if that is happening then the "For each" object should be optimized because the internal "For each" condition is faster.

I got similar results!

On the second example (mine), the additional ForEachLoop "checkdistance" condition kills the framerate, compared to examples 1 (the original) and 3 (mine modified by you).

Well, it's not a surprise. MMF2 loops through objects a lot faster than the ForEach object does, as it doesn't involve evaluating the "on foreach loop" expression once for every object and some other stuff MMF2 probably does to make an event work. I predicted the slowdown before I confirmed it with the benchmark test, so I'd say my guess was pretty accurate.

The expression (X( "Active" )-X( "lookatclosest" )) pow 2+(Y( "Active" )-Y( "lookatclosest" )) pow 2 have no reason being in a foreach loop, MMF2 does that automatically anyway. Same reason as there's no need for that "on foreach" for the arrow to look at the closest found object.

You're right I forgot that fastloop and foreach objects aren't actually "pure" For (and Foraech) statements since they involve evaluating wheather a sentence belongs to the conditional loop or not (in contrast to pure for loops where all conditions/actions inside its brakets are part of the loop).

> And we have learned something again

Yeap. MMF3 should change the way it deals with fastloops and foreach objects. :p