First, give the sprite the Tint effect, default settings make it red. Then, at the start of the layout, disable the effect.

Next, give the sprite the Flash behaviour.

Now create a function that you'll call whenever the player is damaged. In that function, set the tint active, then start the flash behaviour, then wait a period of time, then set the tint inactive.

I've attached a quick example of this in action.

Note that this uses a WebGL effect, so this won't work if there's no WebGL support on your target platform. If you want to be absolutely rock-solid, then you might have to create new sprites with the red tint already applied. Flash will work regardless, though.

There's actually a version of the Ghost Shooter demo included with Construct that has that exact feature. You can find it on the list that pops up when you create a new project. It looks fairly complicated but if you break down the events one bit at a time you should figure it out.

Oh, that's quite interesting. This seems to be caused by the fact that you're using the object->spawn action as opposed to system->create. Spawn seems to specifically pick the current instance as the spawner, rather than the spawnee. Create picks the spawnee as the current instance.

Here's an example of the two different events in action.

Setting up the parameters of an object in the same event in which it's created definitely does work, but you have to be in exactly the same event or a sub-event. If you're trying to do it in a parallel event (if the creation and parameter defining actions are both separate sub-events of another event), then Construct will reset the picking and default to all instances of the object. Picking is always reset as soon as you step up and out of an event.

I'd say the absolute easiest way would be to have the control groups disabled by default, then run an event on startup that goes something like this:

Text > Set Text ("3")

Wait 1 second

Text > Set Text ("2")

Wait 1 second

Text > Set Text ("1")

Wait 1 second

Text > Destroy

Set control groups enabled

Not elegant by any means, but totally functional.

I suggest that you take a step back, learn and understand fundamentally how picking and events work and how containers and/or families will help. Then try to rework your game logic using that knowledge. There's little point in throwing a bunch of new ideas at wonky code unless you understand those ideas.

There are loads of threads about this exact topic. Just do a bit of searching on the forums and you'll see this question has been addressed many times before.

Because the logic is wrong. The "container issue", as you call it, is at the root of the problems.

Here's a quick example I put together to illustrate the difference between events referencing objects in containers, and those not in containers. Hopefully it'll give you a clear visualisation of what's going on inside your game.

Also worth noting is that objects in containers are automatically created at the origin of their "parent" objects (although containers are actually flat and not in a hierarchy, they can still use root objects to create the rest of the container objects). Otherwise, if those objects already exist, they are paired according to the order in which they were placed in the layout.

Oh, okay in that sense your events are even more muddled than I thought

Read through the containers manual entry for all the details, but essentially, containers make different objects behave together very well.

If you put the red sprite, aggro sprite and skeleton animation together in one container, when you have a condition that picks any of those objects, it will always pick the corresponding other objects in the container for the purpose of actions.

It's difficult to really tell without seeing the full capx, but why are you using separate objects for enemy and enemy aggro? If you're following the recommended practice of using a bounding box (EnemyAggro in your case) for the actions and a sprite for the animations, you need to store all of the necessary data and behaviours in the bounding box object, and only pass on the necessary animations to the animation sprite.

From what I can tell, you're assuming that the bounding box knows which skeleton animation to trigger, and vice versa. It won't unless you specify that, so it's applying the actions to every instance. Depending on how your game is set up (or rather, you should set your game up in this way), you should be using containers to pair each skeleton to a bounding box so they always know to which instance you're referring. Read this manual entry on containers.

Also, you have loads of redundant "every tick" conditions there. Read this very important blog post.

You're using four plugins there that I don't have. I strongly suggest that you remove them and re-upload your file if you expect people to help. It's also possible that those plugins are causing your issue.