Turrets targeting themselves

Hi, I have what looks like a bug in my project. I have two types of turrets both in a family called "Turrets", and each also in a family of their own color ("Green" and "Red"), which I use to give objects factions. So, two turrets, three families. I want the turrets to automatically target members of the opposing color when they're created.

To do that I have an "on created" event for the "Turret" family. I first attempt to pick the first color family using the the UID of the turret that was just created. So:

Turret On created
(sub event)
     Green Pick instance with UID Turret.UID   Turret Add Turret target Red

(sub-event)
     Else
     Red Pick instance with UID Turret.UID   Turret Add Turret target Green[/code:gkne4bdv]

These turrets are both set to Target mode "Nearest", by the way.

The problem is that all the turrets end up picking [i]themselves [/i]as targets. If I disable one of the picking sub events, the other works perfectly. But if I leave them both enabled, all the turrets wind up wanting to shoot themselves. And after hitting my head against the wall for awhile on this problem, I can sympathize with them. <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

Here is a capx of this problem. 

[url=https://www.dropbox.com/s/4em3r96astjglmr/TurretBug.capx?dl=0]https://www.dropbox.com/s/4em3r96astjgl ... .capx?dl=0[/url]

Does anyone know what the cause might be, or if there is a workaround? If not I'll file a bug.

Thank you!

Just simplify it:

On green created : target red

On red created : target green

Or you can create txt variable and set them on their creation to either green or red, and then pick by that variable.

Thanks for the reply! That's a valid way to do it, but I want to keep all turret initialization logic in the turret's on created event even if it adds one additional condition per faction (color). I'll have various things using these faction families and hate to spread the initialization logic for them around at that level. But your suggestion should definitely work and in the short term I'll probably do something like that so I can move forward.

Still, my first approach should work - do you have any idea why it wouldn't? I'm using a similar picking system in other cases to treat families more like components, and it seems to be working just dandy. But this makes me think I'm misunderstanding something fundamental (and apparently pretty important) about the way families work, picking works, and/or the way the turret behavior works.

Thanks for the reply! That's a valid way to do it, but I want to keep all turret initialization logic in the turret's on created event even if it adds one additional condition per faction (color). I'll have various things using these faction families and hate to spread the initialization logic for them around at that level. But your suggestion should definitely work and in the short term I'll probably do something like that so I can move forward.

Still, my first approach should work - do you have any idea why it wouldn't? I'm using a similar picking system in other cases to treat families more like components, and it seems to be working just dandy. But this makes me think I'm misunderstanding something fundamental (and apparently pretty important) about the way families work, picking works, and/or the way the turret behavior works.

Then the events that are the same for both, make for the family that includes both types. But when you need turret to aim at the other group, it's best to have it separated. Will save you time, and frustration, and performance is the same!

I found this issue in the Bugs forum - it's a property of the turret behavior (AKA "Not a bug") that turret settings are passed to ALL other members of the family even if you change a single instance.

So there is no way to change turret behavior settings on an instance-by-instance basis if the turret behavior is coming from a single behavior in the family. This seems like a less-than-ideal implementation, because it limits what you can do with the turret behavior. I assume there is some under-the-hood reason for doing it this way, but as an end-user I can see no benefit.

So, the only ways to do what I want are to give all turrets with different target lists their own families with their own turret behaviors, OR to add multiple turret behaviors to the common Turret family and only activate the individual turret behaviors needed for each turret faction. So my Turret family would have behaviors TurretRed, TurretGreen, etc. Since it's easier to do one of those than try and write my own turret plugin (which is otherwise working wonderfully, I should add), that's what I'll do. It's messier than I want, but it'll work.

Thanks for your suggestions megatronx, much-appreciated.