Basically.

Ash, I'm concerned about something I noticed while looking at the Keyboard plugin. Will plugins have to be independently created for each exporter? I noticed that jQuery is used for key events in the keyboard plugin.

Arsonide: good tutorial but the expressions are wrong: the return value from expressions is ignored. You need to write PieExp like this:

Hehe, can you tell I got confused there? I thought I'd read something about expressions being broken, and I noticed the format changed - at least in the text object, between AC and E, and I couldn't figure out from the text object's expression how it was tied with it's "function".

In a moment I will update the file with your section so there's not more confusion.

Alright guys. I put all I currently know into this puppy. It's a trimmed down keyboard object with a few example ACE entries in it and a lot of comments. It is likely very buggy, but it should familiarize you with everything. You can use it as a starting point if you like, but realize that I'm just feeling my way around blindly. Now that I'm fairly familiar with everything, I'm going to try and implement simplex noise as a plugin.

The two parts you want to really familiarize yourself with mainly are the ACE definition macros in the edittime file and how those relate to the ACE definitions in the runtime file. That should get you well on your way.

http://dl.dropbox.com/u/1032313/SDKTut.zip

I am preparing a "template/tutorial" plugin. It will contain one action that pops up an alert, one condition that compares a number with the number 17, and one expression that outputs the string "Pie".

The template/tutorial plugin is extensively commented, so you can understand most of the sections in the SDK. I'll post it here by tomorrow morning.

EDIT: I think I will call it the SDKTut Object, seeing as how Ash might one day decide to make his own template object with better comments, and I don't want to cause any confusion.

OK, I'll see if I can put together a quick template at some point.

In the meantime, the keyboard object seems to be the best place to start. It's the most barebones of all the plugins.

I figured these belong in their own thread, questions directed straight at Ashley that everybody needs to know. There perhaps needs to be an engineering section as well, as I've already started picking apart the Javascript within Construct 2. I have two questions to start us off that are pretty important.

• Within GetPluginSettings(), there is a section for "flags", and scanning the existing files available, I can see pf_singleglobal, which appears to be for singleton objects like Keyboard. I have also found pf_texture, pf_position_aces, pf_size_aces, and pf_single_aces, which appear to prepare Construct for actions, conditions, and expressions using these things, but I'm not sure. Could you give us a full list of these flags please? Preferably with a short explanation of what each does.
• In the property list, there is within each property, a type to describe what kind of property it is. Could we also get a list of these? (Examples: ept_text, ept_font, ept_color, ept_combo)
• A list of return types would be cool too, though I could probably guess them based on the original SDK. (Example: ef_return_string)

EDIT: I just found the answer to most of these questions in a file that I didn't know even existed, because I'm stupid and Ashley put it in the original extension thread. There is three "preclude" files in your html5 folder that define all of these flags. I did not know about them, they are there.

However, I think having this thread so that all these little tidbits of knowledge are in one spot is still a great idea.

We've been working on generating persistent ship traffic. (Procedural AI ships that stick around in a sector for a while, and then move on.) Been having some trouble generating the external model of the ship, but work is progressing slowly.

I am replying now because we have had an internal discussion on whether we want to move to Construct 2 or not. We are one of the few large projects that would be impacted by the transition. Since C2 will have no backwards compatibility, we would have to restart from scratch - however, a lot of the code concepts we are more familiar with now, and all of the art is complete...so it would likely be quicker. That is the downside, but the upside is obvious...with the universal formats being used in Construct 2, the Linux crowd will show up and start pumping out some sick plugins, which could REALLY help Void Runner in the long run. Of course, the downside is pretty huge for a two man team - we were fairly disappointed with the decision to drop 1.0 after so much discussion of it. We had no compulsion to migrate up to 2.0, as we assumed all the quirks of 0.9x would be worked out at some point, but obviously things have changed.

Our decision was to keep a close eye on how the community surrounding Construct 2 evolves, and to familiarize ourselves with the program itself, but to stick with Construct 0.92 for the moment. It's the version we've been using since we started. If the community flourishes, we will begin a painful migration process...if not, we won't.

Ashley I'd like to write some articles involving procedural generation methods so it's easier for other people to do. Possibly do a write up on the Perlin Noise plugin and the dungeon generator.

Also there are a lot of absent pages that I've needed over the years that I could add. So editor would be awesome.

edit- Bah, looks like Sourceforge recently did something with my account, I have to go but I'll clear it up later tonight.

Ah yes. I've got this bookmarked. Wish he'd keep going with it, looks like he lost motivation.

Spent the last day or so redoing the generic walls and floor tiles we had. They now look a lot better. Was pretty rough getting this to play nice with the generator.

<img src="http://content.screencast.com/users/Arsonide/folders/Jing/media/fe032cf8-6809-4c30-bc13-01ab2d4a64ba/2010-11-23_0601.png">

The ship internals are in a beta state, we're going to spend time working on adding machines for a while, things like the engines, artificial gravity generators, crafting equipment...stuff like that. We can't really flush out the data system until we have more "things" to work with. But speaking of gravity - I have made the player a physics object, and made gravity affect him. Good times were had bouncing around the ship in zero-g.

<img src="http://content.screencast.com/users/Arsonide/folders/Jing/media/9caa1314-4c76-4056-97e0-1b15584b9a62/2010-11-18_0507.png">

This is a pretty simple version of data in its infancy. I am hooking up a fan to a diagnostic console. In the future the console will show if the fan is on or off, which is useful when you have 20-30 fans running that all require frequent repairs and maintenance. We decided to simplify the data system a bit, more for the player than anything. Wireless connections will open up the possibility of hijacking enemy signals and messing with them, as well as other possibilities.

I don't think complexity must be avoided, it just becomes more quirky. Not like "OK, gotta take that out of the game", more like "OK, guess we'll have to do it this way" instead of the other way. both ways have the same result, just one might trigger said glitch, the other is fine

This is my experience to the letter.

Keep in mind Arsonide is a developer of a procedural space game with infinite (for all practical purposes) universe, that had moved away to try out Unity, and come back to Construct with continual updates on the development to his game for the last several months. Seems a large investment of time for something if he was so sure it wasn't going to work in the end. I don't think he was trying to deceive you, just warn you that stability is an issue at times. It's just the analogies he used seem to indicate it's impossible to work with construct without it all ending in disaster, which I personally disagree with.

Well, I'm using .91 for my project, and am too paranoid to upgrade the cap to .96. That said, I'm like a year behind on the updates, which explains my experience with stability.

Construct isn't UNSTABLE, by any means. I'm just saying, it does have it's quirks and I've learned to live with them. Its power certainly outweighs them.