It seems right after i posted here thinking my post would be visible and get feedback it's right at the bottom of the list all of a sudden (and some of those seem to be off topic btw). :(

I posted these a while back in the general forum but the post was quickly lost so i will post here as it's a much better place for the request.

I suggest the following new ept_types for the plugins GUI/Properties as i think these would help make the visual part much more organized, hopefully other developers here will like these suggestions also.

1) Paired/grouped values like you already have with the Common properties for Position and Size. It would be nice to have these available to use for regular plugin and behavior properties also. I have made a few plugins where i have many sets of X/Y values and each needs it's own item making the vertical size much longer than it needs to be so for me this would be very helpful.

2) A separator line. Each item is already separated by a thin line so maybe it could just make that line chosen color and also slightly thicker, maybe with a optional title text. This would be helpful if a plugin or behavior was slightly more advanced and you wanted to organize the properties into a few groups/sets.

I had single problem with the new test in that the exe would not close correctly and remained in the task manager, so i had to force close it. For the GUI however everything seemed to work well.

> Exe exporter won't be coming anytime soon most likely.

Yeah, the more I read this thread, the more convinced of this I become. Or possibly, it will never come from Scirra, but from some developer who wants it done

Yeah same here, i doubt it will happen anytime soon but i guess if the EDK was made available there would then be more chance of it happening.

I am wondering why Construct 2 runs as EXE though which is apparently a redundant format. I quite liked it that way and the fact you could use it as a offline standalone, but with all of HTML5's benefits over EXE then C2 might be going fully browser based in the future by the sound of things.

Two reasons, the first reason is because i want to test the default mode before accelerated in case the players don't have a compatible graphics card.

The other is some firefox plugins need me to allow it each time. I trust C2 of course but i have to do this every session, constantly doing this quickly gets annoying and the other option is i globally enable WebGL which i would rather avoid.

Kyatric, The Runtime you link to is part of what i call the "Plugin SDK" and i guess "Runtime SDK" is what is being called "EDK" but i did not know what you guys were calling it. So yeah i am talking about the Exporter Development Kit (EDK) yes, i figured you/other people would have understood that from my first post so i am sorry if i caused confusion.

Ashley, I fully understand about the time issues but reading some of the comments makes it seem almosty like after having worked on Classic you never want to work with the EXE/native format again.

As for your points against a EXE runtime/exporter you make some good points however a lot of it seems like frustrations maybe from previous experience developing Classic, i really can't comment on that but as for EXE as a format however here would be my own opinions on it.

1) I really don't see people being limited to either windows, mac or possibly linux as a problem. Only untill very recently these were probably the only options people had available anyway.

Also what about Classic which is EXE with DirectX so probably windows only without tools? Why make anything other than a program that exports to all formats if multi-format export is so important. A lot of mobile devices also don't have anywhere near the power of native platforms and you also need to think about things like file size and optimizations a lot more so you have added limitations developing for some mobile platforms currently.

2) That's just down to the people that make the game/program though and OS's now have better security so it's all down to if people are ok running the EXE. Classic could have been a virus but it's not as far as i know yet many people were more than happy run that on their computers.

3) True for many points but as for not being able to port games you could have the argument the other way around and say that some people could not export EXE games to HTML5 because they don't have whatever plugin. Still at the same time there is many plugins available for Classic by 3rd party devs.

Also by saying "a constant thorn in our side. We want to avoid this situation at all costs." you make it sound like there won't be other runtimes than javascript because as far as i know just like EXE's many runtimes would need to use there own programming languages anyway and not be able to base everything on Javascript. The fact that there is technology's like Phonegap is lucky for the HTML5 runtime also because otherwise many of the current mobile phone/tablet export formats would not even be possible.

4) This is perfectly understandable. As i said before it would be great to think that much later into the future a EXE exporter might happen, but replying to your points i don't really see it happening in any other form than a wrapper for HTML5.

As for EXE advantages as well as the point you already made a few others are:

1) One thing i notice people choosing HTML5 over flash saying as a negative point against flash is that it needs a plugin to run, i don't see that as a good point myself, both need a browser to run. With EXE's however you don't need to run them within a browser. Another advantage for EXE is also that it's easy to give them shortcuts making them even quicker and really simple for people to run.

2) With EXE's for games in general the file size is not much of a problem. With web games such as HTML5 you need to make sure they are within a certain size range otherwise some people won't even bother to run them, this is also true for flash games. With web games you would also need web hosting or something like dropbox so people can play them but these have limitations like bandwidth, while costs are generally low this is a additional concern that you don't have with EXE's.

3) To take advantage of HTML5 you really need WebGL right now, you will not only need a compatible graphics card but to update the browser also. A while back there was also talk of security issues with WebGL, to avoid things like that and get speed improvements and visual error fixes etc if they happen you need browser and graphics card updates which makes it a similar process to EXE anyway.

4) EXE's are more secure and often compact, with HTML5 they are more visible and open hence the need for obfuscation etc. Sure you can say that you can rip things out of exe which is true but EXE is much nicer as default and also standalone so they don't need to be run from within a browser.

5) With Classic you are not just limited to games, that's true for HTML5 also but with EXE Classic has shown it's nice for making apps also. I think there has already been a few made with Classic and one good advantage that goes along with this is the fact that EXE is good at linking to the OS for system tasks. Javascript can also for some things and you could make web apps however you are mostly limited to the browser as it acts more like a sandbox. So maybe less of a point than the others but definitely still worth making because EXE is much better for system tasks.

"Adobe have ditched Flash for mobile, and is rapidly being replaced by HTML5 on the web anyway, so I see no reason to develop for it at all."

