Scripts in actions
Scripts in blocks
- Right-click in the margin of an existing event block and select
- Click the Add... menu at the end of a group, or the end of the event sheet, and select Add script
- Use the J keyboard shortcut when an event block is selected (note if an action is selected, a script action will be inserted instead)
Remember that the event sheet runs all events in top-to-bottom order every tick, so a script in a block at the top level of an event sheet is run every tick (as if it was an action in an Every tick event). Often it is more useful to use script blocks as sub-events, which only run if their parent event block was true.
Code written in either a script action or script block is actually run inside an async function. This means your code can use the
await keyword. For example you can await the result of a fetch over the network.
Note that the rest of the event sheet will continue to run while
await waits for its result. In other words,
await will then run - which will be after the following actions have run. You can change this using the System action Wait for previous actions to complete: this will wait for any code blocks before it to finish before running the following actions.
Since code in a script action or script block is run inside a function, you cannot use
Instead you can import things in to a script file with the purpose Imports for events, normally named importsForEvents.js. For example if you add the following line in the Imports for events script:
import * as Utils from "./utilities.js";
...then all your code in script actions and script blocks can use the exports in Utils, e.g.
Using the runtime interface
All scripts in the event sheet can access a special
runtime variable which refers to the runtime script interface. This provides functions and properties that lets your code access and control Construct's runtime. This also includes ways to closely integrate code and events, such as iterating the instances picked by the current event.
A very simple example is shown below, which can be used to show a dialog box with the project name in it.
Accessing local variables
A useful way to pass values between scripts and the event sheet is to use local variables in the event sheet. These can be accessed by both script actions and script blocks using the variable name
localVars. This is set to an object with a property for each local variable in scope. The available local variables are the same as are available to a Set value action in the same place. This includes any parameters for event sheet functions.
For example a script in an event group with a local variable named temp can access the local variable using
localVars.temp. A useful pattern is to use an action to set a local variable to an expression, and then read from it in a following script action. Alternatively a script could calculate a value and assign it to a local variable, to subsequently be used in the event sheet. It could also be used both ways at once, both reading the variable and then assigning it.
localVars excludes global variables, which are available via runtime.globalVars instead.
localVars is also unique to scripts in the event sheet - script files cannot access it, because they do not have a scope in the event sheet.
Any exceptions, or rejected promises, arising from a script in an event sheet will be caught by the Construct engine and logged to the console with information about where the error came from. This means unhandled exceptions or rejections will not crash the game (since browsers stop running scripts if they encounter an unhandled error). However you should keep an eye on the browser console to check for any unexpected errors. For more information see the section on debugging script.