As far as I know, copying and pasting between layouts is fine, between .caps is not.

What would you want to combine from MMF, if it doesn't do per pixel collisions for physics either, and for what reasons? The bullet behavior in C2 has a bounce option, BTW.

— - What I generally do to find crashes is save a copy, then delete code section by section until it stops crashing. Then narrow it down to find out what exactly is causing it.

You need to add the mouse and keyboard objects to the project first. It's the same way you add a sprite in the plug in list.

Metal_X - Ashley has said of that JavaScript both isn't fast enough and doesn't allow for certain operations that they used to make construct classic's collision detection so fast.

AnD4D - I'm a little surprised that works in MMF - have you actually tried it? As far as I thought I understood it, physics are generally a polygon based affair, or straight math in the case of a circular object. Construct classic has per-pixel collisions, but it requires the use of polygons for collisions when using physics, so it wouldn't take seconds regardless.

Technically you could fake it by using physics object 'tiles' to make up the level, but it's true it wouldn't be a simple as you describe - you would likely have to set up the levels by hand the same way you would put together a level based on sprite tiles.

Yeah, topics like this are fine. We don't censor discussion of other tools here.

Ashley has said they're going to look into making an EXE exporter when awesomium 1.7 comes out. Directcanvas and cocoonJS are also in the works to improve mobile performance. As for per-pixel collisions, why do you need them?

My recommendation, of course, is to stick with C2. ^^ If nothing else, the ease of development I think is far more important than the need for per-pixel collisions - which is something there's a good chance you can fake, anyway.

konjak Jayjay - Actually, I think Dima111 is right! I tried it with a blank .cap - 6,674 bytes, created a sprite, added a condition for the sprite, then deleted the sprite, which deleted the condition automatically and resaved - the resulting .cap is 6,954 bytes! Deleting the event first and then the sprite instead results in 6,697 bytes.

It would appear both ways that construct is not cleaning up after itself properly. Thanks for the idea Dima111, I had been wondering what caused that for ages!

lucid R0J0hound if either of you happen to work on CC again, any chance of this bug getting fixed? And though I realize that this might not be something you can devote the time to doing, you have no idea how much nicer it would be for me working on loot pursuit if you could get it to also clean up the garbage that was left from previous versions so I didn't have to wait 7 seconds every time I edited something on that event sheet! ^^

Also, Arima, if you've once had event sheets that take MINUTES to open, I probably have no serious memory leak issues to worry about for quite a long while, haha. Nothing I've opened in Construct has taken me longer than a second or two.

konjak - I think that's a separate issue actually. I think the memory leak itself is restricted to the image editor, the number of objects, the number of objects in a layout and possibly the number of animation frames in those objects. The event sheet taking 10 minutes to load seems to be completely unrelated. :/ It doesn't even make much sense, because the event sheet that takes 10 minutes to open is about 6000 events, and yet another event sheet with almost 2000 events takes 5 seconds to open. I have no idea what's going on there, but it seemed to take longer after having tried to split that event sheet up into multiple smaller event sheets, and then recombining them.

Ashley - What about a way that we could switch rendering modes at runtime via events? That way we could do a check for if the frame rate is really low with web GL, then we could switch to canvas 2D instead. Is that sort of thing possible, or does it have to be done at the start when the page loads?

Dima111 - it sounds like you've encountered one of the dreaded memory leaks. Does the problem happen immediately after startup and loading the file? Because if you're willing to upload it, that might help one of the people maintaining construct classic fix it.

However, I'm almost entirely sure you're incorrect about construct being able to handle 1500 objects. The fact that you have 1500 objects, from my experience, is why you're getting that error message about invalid arguments. The more objects construct classic has, the quicker the memory leak will crash the program. I'm almost positive that the memory leak is involved with the image editor and how many objects, and possibly animation frames, a .cap has. The only way I've managed to get around it is to repeatedly close and reopen construct after editing a few animations to reset the memory leak.

I hate to say it, but I think you're trying to make a game that construct classic simply can't handle. Why do you need so many objects?

They've said it's a planned feature, they just haven't gotten to it yet.

— - ARGH NO!!! I tried that, and as a result, loot pursuit has LITERALLY taken over a YEAR LONGER than it would have if I had learned to use construct and its features properly before I started!!

Start with smaller projects and play around with prototypes of larger projects, but don't start anything substantial until you've learned the tool!