I would have said it's more like they wanted AIR to be the main adobe platform because it's much better suited for it. Also they will still be updating the flash player just not in a major way. Flash remains very strong on the PC platform though and will for a long time, with Stage3D it's now very powerful.

As i said before Flash/Flex could have been a good platform for Scirra to offer and would be good with plugins also but it's clear like EXE this probably won't happen.

While i don't really agree with your thoughts about EXE or flash i would like to say thanks for at least taking the time to respond back to me as i know you are very busy. Also putting opinions on exporters aside though i think you have done a great job Construct 2 for HTML5 so far so also thanks for a great program.

Thanks for the reply Kyatric but you seem to miss the point of some of what i said though. Firstly i have no problem coding javascript plugins and i don't want to request plugins or need help making them, i have been coding my own long before the manual was available. When i talk about a SDK you will notice i am referring to a "Runtime" SDK which is not available, the "Plugin" SDK is a totally different thing.

To clarify when i say i am disappointed that Scirra is not helping plugin developers i mean because they don't seem interested in taking feedback from the people actually using the SDK. Currently all my requests to enhance the GUI/editor connection for the "Plugin" SDK seem to have been ignored. As i said before though i am guessing/hoping this is mainly just down to the fact that there is a lot of work to do at the moment and these will be added to the "Plugin" SDK later on.

If you are interested the "Plugin" SDK suggestions i made were here -

http://www.scirra.com/forum/plugin-dev-request-edittime-properties_topic45084.html

I am sure that other plugin developers would agree that these would help a lot to clean up the GUI controls side of the plugins and allow them to be much more organized also.

I have also made various Editor based suggestions here -

http://www.scirra.com/forum/a-few-simple-requests_topic45930.html

Also, it was clear from the beginning that C2 was aimed at HTML5 "against" flash and that an exe exporter was a possibility, not something set in stone.

I would actually disagree with that, i think a lot of old construct classic users were under the impression that first there would be a HTML5 exporter, then a EXE exporter/improved Classic updating it with the previous experience and making it much better this time round possibly with OpenGL instead of DirectX. A lot of people probably purchased thinking a EXE exporter was on the way but as i say now from the developers own words it is looking like it won't happen like people were expecting.

I would also disagree about the anti-flash thing because originally it seemed like they wanted to back the new HTML5 however that doesn't mean you need to be against flash/flex etc and totally ignore it. As a coder myself it seems like a odd choice really because flash is a great platform so really it's just cutting away a potential market for scirra and also for people making games with Construct 2 that might have liked to make flash based games.

So yeah i am a bit disappointed after reading this thread and the blog recently but hopefully these doubts will be resolved with time and we will see a "real" enhanced EXE exporter in the future.

8) It would be good if Enable WebGL was available as a option in the Preferences just like Preview browser. I don't want it to default to "On" but that was a recent change so i have no choice but to set it each time i use the program now.

It might be useful to have other Project based options setup like that also so you can set main default choices for things.

It's sort of disappointing reading some of the forum and blog recently because i get the impression the developers are not really interested in making EXE exporter. Thinking there would be one was one of the main reasons i purchased however.

"I'm wondering if we'll need an EXE exporter at all", "what need is there for an EXE exporter?", "I'd prefer to recycle the HTML5 engine."

So it seems like if there is one (doesn't sound likely) it will just be a wrapper which is not so good really.

In my opinion HTMl5 is great but flash is also and still more powerful and and also contained rather than being multiple technology's linking to resources. Reading the blog there is a clear dislike for flash though so i guess that means flash/flex is never going to be a official runtime for it.

Also one of the earlier blog posts was saying how there is a focus on helping coders make plugins and runtimes. Though i wonder how long it would be before the SDK for runtimes is released, the last update was actually that a option to switch runtime got hidden because you can't do it. That makes sense i guess but at the same time it's worrying because i see no news for the 3rd party runtimes feature.

A while back i was coding plugins and requested some features which i think would help other coders also but just one of those was added. That feature was apparently because it was needed for a official plugin though.

So yeah i am sort of disappointed about some things and don't really feel the helping of plugin coders just yet either, but hopefully that is just down to the fact there is probably a lot of work to do and these will be added later on.

Yes, it was basically just as i reported before to make it crash. When loading the project it would crash every time i went to add or move something. Starting a new project seemed more stable however and you could use some of the features however it would still crash a lot after doing certain things like moving the timeline.

The plugin seemed to work but i couldn't test it fully because i think the editor would need to work well for me to do that. The example you posted needed to be edited first but it worked and seemed stable however. Basically when i tested it i was limited to using the animations you had setup in the example.

One suggestion which i think would be useful in the plugin is a way to mirror/flip a animation without needing to use the main editor to duplicate it with another new mirrored version. I don't think there was a option to do that but it would be useful.

Currently i have removed the plugin as i can't use it but i will try the next version when it is released. It sounds as if it will fix the problems i had using the current version. Thanks

I made a suggestion of my own (suggestion 7) before reading this -

http://www.scirra.com/forum/a-few-simple-requests_topic45930.html

My idea was slightly different in that the HTML files would go in folders and then at export you could pick one to use. With that sort of template setup you could then easily make a few HTML's you want to use, add them to folders and simply select whatever one you wanted at export.

This idea would only need one simple editor change also with a new dropdown list or something similar, it doesn't turn Construct 2 in to a HTML designer either because it's still down to the user to make the templates.

With C++ you have limits on the data type values you can use:

signed: -2147483648 to 2147483647

unsigned: 0 to 4294967295

etc, maybe use a long int for the Binary to decimal problem or maybe use doubles then round to int again etc.

Using a string input as a workaround then converting data types could also work.