Problems using Qualifier / Groups when overlap

[AyreGuitar]

I've always wanted to get my head around using Qualifiers (aka Groups) effectively so I can cut down the amount of code i use. However, I've run into a bit of a problem which you can see with the attached example file.

The example simply changes the direction of the Active (Red Block) to the direction of the Qualifier (Yellow Arrow) when they overlap, but doesn't give the expected results. It's as if the code is confused as to which arrow is overlapping which block. The 2nd frame of the example shows how it should work, but doesn't use Qualifiers, and so has random start directions for the qualifiers (not what I want!). I'd also prefer not to have to use fastloops, since this is for an iOS project.

Perhaps I'm missing something simple? Any help is much appreciated!

[mobichan]

You will need to use fast loops, I think. Basically, you need to force MMF to select the specific member of your qualifier group. If you don't then you will be applying actions to all of the qualifier group members.

[AyreGuitar]

mobichan - thanks for replying.
That's a shame. I'd expect it to work the same as any other active, just picking the specific objects that overlap. This is probably why I've always ended up with problems in the past. Is there a good article on Qualifiers anywhere that explains this (eg Knowledge Base, Wiki, etc)?
Looks like I'll have to remove most of the qualifier code and go back to plain actives overlapping to get the desired effect.

[mobichan]

I am not sure where a good source of info would be. You can try scouring the forums for examples. I tend to use qualifiers when I want to apply code to groups of objects, instead of writing unique code for each object separately. Overlapping tests can be tricky, but you could try creating an invisible overlap object (not in your qualifier group) that you set to the position of your first overlap object. Then do your overlap test against that invisible object. You would still need to use a fastloop, but it might simplify things for you. I don't understand why fastloops get such a bad rep with people. I use plenty of them for exe and swf games and they don't make any noticeable amount of slowdown. You can also minimize their impact by keeping your loop code in groups and disabling the groups when you aren't using them. You just need to plan out your code to work with them.

[nivram]

Reg. I think it is just a matter of method of coding. Someone doesn't like fast loops, or they don't understand the inner workings. So they start frothing from the mouth and spread some vicious preaching about fast loops. Before long it is against all programming rules to use a fast loop.

I use them.

Marv

[Chaos]

Hey Kevin/Ayre,

I might be a bit late to the punch, but when I use my qualifiers in CoI - I add a condition to 'pick OBJ at random' with the overlap condition, and it seems to sort them out properly for me when I'm interacting with multiple actives in the same qualifier group. I'm not sure how your code is set up exactly, but if you still have an older version of the qualifier code, give it a shot!

[AyreGuitar]

Hi Chaos - Pretty sure I gave that a try, but will check again - sometimes the order of events needs to be tweaked. Thanks for the suggestion!

[Shawn]

Fastloops getting a bad rep could be due to poor optimization or bad code. I'm not saying every instance of slowdown caused with fastloops is due to this, but I would be willing to bet a good number are. Or, as is always the case on the internet, things get over exaggerated and blown out of proportion. If you're trying to pull off a lot of intensive stuff simultaneously I can understand that being an issue.