How do I access instance's behavior from within a family?

I keep running into the need to access the instance's behavior that has been picked from within a family. I only have access to the family behaviors.

Don't respond with questions as to why I would need this and effectively change focus of the question. If this is simply not possible, then it should be something to consider implementing.

Thanks.

No it's not possible. TBH it doesn't make sense to me to be able to do that.

Okay.

Well, families group objects together.

Objects in a family can have different behaviors from each other.

Referencing a group allows you to use less events to pick out objects (saves you from having to create events for each object).

When you pick out an object this way and need to perform actions based upon their behavior, then you simply can't do it without extraneous steps that make the events crowded and difficult to change later.

Doing this defeats the whole point of Families.

What I would want, or what I think would suffice:

Families collect all behaviors from each object in the family, and provides access to these behaviors in the event sheets, but if the behavior is used, and the instance doesn't have that behavior, then that it is ignored.

Seems like a simple thing to implement?

Okay.

Well, families group objects together.

Objects in a family can have different behaviors from each other.

Referencing a group allows you to use less events to pick out objects (saves you from having to create events for each object).

When you pick out an object this way and need to perform actions based upon their behavior, then you simply can't do it without extraneous steps that make the events crowded and difficult to change later.

Doing this defeats the whole point of Families.

I guess there are logical reasons for their behaviour. A Family is like a base class in OO languages. When using a Family you're saying, I want to treat these types of objects as a 'new' XYZ type. You effectively lose the object type information at that point. To get that information back (in order to access their behaviours) you would need something like an OO 'cast' which retrieves the type information. This is even frowned upon in some OO circles. I disagree it defeats the whole purpose of Families. It cuts down on many identical events as you know. And yes I know C2 is not OO but it's an analogy.

What I would want, or what I think would suffice:

Families collect all behaviors from each object in the family, and provides access to these behaviors in the event sheets, but if the behavior is used, and the instance doesn't have that behavior, then that it is ignored.

Seems like a simple thing to implement?

I can see issues with this. How would you know if you were inadvertently accessing a behaviour that didn't exist? Could take a bit of debugging. I can just see it getting out of hand, and also breaking the tenet of 'simplicity' for C2.

I'm curious what kind of workaround you're using at the moment. I would think something with the 'nickname' plugin would work.

There's a simple work-around that I use sometimes. If you want to identify a sprite from a picked family then add a variable to the family to allow you to identify the sprite that has the behaviour you want to change. Then, using the Family.UID, the instance of that particular sprite can be picked (or instance of other family, if applicable). See the attached file for a super-simple demo. Hope this helps...

There's a simple work-around that I use sometimes. If you want to identify a sprite from a picked family then add a variable to the family to allow you to identify the sprite that has the behaviour you want to change. Then, using the Family.UID, the instance of that particular sprite can be picked (or instance of other family, if applicable). See the attached file for a super-simple demo. Hope this helps...

I guess this is exactly what the OP is trying to avoid

One thing that might help is by allowing a Family to belong in another Family, and aggregate the behaviours across all contained Families. This is something I've wanted a few times.

If you've single member of the family you can do this:

Sprite1 pick by uid : Family.uid

Sprite2 pick by uid : Family.uid

Sprite3 pick by uid : Family.uid

Etc.

then you can access sprite specific functions behind every condition.

I can see issues with this. How would you know if you were inadvertently accessing a behaviour that didn't exist?

Like I said, it would simply ignore it. Nothing would happen if it doesn't exist. You should know how your program works, so running into this issue wouldn't be an issue if you're aware of what things should be doing.

vee41, that workaround is exactly the type of thing Families should be preventing.

That is the type of workaround I'm using, but I have to use it so many times that it is becoming a bit ridiculous when this could be prevented and made much cleaner.

>

>

> I can see issues with this. How would you know if you were inadvertently accessing a behaviour that didn't exist?

>

Like I said, it would simply ignore it. Nothing would happen if it doesn't exist. You should know how your program works, so running into this issue wouldn't be an issue if you're aware of what things should be doing.

.

That's why I said inadvertently. That would be a very frustrating class of bug.

codah

No, 'nickname' plugin could not solve this problem.

That's why I said inadvertently. That would be a very frustrating class of bug.

Perhaps, but there's always going to be possibilities for human error with everything.

One way to help confusion is to highlight the event with a color where behaviors may not be active. So it would check all objects in a family and if you reference a behavior that isn't attached to all members, it would get highlighted red as a warning that the event may not fire,etc..

So a kind of, use at your own risk, sort of thing.

codah

No, 'nickname' plugin could not solve this problem.

You're right, I had a go but it doesn't solve anything. I wonder about families within families (multiple 'inheritance' )

> codah

>

> No, 'nickname' plugin could not solve this problem.

>

You're right, I had a go but it doesn't solve anything. I wonder about families within families (multiple 'inheritance' )

That has been discussed many times, it is just not what families are meant for