Having unique variables for instances within a Family

Having unique variables for instances within a Family just doesn't seem to work. It seem Construct looks for a variable's index number rather than its literal string name.

What I'm saying is I had a "bullet" sprite created before I got around to making a family for all kinds of bullets, and I gave that family its own variables. But as I check against the "first" variable for that family, if I already have variables unique to one specific bullet instance, it will check the "first" value in the list of that specific bullet's variables.

Am I missing something here, or does it indeed check for just a numbered index rather than the name of the variable? I am having issues with this in an Event Sheet not tied to a layout.

It's kind of hard to say, as I don't know how you are picking.

For example if you just say

family move to x

all objects in that family will move to x

or if you say on collision with family

It will pick only the object that have that particular collision.

So if you were to compare a pv in a family all objects with that pv will be picked, but if you were to do something like

family set pv to 1 all objects with that pv would set the pv to 1... unless you have an additional condition that tells it otherwise.

Now it is possible to put objects with different pv names into a family, but that wasn't always possible to do that. You might want to check out all the pvs in the family editor, and if some are missing you may have to add them manually.

Supposedly every object in a famly should share all behaviors, as well as pv names.

Maybe I didn't make myself clear.

• My problem is, say, I have these values in a Sprite: bump & lump
• A Family is given these values: sing & dance
• I proceed to make Sprite part of the Family, and sing & dance now follow bump & lump in Sprite's variables.
• I have an event that sets the Family variable sing to 1.
• Construct proceeds (as it seems) to set bump to 1, as it's the first variable to the Sprite, because Family's value sing is first in the list to the FAMILY, so therefore it seems to search for a variable by index, not its exact name.

I haven't had time for extensive testing, but Construct is at least changing the wrong variables.

EDIT: I'm gonna try an example file. My bets are that the same problem won't happen when I try to recreate it, like always.

That should not happen. If there is some error somewhere I'd suggest making a new family, adding those objects to the family then replace the old with the new.

I still feel its something to do with picking.

Is the event part of another? I know there is an issue changing pv's from subevents.

Of course my attempted example had no issue like that, like friggin' always!

But it doesn't change the fact that both recent attempt where I've been trying to use families, the values screw up and I end up not being able to use it. I hate this. When I can't show the exact problem it of course can't be fixed, or realised if I'm the cause.

EDIT: Yes, I use sub-events. What is the issue exactly?

If anyone wonders how I came to the conclusion it changes the variable by index it's because an action in my game repeated as if the first value, not related to the Family, reset for whatever reason. That variable is not referenced at all in the code regarding the family.

Yes, I use sub-events. What is the issue exactly?

Well I was destroying an object with the initial event.

Family.man hp= <1

Family.man leader=1

Family.man destroy

--Family.man pick one at random

-->Family.man set leader to 1

Subevent will not work, It needs another tick to set it.

Well, that seems another issue, and it involves "destroy", after all.

EDIT: By the way, I'm even getting a crash from my most problematic event if I shoot a certain enemy, and I have no idea how to determine why it happens. Debugger tells me nothing, just that that enemy has a problem on a line that just sets a variable to the variable of another family.

Maybe I should just make something simpler in Construct for now.

all crashes are bugs, report them to the tracker!!

It seems the crash I had was the same everyone else is pointing out in the 0.99.5 thread.