I'm the one who wrote "It should just work". I wrote that because I was made to feel like it was my fault CJS wasn't working properly. Like it was my responsibility to tweak and sleuth my project to make it work properly with CJS. This isn't how it's supposed to work.

And the same goes for our games. They should just work. Free or not. If someone can't understand how to play our game, or a section of our game is unclear, it our fault. It's not because the player isn't smart enough to get it. It's not because they didn't read the instructions carefully enough. It's because we didn't do what we needed to do as designers to make them understand how to play. If any part of our game seems "broken" to them, no matter how simple, then it's broken.

Like I said before, these guys can fix CJS no problem. If I handed them a million dollars and said "fix it" it would be done overnight. But it's a business, and time is money. They will eventually fix all the problems but for now we're getting exactly what we pay for.

Just for the record, I feel Construct 2 is genius software, ahead of it's time, and Scirra's dedication and involvement in the community inspires confidence in the company and the product.

On not sure exactly what's going on here but it seems like when you say;

A On Collision with B

It resolves one at a time rather than resolving all the collisions then applying actions to the affected instances.

You can see this in action by simply adding "Sprite2 | Set position(0, 0)" to the action list.

You'll notice only one instance of Sprite is affected. As if the first collision resolves, then Sprite2 moves causing the second collision to fail.

Why?

Simple. Just create an invisible Zone sprite of any shape and set the Turret to automatically target an object (Add object to target).

Then check if the object is overlapping the Zone.

If it is, then enable the Turret, if not, then disable the Turret.

Off the top of my head you could try this? This might work if only one Enemy can be alerted at a time. Otherwise, you'd need to Pick nth instance to limit it to one.

(Create a couple variables X and Y.)

Variable X

Variable Y

(When an enemy is alerted, record it's position)

[event] if Enemy becomes Alerted:

[action]X = Enemy.Position.X

[action]Y = Enemy.Position.Y

(then compare all the enemies to that position)

[sub event] Pick All Enemies

    [sub event] System | Pick by evaluate distance(Enemy.Position.X, Enemy.Position.Y, X, Y) < 200

    [action] Enemy become Alerted

CocoonJS doesn't support Letterbox so it defaults to Scale Outer.

Yeah, I never really had a good grasp on this. As a result, I only ever use -or- when I'm not picking objects and implement -or- when picking by creating separate events. It would be nice to know what's happening under the hood here.

That's a tough one.

I know this works;

Sprite | Overlap Red

-or-

Sprite | Overlap Blue

So I'm thinking it has to do with "System Picking" maybe? Does calling a System Pick break the rules?

Try adjusting the Origin point of the green square to the far left. You will then have to rotate and re-position the green squares in the layout such that all their origin points are in the center of the larger vortex square. That should do it.

To be clear, when I say far left, I mean around -500 on the X value. The Y value can stay centered.

That was kind of mean. Don't worry, Ludei can handle the criticism. They're a business. Making CocoonJS work seamlessly with Construct 2 is only a small part of that business. Just because it doesn't quite work yet doesn't mean a team of professionals is struggling to get it to work. It just means they only dedicate a certain amount of resources into fixing it for us.

Sorry, I didn't mean to ruffle any feathers, just looking forward to the potentially low barrier of entry for mobile development.

Installed by clicking update in the app store. Is there another way?

There are no Text objects in the game.

Something like this should "just work" since it only has one purpose in life. It's only reason to exist is to take what we've done and "make it go" on mobile devices. If any single setting or object could make the frame rate drop 30+ frame per second, then that is considered a flaw in my mind.

Clearly CocoonJS isn't fully cross-platform ready, at least not when used with Construct 2.

Hopefully Ludei will sound off on this issue at some point. At least acknowledge it is an issue.

Without any changes to my game, I updated my CocoonJS from 1.3 to 1.4 and the frame rate of my game dropped from 30 fps to 5! (on iPhone 4 and iPod Touch)

Turning WebGL off improves the performance.

There must be some kind of disconnect here because the launcher demos run fine.

Thanks.