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

Get help using Construct 2

Post » Mon Sep 01, 2014 12:55 am

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.
B
47
S
22
G
65
Posts: 1,127
Reputation: 38,395

Post » Mon Sep 01, 2014 1:54 am

No it's not possible. TBH it doesn't make sense to me to be able to do that.
B
24
S
9
G
4
Posts: 1,646
Reputation: 6,596

Post » Mon Sep 01, 2014 3:05 am

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.
B
47
S
22
G
65
Posts: 1,127
Reputation: 38,395

Post » Mon Sep 01, 2014 3:13 am

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?
B
47
S
22
G
65
Posts: 1,127
Reputation: 38,395

Post » Mon Sep 01, 2014 3:27 am

Prominent wrote: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.
B
24
S
9
G
4
Posts: 1,646
Reputation: 6,596

Post » Mon Sep 01, 2014 3:34 am

Prominent wrote: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.
B
24
S
9
G
4
Posts: 1,646
Reputation: 6,596

Post » Mon Sep 01, 2014 3:55 am

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...
You do not have the required permissions to view the files attached to this post.
A big fan of JavaScript.
B
76
S
20
G
74
Posts: 2,253
Reputation: 46,480

Post » Mon Sep 01, 2014 4:28 am

Colludium wrote: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.
B
24
S
9
G
4
Posts: 1,646
Reputation: 6,596

Post » Mon Sep 01, 2014 5:30 am

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.
B
24
S
9
G
7
Posts: 756
Reputation: 7,312

Post » Mon Sep 01, 2014 6:04 am

codah wrote:
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.
B
47
S
22
G
65
Posts: 1,127
Reputation: 38,395

Next

Return to How do I....?

Who is online

Users browsing this forum: dop2000 and 22 guests