I mean that in your event where you add damage ( I assume it is on collision with enemy/bullet ) you need to add another condition :

In your case if using flashing behavior, just ad player is flashing condition, then invert that ( add it to your event that checks for collisions and ads damage ).

That means even if colliding with enemies and bullets he will not take on damage while flashing

That is not a good design for mobiles though. Your finger will cover too much of the power bar and you will not be able to see exactly how much power there is and it's generally not a good idea to have to stick a finger in the middle of the screen in games like this.

I always go for, tap/click behind the ball and move away from the ball in the opposite direction of the power bar. That way you see everything clearly

Crop outer?

Just use a few particle emitters in the same spot and set those to different angles, then also play with angle randomizer property and you won't be able to tell the difference.

It should not affect performance either because you can have fewer particles coming out of each one ( combined they should match what you have coming out of a single emitter now )

just noticed this is a thread from 2013, wow. Well, my suggestion could also help the last guy posting. Few particle emitters, like I said, each can have a different shape or color, so you can create an illusion of frames/animation.

You can always use the browser object to detect device and then depending on what it is do anything you want.

For example, you detect it's an iPad, game loads and instead of proceeding with normal gameplay you jump to a layout which only has a pic of ..................................

[quote:30hjtt6b]It works on my Android version, but not on iOS?

The transparent button trick?

Last time I checked on iOS it worked fine, but maybe they've changed something with recent update?

No it is not. It's unreliable. It may change with browser updates, but that would often be blocked by browsers for security reasons.

Clicking on buttons counts as user input. Just clicking on a sprite does not.

If you are trying to open a link by clicking on a sprite, then this should work:

Add a button, put it on top of your sprite so they click on a button to open a link.

Make the button invisible by adding onStartofLayout > button set CSS style to "opacity" to "0"

If you are trying to open a link by clicking on a sprite, then this should work:

Add a button, put it on top of your sprite so they click on a button to open a link.

Make the button invisible by adding onStartofLayout > button set CSS style to "opacity" to "0"

If only debugger had a debugger of its own. Maybe in Construct 4

You could just use another condition in your damage thingy. If player not flashing ( assume that is an animation ) damage = OK.

So as long as it is flashing it will not pick up any damage

I think you need a nap. That is not at all what I am saying.

Given that 95% of your customers are on Windows it makes sense to concentrate on making sure you have a stable standalone on Windows.

After that is done do whatever you want with browsers and other OS.

You still cover everything just as you have now, but it would be Windows version first, then the rest ( and I am sure that is what almost everybody here wanted anyway ).

[quote:b8oaqtuf]So... because of a bug in a browser that isn't supported at all on Windows... you think we should have made a Windows app first?

No, but one day it will be a bug by Google and it will take down all of your customers who regularly update their Chrome browsers without thinking.