Fastloop to apply actions to all objects created by an event.

[mobichan]

You pick them based on a condition the eligible enemies will either pass or fail. One way would be based on whether they are currently playing a specific animation. Then I would set a flag on the enemy to mark it as a target. Sounds like you understand the basic concept. Just have to spend some time trying things out.

[Crash86]

Hopefully, I have found the solution now that the search function is fully functional (Thanks for fixing it by the way. The old search was terrible).:
http://community.clickteam.com/showthread.php?t=34967

I can't test if Francois' example works on these Macs here at work but I'll give it a spin at home tonight.

[Morbus Crohn]

I can't download the file in the thread Crash86 linked. I'm really interested to find a solution to this problem. I think at the moment I am a little bit confused with Active Object Association. Especially the "action loop"...

[Crash86]

http://community.clickteam.com/showthread.php?t=55166&page=2

Second-last post.
I asked this question ages ago and he had the answer. I just didn't understand spreading etc. then.
I tried this out and it works a treat. Just be sure to spread your values on the creator object outside of the other two sets of events or it won't create enough objects.
That guy is legend.

[Morbus Crohn]

Thanks...

I am still not sure if I understand the Object Selection of MMF very well... If there only would be a easy possibility to define the referenced object by some criterias.

[Crash86]

The selection after you create an object is an exception. In the first old thread I posted, Francois said that it was basically just a bug and that was how he programmed it in the beginning.
I think it was probably done to save CPU time.
If you want to apply actions to all created objects then you have to make it explicit with the fast loops now.

It seems to work very well. It's very good for creating particles because you can set them up when they're created and then leave them completely alone.
You don't have to test them for anything so you can have thousands in HWA.
Before, my vapour trails/clouds etc. were putting a big load on the CPU because it was having to test each segment to see if it had just been created.

[Morbus Crohn]

Ok thanks.. I think I am slowly starting to get it...

can you tell me what will happen to this examples? Will there be a difference if you have 1 or more battleships?

+ by pressing action button
- create Bullet @ position 1
- set bullet value A to 1
- create bullet @ position 2
- set bullet value A to 1

or

+ by pressing action button
- create Bullet @ position 1
- create bullet @ position 2
- set bullet value A to 1

or

+ by pressing action button
- start loop "shoot" 2 times

+ on loop "shoot"
+ battleship ready
+ pick one at random
- create Bullet @ position 1
- create Bullet @ position 2
- set bullet value A to 1

[Crash86]

In the first two, you'll generate as many bullets as you have ships/positions but you'll only apply the actions to the last-created bullet.

In the last example, you'll create one bullet at a random ship/location. The actions will be applied to it.

Did you manage to get Quinto's method working from the other thread? I'll set you up an example if not. I found it very fast and reliable. I followed his example to the letter and it just worked first time, every time.
I'm now able to lump-in quite a few different tasks to fewer objects thanks to this.

[Morbus Crohn]

I hadn't time to test it yet but if you have time for an example, I will be very thankful.

I think I get it but it just confuses me because it doesn't seems logical to me (almost everything else in mmf does).

If you create 2 objects and set the value to 2, why does anyone ever need to assign the value just to the last object by default?

Perhaps it is possible to make object reference a litte bit easier in an future update? MMF is so close to perfect ;-)

[Crash86]

Yeah, I found an earlier thread where Francois basically said that it was a bit of a bug or a mistake in hindsight that couldn't be changed.

If you use the old Games Factory from 1994, it does exactly what the fast loop does (applies actions to all objects created in the event but leaves the others alone) if you create your first/second examples in it.
So, clearly, this is just an illogical exception that dates back to the original MMF. It's just there, no understanding it.