Referencing a Family Instance Variable in an Expression

Hello!

In the above example, it seems that the Facing value that's grabbed in the Expression:

"Walk" & Enemies.Facing

Isn't the Facing value of whichever Sprite in the Enemies Family that this event applies to.

.c3p file:

drive.google.com/file/d/1FdaydzYiBfLpecsF6B_X4p_EMM8sDJ3l/view

Upon running the layout, the 4 Enemies that walk around randomly seem to play the animation of the most recently updated "Facing" instance, instead of the value of their respective Sprite.

I might be going around this entirely the wrong way, is there a better way to handle identical isometric enemies with asynchronous frames?

if I understood good, here is the solution:

https://drive.google.com/file/d/1GgR2919wpv4XV4fKzQ5jGaoqOXOKyW7k/view?usp=sharing

just reupload the link, I made it look more natural.

D'oh! Looks like I needed that "Trigger Once" event to not have it fire multiple times. those System events are powerful. Thanks a ton! :D

drive.google.com/file/d/1-dIiNxDfPsGb8HWaK_3qQ_6cyiev0twu/view

It still seems like when you reference a family instance variable in an expression, (like my "Walk" & Enemies.Facing), it doesn't look at an individual family member's instance variable value, rather, looks at all the family members' instance variable values, and just uses whichever one was last updated.

Just run the project and hit spacebar - you'll see that the walking animation doesn't stop on any of the Enemies until it stops on all of the Enemies. From what I can tell, it's because "Is Moving" is still true on at least 1 Enemy. That kind of circumvents the whole point of families.

Get rid of the trigger once, also the Else. Use an event 'move to is not moving' for the Idle animation. Can't see the original file but if you had a problem with picking, adding a trigger once was not the fix.

Like this?

Here's a .c3p with that change: drive.google.com/file/d/1fndJazzGJUSX5i0jeA0afB2Yx2MnCpTF/view

Same problem though. You'll see what I mean if you can run that. It updates every time any Enemy changes its Facing value, instead each Enemy individually, like Families normally work. I think.

Wait I just noticed you are picking Enemies then trying to play an animation on a different object EnemyAnimations, that isn't going to work as they don't relate to each other, and putting them in a container isn't going to work as you are using families. You should use one Family object for Enemies.

They aren't related even though the EnemyAnimations spawn in as a child of their Enemy parent? Phooey. Alright, back to the drawing board then. Thanks!

There is a fairly new feature called Hierarchy but I don't see it in use in your project. I've not used it myself and not sure if it's required here. As far as I can tell it's more for animations in a scene. I would create one Family for 'Enemy' and add all behaviours, anything else is overcomplicating it.

Here this is a question of picking.

Your condition "Enemies. MoveTo is moving" will take ALL the instances of ALL the object types in the family Enemies which are moving at that tick of execution.

So if you have only a single instance of the WHOLE family that is moving, nice, you will get the .Facing value from it.

Otherwise, it will go through all the picked instances, and the value of the last instance is going to be the one applied.

That's why the "Trigger only once" seemed to work for a while, because it took only a single instance of all the Moving instances, and applied the value only once.

Now apparently, there might be picking issue with the EnemyAnimation instances also.

Apparently, you want to pick ONE instance, that is a child (in a hierarchy) of the Enemies object.

Perhaps you should, rather than hierarchy (which is meant to make objects move/behave as a single one; in order to create a structure), look into the "Container" feature and have your ENEMYAnimations as an object contained in your ENEMIES.

For example, CosmicKrampus being the container to CosmicKrampusAnimations. This way, picking a CosmicKrampus instance, any modification made to CosmicKrampusAnimations will be made to the instance "contained"/link/attached/tied to the CosmicKrampus instance that you have picked.

Yes, over the last 48 hours I've come to the same container conclusion that you came to in 2 minutes (but I guess that's why you're the moderator and I'm the customer, lol)

However, putting CosmicKrampus and CosmicKrampusAnimations in a container doesn't seem to make any effect.

No combination of the two aforementioned sprites nor their respective containers is preventing each CosmicKrampusAnimations from changing its animation every time the .Facing value updates on any CosmicKrampus. (Same behavior as without a container. There's no master/slave or parent/children relationship in a container right? They're both in there equally? There's also a container mode in the properties bar that the manual doesn't cover, but same result on all 3 modes.)

Current .3p:

drive.google.com/file/d/1ctvX4dHtBmdHG6E4iugTMTGwev3X7THQ/view

If there's an easier way to handle directional animations on multiple enemies, by all means, point me in that direction. Thanks for taking the time to look into this.

As mentioned above the container won't work, the easy solution you're looking for is to make it one object. The behaviours can go on the Family object.

I think if I merge the Enemy and EnemyAnimations into one object, the same object will both be rotating, and playing an animation, which means when moving left the animation will be upside down, etc

If I just put them both in the same family, I'll give all the EnemyAnimations a lot of behaviors they don't need, not to mention it still doesn't solve the problem of associating each Enemy with its respective animation sprite (I think? I've been using Construct 3 for a week.)

Anyways, I sort of found of a solution, and I don't know why it works, but it does.

I gave EnemyAnimations their own family instance variable also called Facing, and make it update to Enemies Facing value every tick. That way the Event to set the animation reads the Animation Sprite's .Facing value, instead of the .Facing value of the Enemy. Pretty ugly, but it works for now. Hopefully I can bundle it all up in a black box and never have to touch it again.

Oof. It seems as if any characteristic of the Enemy sprite that I need to pass to the EnemyAnimation sprite, has to be done through that janky syncing variable method I created.

To check if the Enemy is moving, I have to give it an IsMoving number variable, 0 for false and 1 for true. (and it can't be a boolean, because you can't set a boolean with an expression in an action.) Sync that variable to an identical variable in its EnemyAnimation, and use the value of that variable to play any relevant animations.

It's pretty ugly, and I'm worried how it'll scale, but it's getting the job done!