A bit toying around with the ForEach object. This example looks at the closest object.
Closest object with ForEach
Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.
A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.
Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!
Clickteam.
A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.
Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!
Clickteam.
-
-
And this is also an excellent example of a ForEach Bug with Flash. It does not work in Flash
-
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.
-
Thanks
That`s pure habit. The file size limit here in the file archive is very low. Around 200 kb from what i know. And i`ve hit it too often in the past. So i zip it by default. I wouldn`t call rar a proprietary file format nowadays anymore. 7Zip can handle it, is open source, and should be installed at every pc
Too bad that Ross didn`t react so far. I`ve written him a pm about the flash bug. That`s where i would`ve needed it ...
-
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. -
Thanks for the indepth explanation and your help Ross. In short: watch the order of Events. Starting a ForEach Loop better sits in a separate line of code to work with Flash!
Works like a charm now
-
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"). -
Nice changings. I am just not sure if your changings makes really sense
-
Lol ... they do (trust me)
-
While you're at it, remove the "on foreach loop" in the last condition too
-
-
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).
-
Heh. That`s what i have meant with "does it make sense"
But yeah, it`s always worth a try. The modifications could also have improved the speed. And we have learned something again
-
> And we have learned something again
Yeap. MMF3 should change the way it deals with fastloops and foreach objects. :p
-
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!