No scripting mode. It would be extremely difficult to implement, way past the realm of plausibility.

However, you can type events using keyboard shortcuts. A, action, c, condition, e, event, s, subevent, then you can type to filter the name of the object, press enter, then type to filter the name of the condition, then press enter, then use the arrow keys/tab to work your way through the expression editor, then press tab twice to highlight finish.

So making an event ends up like pressing: esy enter gr enter "groupname" tab tab enter.

Perhaps sub-events could just be separately numbered 1, 2, 3... at each nesting level?

Ashley Not sure what you mean?

Arima, In the case of 5,000 events you prefer this:

3012

-3013

--3014

---3015

---3016

----3017

Over this?

32

-32.1

--32.1.1

---32.1.1.1

---32.1.1.2

----32.1.1.2.1

The first has no meaning beside counting events. It has no purpose too beside telling someone he/she has an error on event #40,321.

Your highlight idea is a good start/direction but it lacks the point I was trying to make - a mechanism which will show you how deep your current event is.

That's exactly what my idea is - the vertical lines CC has accomplish that in a much more elegant fashion IMO.

Honestly, I can't think of any reason to want to know how deep an event is. That information alone, without the context of the conditions in the events above it is pretty much useless to me. Using CC's vertical lines, I can tell what events are on what level. That system is a lot cleaner and works just fine. If the line of the currently selected event was highlighted, that would be even better.

You also forgot my prediction - events will be able to fold in the future. With my suggestion you won't see the mess you mentioned in the 1.2.3.4.5.6.7.8.9 scenario (have you really gone so deep?)

Even when sub event collapsing is implemented, I would still have to look at it when working with those events! That wouldn't make any difference.

Do I prefer event 1981 to event 5.16.2.1.2.2.5.1.1.6.1? Vastly! Much simpler, much smaller, less keys to press, less likely for a typo, easier to read, much easier and faster to process mentally. Tell me at a glance - which is higher in the event sheet, event 5.16.2.1.2.2.5.1.1.6.1 or event 5.16.2.1.2.5.1.1.6.1? Comparing event 1981 and event 1960 is far quicker and easier.

I don't like this idea. Having worked regularly on an event sheet 10 levels deep with more than 5000 events, this might sound like a good idea in theory, but in practice for anything complex it would be an utter mess.

Letters would be right out because it wouldn't last more than 26 events. For each level, you'd have to add another point to it. So you'd get something crazy like event 1.2.3.4.5.6.7.8.9. It would be harder to read than what's currently implemented.

I think C2 should use what CC has, lines that show levels. Even better, I think they should be highlighted as well when an event in its level is selected, making it easier to spot which one you're supposed to be looking at.

Bert - no. I guess I didn't describe it properly - I have common animations in one object, then the less common ones in other objects. By keeping the less common animations in another object that's not in the layout in CC, it keeps it out of VRAM.

I create an instance of the uncommon animations objects when I need them, and then swap visibility between the common animations object and uncommon animations object as needed.

I've been wanting something like this for awhile, only a little different - basically a drop-down menu in the properties of a sprite that would set if the runtime should load all animations into memory upon loading the object, or only load the first animation. Sort of like how construct classic has a 'load all layout textures at start' and 'load only the current layout' modes, except with animations instead of layouts.

So, there could be an action to load or unload animations by name (they could load in the background while other stuff is happening), and an action to dump all but the current animation from memory. If the user used 'set animation' to an unloaded animation, then it would load that animation then. That could probably cause a pause, but MAN would that feature be useful to me!

My characters in loot pursuit have thousands of animation frames between them, many of those only being used once in the entire game. It's extremely impractical the way I'm having to do it now by sectioning off animations into separate objects and creating/alternating visibility between them for memory savings.

It works here too! Thanks Ashley! :D

The solution is not appmobi (which by the way is better than nothing) that is another hack on top of an hackish technology but a real iOS and/or Android exporter which, not only me, but a large portion of your users would be more than glad to pay for. If this is not possible (I understand that it's not an easy job) at least make an exe exporter like construct classic, not directX but SDL/openGL to allow for multiplatform development: you'll gain thousand of subscribers.

You have the best community, the best documentation on top of the best tool, what are you waiting for?

I understand the frustrations and concerns, but consider it from Ashley's point of view. He already has a mountain of work to do! The IDE is incomplete and missing a lot of features like functions and containers - those need to get implemented first before any work on other exporters can happen.

I think HTML5 was the best choice to start with. If he had started with an iOS exporter first instead of HTML5, it would've been a vastly more limited audience that could have used C2 from the start. With HTML5, everyone can use it even if it currently isn't as fast as it could be on some platforms. Also keep in mind the increasing speeds of hardware and improvements of software - iOS 5 was a 2000% speed increase for HTML 5 over iOS 4!

I know Ashley makes it look easy with the weekly releases, but remember he's one man coding C2 all by himself! He still has to sleep! Patience! :)

also I do remember similar bug in construct classic, kinda like the every X ms precision bug :)

Sorry, I should have quoted what I was referring to. The every x ms imprecision in CC wasn't a bug.

Argh, completely misunderstood. Sorry! It's clear now.

septeven I don't understand what you mean. C2 comes with a touch object. How is it not supported? It's not even a third party plug in, it's built into the program.

Technically, that wasn't a bug. It was just kind of unintuitive.