Why not just make it "Every 250 miliseconds"? Then you can just enable and disable the group at will.

In the worst case, we can just .zip everything.

Which lucid is talking about in his post. You see, the pairer plugin isn't polished just yet.

Containers are permanent, quite often we want to change pairs.

Nope, it is additive, but if you use white sprites...

You can create a template project which you can then reuse for your new projects.

stack (LIFO - Last In, First Out) - data is layered on top of each other, the oldest at bottom, newest at top, useful where you need layered stuff such as tiers of units, defenses, whatever in games. Moreover, GUI windows often are stacked on top of each other; you have to close topmost to get below, so you don't accidentally alter something below the active window. The stack object would help ensure this. Also it could be used as game resource storage or an active game element (train wagon coupling, where you have to uncouple outer wagons to get the inner one).

queue (FIFO - First In, First Out) - data is queued, the oldest element is the first one to go out, which is very useful for tack/order queuing, turn management (turn based games!!), AI routines and so on. You would add new elements and know that eventually they will be processed. This would make turn based games and AI development MUCH easier.

As for array changing size, does it change size when an element is removed? I think that you have to manually remove the element. Moreover, whenever you take an element, you have to move ALL other elements to their new positions etc.; stack and queue would take care of that automatically.

Does it have to be text blitter? Wouldn't it make sense to have an universal blitter, which could be used for text and imagesets alike?

I know blitting is probably a little ineffective, having to read the same big image for each smaller bit of graphics to be blitted seems ineffective compared to just drawing smaller independent images. Perhaps it would be better if it was an one-time thingy; load an imageset, chop 'em up and store each piece into their own textures, which would then be referred for the remainder of session (or until dumped).

Well, anyway, I'm not an expert and blitting feature is not so strongly requested, since there are alternative methods of drawing graphical text. I'm sure others will digress, though.

Array is not really flexible when it comes to dynamically adding and removing elements (which hashtable does well, but is somewhat limited; ordering etc.).

Stack and queue, please! (FIFO, LIFO, etc.)

The only way to rotate the tiled background is to rotate the layer it is on. You can put it onto its own layer.

Awesome job so far!

Everyone has to begin somewhere; most begin with the Ghost Shooter tutorial that is supplied to them. As part of the learning process, they create a GS clone and experiment with it - different sprites, actions etc.

While just altering another game (demo), altering it slightly and then showing it off as your own is FROWNED upon, we should realize that the start of learning process is imitation. If we burn them for cloning, we risk discouraging them from Construct or game development altogether.

But I agree, GS clones do not belong to 'Your Creations'. It is not a creation, it is an alteration, a schoolwork taken home. Give 'em their own section, say 'Beginner stuff' and just stick the junk in there. Or name it 'Demos' or whatever. Actually, split the creations forum into categories: demos (proof of concept, simple demos, GS clones), games (actual playable games), utilities (zomg 3dmesh tool) etc.?