Many of us use CocoonJS. What problem in particular are you having?

The first value sets each particle's opacity on creation. The second value sets the range in which its opacity can change after it's been created per second. One such usage lets the particles twinkle.

All of the particle effect values follow that same format, by the way: the top values are for on creation, and the bottom values are for during its lifetime.

There's no way I can think of to do what you want, though. The Fade behaviour only applies to the whole particle object (the emitter, basically), so it'll fire off once and be done with it. It doesn't affect the individual particles

To sort-of get what you want, I suggest setting the particle opacity and starting size very low (say, 1 and ten), then setting the growth rate quite high (about 80-100). It's not perfect, but it could work for something like a jet of flame or smoke.

Your other option is to create your own emitter using the Bullet behaviour. That way you have direct control over the sprite animations for opacity, or just use the Fade behaviour. It'll require a bit of messing around to get the same functionality as a particle emitter, but it's effectively the same thing (just with a much higher system load).

Example capx (r135).

You've got some weird plugins going on there, so I can't open your capx. But it should be easy enough: Once you've taken your snapshot, create a new background object, set it to the size you want, and Load image from URL -> CanvasSnapshot.

Also, there is an option missing for condition object background, and selected event background doesn't seem to change anything (it stays that orange-ish colour no matter what I set it to).

There also doesn't appear to be an option to change the "add action" text colour, unless I'm just missing it.

Some of the new theme colour editing options are backwards. Selected affects items when they're not selected, and vice versa. In particular, conditions and condition object text colours.

Great aesthetic, and quite relaxing.

A few suggestions:

• The coin clinking noise is perhaps a little too harsh; it doesn't quite fit in with the general peacefulness of the game.
• It's unclear where the top and bottom borders are.
• Some pickups appear right on the edge. I don't know if this is by design or not but it feels a little odd when it happens.
• "Your only obstacle is yourself" is untrue: the first thing I did was test if I could wrap around the edges of the stage and I couldn't.

I've encountered the same thing. I can only assume it's a bug.

WebStorage works on everything. You don't have to use the Windows 8 object.

Come on, I can't believe you've actually looked. The search "spawn random" comes up with dozens of threads - many of them solved - on the matter, with multiple approaches.

In general, with the free version of C2, the approach is: generate a random variable (rounded to nearest whole number) within your desired range; then create a bunch of events to spawn objects, each triggered by a different value of that variable.

With the paid version, you get access to families, which can do this all for you in a single event.

I'd also seriously recommend against using set frames. Why go through all that hassle for a bit of trickery?

Using rotation towards a dummy object that uses the drag-and-drop behaviour, you can quickly put together a rotating dial as you can see in this example (taken from a metronome app I made a little while ago).

For the directional emboss (which doesn't rotate), I used an object with transparency overlaid on the dial. I think the effect is convincing enough, and I imagine you could extend it to some simple lighting effects.

If you are totally set on the masochistic practice of creating 30-odd frames for your dial, you could create an event to set its animation frame every tick to int(Dial.Angle/10)-1, with the frames loaded up in the correct order and the animation speed set to zero.

Ashley I've followed the best practice and I am using a collision object. This particular situation came about when I was trying to implement a sliding animation in a game, which needs more width than the standing animation to keep the sprite from overlapping the wall during the animation.

I already have a workaround in which I check which side the wall is on and move the collision object out by x pixels. It's not really a matter of finding something that works; I posted a thread about this in General and the consensus was that I should report it as a bug because it's so consistently... inconsistent - it's spot on every time there's a wall to its right. California thought it might be linked to some greater issue.

I do get your point though - it's simply not designed this way, and if it's not a straight-forward fix then I'm totally okay with that and I'm prepared to work around it. I think the concern (California's, at least) is that whatever its design is, is affecting other parts of the engine.

The jittery movement is caused be a small "fall" taking place (courtesy of the platform behaviour) after you set the X position to +1.

I found it easiest to actually use the platform behaviour itself. Find the angle of the platform beneath the player, and, based on that, simulate movement left or right.

Here's an example I made recently for someone else, based on the platform template. I've since applied it to my own current project and it needs a little tweaking, but the basic functions work fine.