ACE implementations

Actions, conditions and expressions (ACE or ACEs) defined in edittime.js must each have a corresponding runtime method. In the runtime script you'll find objects named Cnds, Acts and Exps, which you must add your methods to like so:

Cnds.prototype.MyCondition = function(...

where MyCondition is the script name from edittime.js. See the edittime documentation on ACEs for more - it also covers how to write the runtime functions. You must remember to use dot syntax - see the section on Google Closure Compiler compatibility for more.

Implementing conditions

There are four kinds of condition:

Ordinary conditions
These are the default. They are evaluated once per tick (or whenever the event is run). The method is called once for each instance, returning true or false, thus filtering instances meeting the condition. Conditions specifying cf_faketrigger are still ordinary conditions.

Trigger conditions
These specify cf_trigger (not cf_faketrigger). These are not run every tick: they only ever run when explicitly called by runtime.trigger(). This is useful for input events and other on-the-spot events.

Static conditions
These specify cf_static. Ordinary conditions are called once for each instance. Static conditions are only ever called once no matter how many instances there are. You must pick the necessary instances in the condition method. For example, 'Pick random object' is most easily implemented as a static condition.

Looping conditions
These are actually ordinary conditions, but are implemented in such a way that they repeat. The cf_looping flag should be set, but this does not affect any functionality. Instead, the method must 'retrigger' the event (calling event.retrigger()) which runs the remaining conditions then actions and subevents, then returns to your condition again. The event should be retriggered once per loop iteration, then the actual condition method must return false - otherwise Construct 2 will carry on and run the event one more time. A good example of a looping condition is Array's For each element condition.

Implementing actions

Actions are usually the easiest to implement. They do not need to return anything. Just perform the action!

Note you may not affect any of the picked objects in an action (via the SOL methods), except for any objects passed in object parameters.

Implementing expressions

The most common thing to forget in expressions is the first parameter must be ret! The expression returns its value through this rather than by returning from the javascript function itself. Any actual expression parameters follow after ret.

Other than that, expressions are also straightforward to implement. The following ret methods are used to return a value:

ret.set_int(0); // return an integer
ret.set_float(0); // return a float
ret.set_string(""); // return a string
ret.set_any(0); // return a float or string, depending on the javascript type of the parameter


You may use any browser APIs you like in a plugin. That's generally what makes plugins useful! It is best to keep plugins focused, and expose a single API or feature through a single plugin. As described in the overview, the Mozilla Developer Network is a good place to get an overview of browser features and APIs.

The rest of the documentation covers the reference for Construct 2's javascript runtime. These methods may be interesting to you so your plugin can integrate seamlessly with the way Construct 2 works.

Some parts of the runtime are undocumented. This is usually for a reason: it is not advised that plugins use them, since it will cause bugs. Therefore, you should only use the documented parts, in the manner that the documentation states is valid. The fact javascript does not provide encapsulation (public and private like other languages) is not permission to use the "internal" parts of the runtime.