I knew there was a solution somewhere with either the IIDs or UIDs! Thank you! Wow, bought Construct on June 2nd and already got help from the boss man himself :D Your method is probably more performance friendly than my wonky variable syncing trick. Thanks a boat load!

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!

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.

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.

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!

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.

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.

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

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?