Ashley's Forum Posts

    • Post link icon

    Last updated: February 5th 2025

    In Construct 3 r391 (released 14th May 2024), we introduced a new addon SDK, which changes the way plugin and behavior runtime scripts are written. This post outlines why we need to do this and how the roll-out of the SDK v2 and phase-out of the SDK v1 will work.

    Unmaintainability of existing SDK

    Construct's original addon SDK is not sustainable. Plugins and behaviors can access internal details of the runtime, mainly because the JavaScript programming language has historically had weak encapsulation features. Despite our SDK documentation warning not to do this, a number of addons have been published that do this anyway. While accessing internal details might seem like a good option to get things done in the short term, in the long term it causes disaster, ending up ruining customer's projects as addons permanently break. This is because in the long run, all internal details of the engine eventually are changed, replaced or upgraded, and this usually breaks addons that access internal details; the changes may then be impossible to reimplement as the internal details have fundamentally changed, or it may simply be that years later the original developer is no longer around and so won't update it. In the long run this harm can outweigh any good the addon did in the first place. This problem is already occurring, with some Constructs update breaking addons, it has already been a severe problem in the past, and it will likely only get worse with time.

    Introducing SDK v2

    We aim to solve this problem and ensure customer's projects can continue working even in the long term without maintenance by the addon developer. We're doing this by introducing a new and redesigned addon SDK v2. This uses encapsulation to ensure addons only use a long-term supported API, which is the industry-standard approach, including with most other game development tools. Ultimately we will retire the addon SDK v1, but phasing it out will be a long process. This is to allow addon developers time to migrate, as well as co-operating with addon developers to ensure the SDK v2 covers all features where reasonable and feasible. However developers should be aware some internal features they were using may not have an API created for them, as we do not want those features to be accessed by outside developers, as it is not maintainable to do so; in this case, unfortunately the addon developer must carry the responsibility for ignoring the warning in our SDK documentation, and they will have to retire their addon and customers will have to move to alternative features or workarounds. We will do our best to avoid such cases wherever possible, but the warning in the SDK documentation was there for a reason, and these addons were likely to end up permanently broken in the long run anyway.

    SDK v2 design

    Construct already has a broad, long-term supported JavaScript API in its JavaScript coding feature. This was introduced in 2019 and was specially designed with modern encapsulation features to ensure it is robust in the long term and avoid the same maintenance problems that plague the addon SDK v1. Rather than creating a separate API, the addon SDK v2 is implemented in terms of the existing JavaScript APIs, unifying both the addon SDK and the scripting feature, so code is written the same way for both.

    This approach has several key benefits, including:

    • Adding a new API makes it available to both the scripting feature and addon SDK at the same time, making it quicker to improve both. This also avoids the problem of the documented SDK methods lagging behind the script API features (such as with access to collision APIs in the past).
    • In the long run, new API improvements for the SDK will make the scripting feature more powerful, and vice versa. There have already been some API additions for the SDK v2 that benefit the scripting feature.
    • The API only needs to be documented once, rather than having two sets of API documentation for runtime methods.
    • As addons are implemented directly on scripting classes, there is no need for a separate script interface class - the addon class is the script interface.
    • It allows for writing addons with TypeScript, similar to how TypeScript can be used to write code in projects.
    • People already familiar with Construct's JavaScript coding feature will find it much easier to develop addons, and vice versa.

    Note that this only affects runtime scripts for plugins and behaviors. Effects and themes have no changes with the SDK v2. Editor scripts and JSON files for plugins and behaviors have only very minor changes, and DOM scripts and wrapper extensions do not need any modification at all.

    Getting started with the SDK v2

    The following resources are available to help addon developers write new addons using the Addon SDK v2, or port existing addons to the Addon SDK v2.

    SDK samples

    All the sample plugins and behaviors in the addon SDK have been ported to the SDK v2. There is also a new 'basic bullet' sample behavior with the SDK v2. You can find these on the Construct Addon SDK GitHub repository, under behavior-sdk/v2 and plugin-sdk/v2. You can also see in the commit list a set of commits to update each sample plugin and behavior to the addon SDK v2, such as this commit for updating the singleGlobalPlugin sample. These show diffs that highlight exactly what needs to be changed to update an addon.

    Documentation reference

    The Addon SDK documentation now covers the Addon SDK v2. A full reference on the APIs specific to the Addon SDK v2 is now available in the Addon SDK interfaces section of Construct's scripting reference.

    Porting guide

    The Addon SDK documentation now includes a guide on Porting to the Addon SDK v2 to help addon developers upgrade existing addons to SDK v2.

    Publishing

    Construct has had support for the Addon SDK v2 since Construct 3 r391, a beta release that came out in May 2024. The first stable release with support for SDK v2 addons was r397 (June 2024). Ported addons can now be published and can support all Construct versions r397+.

    In the Addons section of the website, there is a checkbox labelled Uses Addon SDK v2 when editing an addon. If you distribute your addon here and have updated it to use SDK v2, be sure to check this box; this then ensures it is listed when using the SDKv2 addons only filtering option, which will eventually be enabled by default and therefore hide all old addons using SDK v1 by default unless this option has been checked.

    New features in the Addon SDK v2

    As part of our work introducing the new addon SDK, we've done a range of upgrades and added support for new features. These include:

    • Full TypeScript support for addon development, covering both editor and runtime scripts - see TypeScript support in the Addon SDK documentation
    • SDK v2 addons can now be installed by dragging and dropping the .c3addon to the main Construct window
    • Set a minimum supported Construct version for addons
    • Editor type and instance scripts, and runtime plugin and type scripts, are now optional, which can help make it simpler and easier to develop addons
    • Autocomplete for tag parameters (via "autocompleteId" option for string parameters)
    • A new drawMesh() method for flexible 2D/3D rendering
    • Addons can be set to not support worker mode to force any projects using them to run in DOM mode (although supporting worker mode is strongly recommended where possible)
    • Access to HTML layers to insert custom HTML content (including custom canvas elements, e.g. to insert a 3D engine canvas in between Construct layers)
    • New "combo-grouped" parameter type

    Roll-out timeline

    Replacing an SDK is a complex project, and also requires addon developers update all their addons, and then all customers install the updated addons. We realize this is potentially a lot of work for addon developers. Unfortunately this is a necessary part of the project, but we are providing a long period of time before the phase-out of the old SDK to allow plenty of time for this work to take place.

    The timeline is subject to change, but we are guaranteeing at least the following time periods before any action is taken - so if it changes it will only be to delay steps on this timeline.

    • Milestone 1: beta release of the addon SDK v2 (in r391 on 14th May 2024).
    • Milestone 2: stable release of the addon SDK v2 and all documentation complete (in r397 on 24th June 2024).
    • Milestone 3 (we are here): Construct will start showing compatibility warnings when opening a project that uses SDK v1 addons, prompting the user to update them, or contact the addon developer for an update (in r421 on 7th January 2025).
    • Milestone 4: Construct will remove support for SDK v1 addons. The addons will no longer be loaded in the editor, and projects using them will fail to open and report that the addons are not supported and need updating. This will be at least 6 months after milestone 3 (not before July 7th 2025). Extended support for SDK v1 addons will be available beyond this date with an LTS release (see below).

    LTS release

    Further to the above timeline, we are planning a Long Term Support (LTS) release to further extend support for SDK v1 addons. The last stable release of Construct to support SDK v1 (just before Milestone 4) will be made an LTS release and supported with essential fixes and updates only for another 18 months.

    Therefore addon developers have, as a minimum, over a year to update their addons (from May 2024 to to July 2025) to support new versions of Construct until Milestone 4. Further, customers will be able to continue using a supported version of Construct with SDK v1 addons for a period of at least two and a half years (from May 2024 to the end of 2026), as there will be an LTS release at Milestone 4 to extend support by another 18 months.

    We will review this schedule over time and milestones may be delayed if necessary, but we are publishing this as a guide for addon developers to plan with on the assumption that this schedule will be adhered to.

    Conclusion

    Construct will ultimately drop support for the Addon SDK v1, so addon developers should now be actively updating their plugins and behaviors to use the Addon SDK v2 and publishing these updates. We realise this could be a significant amount of work for some developers, but we strongly believe this is a necessary step to provide customers confidence that their projects will continue to work in the long term. Improving customer's trust in third-party addons should also encourage adoption of third-party addons, as there will be less cause for customers to avoid them entirely for fear of compatibility problems. Finally, we believe the SDK v2 is better designed and easier to maintain, and by unifying the addon SDK and scripting features, will allow both to be improved much more quickly than otherwise. We ask for addon developer's patience and co-operation as we go through this process.

    Tagged:

  • It's not currently supported (the way picking works with custom actions doesn't map straightforwardly on to a function call in code), but you can probably do it indirectly by calling a normal function which then calls a custom action.

  • Please direct your complaints to AMD, whose software is the one that is broken. Or try one of the other things I said - you haven't commented on whether WebGL or WebGPU renderers affect this, and they may well do. If you don't try my suggestions then it is not possible for me to help any further. Please see also the Forum & Community guidelines. If you continue to blame us when it's not our software that is broken, and you don't co-operate with my suggestions, then the thread will be locked.

  • I would advise to do what I previously said:

    Try to get in touch with AMD if you can, otherwise try filing an issue with Google to see if they can help. Maybe also turning on/off WebGPU mode will help avoid the issue.

  • It looks like the rendering problem occurs when the value of the "Compositing Mode" parameter is set to "Standard".

    That setting has been removed in the latest beta because, ironically, it actually tends to cause more bugs when set to "low latency".

    Graphics driver bugs are a nightmare to deal with. Try to get in touch with AMD if you can, otherwise try filing an issue with Google to see if they can help. Maybe also turning on/off WebGPU mode will help avoid the issue.

  • It's by design: they work the same as Array and Dictionary, which is that you can put them in a container with another object to have per-instance state. So just like you can put an Array in a container with a Sprite to have per-instance array data, you can put a Flowchart Controller in a container with a Sprite to have per-instance flowchart state.

  • You do not have permission to view this post

  • But at the same time I don't want to take a risk and turn it on forcibly

    If it used to be on, then changing the setting to force it to be on just means it's doing the same thing it was before.

  • The worker mode "auto" means Construct decides automatically, and we sometimes tweak the way Construct decides to work around things like known issues. You can change the setting in Project Properties to either "yes" or "no" to indicate a specific setting, but you then might run in to some kind of problem that "auto" mode was trying to avoid.

  • It might be over the upload size limit. Try uploading a smaller file.

  • You're right, the return type should be IWorldInstance | null as it is for the equivalent ICollisionEngine method. Thanks for spotting, that's fixed for the next beta.

  • Functions in Construct's event sheets only support string, number or boolean types. There is not an "any" parameter type so you cannot sometimes pass a string and sometimes pass a number to the same parameter. You can work around this by having a string parameter, a number parameter, and a boolean parameter indicating which parameter should be used.

  • I've removed the reference to 'Is supported' from the tutorial and removed the use of the condition from the example projects for the next release. As noted you never need to check this any more, as in practice it is always supported.

    • Post link icon

    The pricing model has been discussed to death over the years. This thread has done it again, and we've allowed it to stay open for a month, but I think it's run its course and there is nothing much to be gained by allowing it to continue. Naturally people will always argue that it ought to be cheaper and easier for customers - some people still argued that forcefully with Construct 2. It's also difficult for people to make good suggestions without seeing our internal data, and in many cases people are advocating for solutions that would likely significantly harm the company, or have other sources of backlash, and it's difficult for us to make our case without revealing sensitive internal details. At this time we don't have any plans to make major changes to the pricing model, and I'm afraid the time has come to close this thread.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • If you want to tell apart mouse and touch input, I'd recommend disabling 'Use mouse input' on the Touch input and making separate sets of events for input. You can do things like call functions to avoid duplicating logic. The 'Use mouse input' setting is intended as a shortcut if you don't need to tell the difference between mouse and touch input, so if you do, it's not really the right setting to use. Any other approach I'd say is pretty much a hack and may well not work reliably, as some devices support both mouse and touch input, so the only way to truly know if an input is a mouse or a touch input is to handle them separately.