... Hm. Well, although you've almost completely shot me down, Ashley, I'm still going to try my hand at it to see what can be done. Thank you for your time.

Nesteris, I would, but that'd ruin the point of making it in the first place, I would rather work off ThreeJS if I were to make my own engine.

But, ultimately, I'm still going to try this. It may not be fully compatible, but it's worth it.

Nesteris, it would be quite difficult, but it'd be interesting, and worth it in the end, I'd assume.

R0J0hound, You're right, and I believe the same problem exist before now with a similar project. I think I might start from that, using v8 and sfml for testing, but I will also try to look for more open source projects that pertain to the same idea. It's unlikely that I'd be able to port v8 to even PSP very effectively, but I'll try, regardless.

I haven't got the chance to actually look into the code that make up the exports yet, but this should be fun. I mean, it couldn't be any harder than doing the same thing if I were to design my own engine. The only thing that'd probably make this different is the fact that this is more interesting to a bigger collection of people than designing my own engine would be, and the fact that this would cut out the rest of the work load.

I'll keep looking into this, and I'm particularly interested in what kind of information Ashley might be able to add to this if he wouldn't mind reviewing the topic. I want to know my limits fully, and he could probably give me the best possible answer.

Needless to say, once I learn more and find if it's possible I'll make a working example, even if it's not the best.

Firstly, before I go on please let me apologize for the possible sloppiness of this post, I'm writing it on my smart phone.

What I'm wondering is if anyone thinks it would be a good idea or if anyone knows if it's possible to make exports for Construct 2? Because I was recently inspired to use my knowledge of programming to make a compiler which would take Construct 2 programming and recompile it as code that is natively compatible with a platform and possibly beyond that, and actually compile to a full app/game compatible with said system. I would choose which system I'd make this for (most likely working with C++, obviously), but I don't want to think about starting before I know if I can make it an applicable exporter for Construct 2.

Many of you may not be so interested in the idea that I have because if I make it I'd probably base it on old systems that most people wouldn't play anymore (between GBA to PS generations).

I know that compilation is possible, that's obvious enough, but not what I want as a whole. What I want to be able to do is make it so that you can include plug-ins in the game you're making within construct 2 that'd better allow you to take control of this.

I figured this would be the best place to post about this project, but I'm willing to move it if anyone thinks I should, and if anyone has knowledge they'd like to share about the topic, it'd be greatly appreciated.

Using wait and every x seconds like this is bound to cause problems ^^".

Actually, that much works quite effectively.

Since Construct 2 is made to work with standard browsers, to officially support CocoonJS would mean having to maintain a separate batch of workarounds just to get things to work within it. And if they go this route (which they already tried), if Ludei decides to change something in their framework and it doesn't get clearly/accurately communicated to Scirra, there will be a bunch of angry users complaining that CocoonJS support is broken in Construct 2.

Yupp, this is definitely the reason why it happened. It should also be noted that it'd probably be best for Scirra to focus on the ability to make games in Construct 2, rather than focusing too much of their time keeping exports working when they're easily broken. If they hadn't chose this I would have probably stopped using Construct 2, because it was this same kind of choice that turned me away from GameMaker: Studio.

Construct 2 is meant to be an environment where people can design games that work well, play well, and can make them simply, with ease, even with little game design experience. This is how it should be, this is Construct 2's strongsuit, and what makes it a good engine. I'm definitely against anyone saying that Scirra should focus on supporting exports that are difficult to keep up, because it'd significantly take out of the time they could be spending making the engine better in the places it really matters.

Crosswalk isn't bad, it runs quite well, and CocoonJS still exists, it's just deprecated. That's how it works. As professionals they have to make tough choices, and this is definitely the best of the options they had.

Well, if anyone has this problem later, think about checking the way you're referencing objects. It's odd that this adjustment I made was capable of fixing my problem, but the reason why it wasn't working is because I wasn't referencing objects correctly before the conditions that I'm actually showing.

Fixed it, but redundancy was not removed, unfortunately.

Basically, my problem is that for some reason, somewhere in my project I must have broke it, because in order to get this to work:

I had to repeat the same condition check. I don't know if it's just my system or what, but this wasn't happening the other day, so I'm terribly confused and angry, because this is happening all over the place.

It's impossible for layouts to be within layouts, or for them to be inter-connected in anyway, e.g. multi-layout editor, in Construct 2.

If you look back enough there's several threads I and other people made asking for Multi-layout editors and such but Ashley said it's impossible with the current architecture of the engine.

it's possible in Construct 3 since we'll be getting an editor SDK, but even then it's up to some genius to make it possible and not Ashley.

Your best bet is to make a save state of the game when switching to the pause menu and just loading the state when you exit the menu.

Rather than using save states I'll use an array to store the progress of the game, because save states won't do what I need it to.

So two layers can't run side by side... It seems like it'd be an easy task. Set up a layer that connects to a layout in the GUI and make the script that'd run the other layout run at the same time the layout you're actually on runs. The GUI would tell the engine to include the objects from one layout in the other, so you could include the event sheet that the other layout uses within the event sheet of the one you're actually on.

I'd have to take a look at Construct 3 later to see how that'd work though.

I also had the idea of just throwing all the objects I need for the menu in a folder and when I create a layout that uses the menu, create an event sheet that controls the object's positioning and then make them invisible when the menu isn't open, but that might become pointless.

I'll just go with your suggestion...

Not really what I was looking for, but maybe the only option? I think there should be a way to include layouts within layouts though..

Thanks a lot! I'll look into that!

I don't know if this is possible, but I'm wondering if someone has achieved drawing one layout inside another. The reason I want to do this is so that I can design a pause/inventory menu for my game that I can just link back to without creating a new layer in every layout or switching layouts

It wouldn't be a terrible alternative to have to switch layouts for this, but it'd be a lot easier just to be able to replace a layer in each game map layout with the pause menu layout.

If anyone can help with this, that'd be awesome! Thank you!