Ashley's Forum Posts

  • That error basically means the project has been corrupted. The solution is to stop doing whatever is corrupting the project.

    If you have some cloud storage system that keeps coming up with file conflicts, I'd guess that's likely to be the cause. If you're doing something like saving a folder project directly to a synced folder, maybe try saving it to a regular local folder, and setting up backups to copy to the synced folder (possibly using Construct's built-in backup options).

  • I'm not aware of any particular reason the SDKv2 cannot support Mikal's 3D object. In fact, in the latest release we just added a new drawMesh() API to improve the performance and ease of use of rendering content like 3D meshes.

    Why not allow SDK1 in a “Legacy Mode” for non-breaking use-cases?

    This has all been discussed extensively already, but to summarize: if we leave it there, people will just continue using it, and compatibility disasters will keep happening. The only way to stop the on-going compatibility disasters is to remove SDKv1. Besides, arguably the LTS release is that "legacy mode" anyway, as that's your option for continued SDKv1 support.

    Why drop NW.js so abruptly when it’s the main route for native integration with platforms like Steam?

    This is a different topic, but we have our own desktop export options for Windows, macOS and Linux now, and it's time to move over to those.

    locking advanced users into a frozen version until end of 2026 feels like a temporary band-aid — not a solution.

    Actually I would say what we are doing is a permanent solution. Other options like continuing support for SDKv1 would be temporary band-aid solutions that still end up causing problems.

    Could we get official support for a compatibility layer, or at least some guidance for rewriting complex plugins into SDK2?

    I'm afraid a compatibility layer is not feasible. However we have long had our guide on porting to Addon SDK v2, plus a set of sample addons, including links to the git commits showing the changes made to update from SDKv1 to SDKv2.

    Could Mikal or other devs collaborate with the Construct team to extend SDK2 to support the missing functionality?

    We've done a fair bit of work on this already. We announced SDKv2 a year ago and have been making various updates to it since then. You can see a log of past SDK updates here, and there's other things like support for the aforementioned drawMesh() API that have come about in large part from discussions with addon developers.

    Removing SDK1 may reduce technical risk, but it creates a community trust risk.

    To me we already have a community trust risk with SDKv1: I can merely rename something, move some code, or fix a bug, and suddenly some SDKv1 addons are broken, and in some cases the addon developer has left the community. Then people see their project break in some Construct update, and they all contact support and tell us our latest release is broken and we need to fix it. If we try to explain about it actually being the addon developer's fault, in some cases people actually refuse to accept that, interpret us as shirking responsibility and trying to shift blame on to others, and they only get more angry and insistent that we fix our broken release. It's a miserable situation, it really sucks, and nobody who cares about making software that works actually develops this way: this is thoroughly understood stuff in the industry, encapsulation was invented decades ago to solve precisely these problems, and the only reason we didn't use it previously was that historically JavaScript didn't support encapsulation. But now it does and we can fix the problem.

    I'd add that back with SDKv1 we always knew the lack of encapsulation was a risk, and so we also had a big red warning in our SDK documentation saying "don't use undocumented features". Our latest documentation is different, but you can see the historical warning on archive.org, which looks like this:

    So if some SDKv1 addon depended on accessing private internal details of the engine, and these features are no longer accessible with SDKv2 - then I'm afraid I have to say we did specifically warn about that. And it also goes to show it's not enough to have a warning saying not to do something - people ignore it and do it anyway. You have to use encapsulation to enforce these rules in the software itself. That's a big part of the reason encapsulation was invented decades ago.

  • SDKv1 addons regularly caused compatibility disasters that ruined people's projects. If you keep using them there is a real risk that your project ends up being ruined before launch. If you have a project years in development using SDKv1 addons then you are relying on sheer luck to be able to actually publish your project in the end. I suspect a lot of people in this position do not fully appreciate how dangerous their position actually is.

    I do not consider this to be an acceptable situation and so we are having to change the way the entire addon system works to remove this risk. It means aligning to what the rest of the industry and all other professional tools do, which is using an addon system that has encapsulation to prevent compatibility disasters from happening. I also wrote a slightly more detailed explanation in this post a couple of weeks ago.

    I know these changes are disruptive and difficult, but I'm afraid it is absolutely necessary. We have introduced LTS releases partly to address changes such as this: you will be able to keep using SDKv1 addons (and NW.js) with r449.x LTS releases until the end of 2026.

  • It looks like you're trying to load audio files that don't exist. The file extensions look like they're missing so make sure you include them (you can only omit them for the event system). Other than that it's best to share your project so others can examine it fully.

  • Perhaps you could use an iframe? That is the usual way for showing an entire HTML document with all its sub-resources.

    If you really only want to paste the content of a file in to a HTML element, then you can use AJAX to fetch the project file and insert it to the HTML element with the 'Set content' action. Note however if the HTML file is a full document and contains things like the <html>, <head> and <body> tags it probably won't work correctly as those elements normally only occur once in a page, and this would mean inserting a second set. So with this approach you should only use a fragment of content HTML in the HTML file.

  • My question was more about having an option within Construct's export window.

    As I described I genuinely don't think this is necessary any more, and many people saw it as a significant downside. However we haven't made it impossible - if you still want to do that you can do it manually, which I think is a reasonable compromise.

    can you confirm if LTS r449 will include support for r449.2?

    LTS releases pick up from where the last stable patch left off - for example the LTS release r397.3 was continuing on from stable release r397.2. And to be clear, all LTS r449.x releases will still include NW.js support.

    Will this LTS also recieve all bug fixes that occur?

    Our policy for LTS patches is described in our guide on release channels, which I think is pretty much in line with industry norms. You can see how this worked out in practice with past LTS releases.

  • I wonder about "--in-process-gpu" - Isn't it a Chrome flag, so should work in any Chrome engine

    It is a Chromium flag but the process model of WebView2 is different, and even with the flag it still uses a separate process for web content.

    LTS is supporting NWJS for another year or so, does this mean build server gets new NWJS versions, Steam plugin gets new SDK update still, and any bugs to C3's NWJS plugin introduced from a new NWJS version would be looked at?

    I'm planning to just update versions approximately quarterly through the LTS support period. So NW.js will continue to update to the latest Chromium version and the Greenworks plugin will be updated accordingly. However there won't be any new features, and with bug fixes it depends - if it's easy to fix it we will, but if it's something like a tricky NW.js regression that they don't fix for a long time, there might not be much we can do. That's part of the reason we want to move away from NW.js too - if we kept supporting it that's still a risk.

    I do hold opinion that bundling the browser engine is preferable.

    In practice I don't think this is necessary any more. Web and Android exports are Construct's most popular export options and have both been using auto-updating browser engines for many years, and I can't recall any Chrome update that broke things since the time with the Audio plugin that you mentioned, which if I recall correctly, was over 10 years ago. We've had the Windows WebView2 export option since 2021 and I don't believe auto-updating the browser engine has ever been responsible for a breakage with it.

    Things have also changed. I do remember the issue with the Audio object, but it was party because we started using the Web Audio API when it was brand new (circa 2012 IIRC). They decided to make a breaking change to the API that was not backwards compatibile. However back then browsers implemented new features with a vendor prefix that was meant to signal "non-standard and subject to change", but in practice ended up being backwards compatibility liabilities anyway. So browsers changed how they publish new APIs to avoid this problem. Chrome now uses an origin trial model where new APIs are only enabled for websites that opt in. They use feedback to adapt the API and later when it's ready for full release they publish it in its final form without any vendor prefix, and they know they are obliged to provide permanent backwards compatibility. So that specific type of problem is both much rarer now because the way new APIs are developed is better, and also because most of the web APIs Construct uses have been around for many years by now, and so are not subject to change.

    These days I think the risk that something like a Chrome update breaks your project is about the same as the risk that Windows Update or a graphics driver update breaks your project. If you publish software you have to maintain it and watch out for such things anyway, and if they happen, usually there is some way to fix it and you publish a patch. In particular I would say buggy graphics drivers are a far bigger problem than browser updates - I see them (or things that look like them) pretty regularly - and that's all part of the system stack that affects all software. It's not like all other software in the world outside of browsers always works brilliantly.

    And if you disagree and want to bundle the browser engine anyway (also to respond to alastair) then the WebView2 export option does support fixed distribution mode (which is documented in the WebView2 export guide) - you just have to set it up manually.

    I have explored node modules and found various useful things that help with communication to the desktop, to other apps, etc

    I'd point out npm can still be a useful source of libraries that can work in the browser. It's specifically the node.js runtime that I meant was effectively redundant for our purposes.

    I really hate to ask, but I'd love to see a guide/blogpost on writing a C++ addon for WebView2

    All I'd say is copy and paste the wrapper extension sample plugin from the addon SDK and tweak it. It shows how to call the MessageBox Win32 API from JavaScript, and it's the same thing to call other APIs. The Steamworks and Epic Games plugins are on GitHub and show more complex examples. The Addon SDK documentation also has a guide on wrapper extensions.

  • I just published an update to the Steamworks addon (v1.4.1) which includes the authentication ticket features. Let me know if it's all working for you.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • My telepathic debugging skills aren't working in this case and I have no idea. You'd need to file an issue following all the guidelines for me to be able to look in to it.

  • Yes, in summary, NW.js is fully removed in r450+. We marked it deprecated in r421 back in January, and support for NW.js will continue in the r449 LTS releases until the end of 2026, so that's an approximately two year time span over which it will have been phased out.

    This also came up on Reddit and I explained in much more detail why we've done this in this comment. I won't repeat what I wrote there here, so do go and read that for the background on this.

    Broadly speaking it is time to move everyone over to our own desktop export options. The maintenance work is a key consideration as we are a small company with limited resources, and maintaining two options for desktop exports is a significant drain on resources, particularly given how tricky NW.js is to maintain and customize.

    runtime.js:1 Uncaught (in promise) TypeError: this._runtime.IsNWjs is not a function

    Oops, that shouldn't happen - fixed that for the next beta.

    I also presumed that we could still choose to use NWJS, but no support provided from Scirra

    If you are happy with that, you will still be able to use NW.js in the r449 LTS releases indefinitely, even past their official support period. We have never taken down old releases. Every past release we've ever made is still available on the releases page and it'll stay that way.

    What if Scirra decide WebView2 is not the path to go with

    I am well aware how difficult these transitions can be, and I can assure you we absolutely plan to stick with WebView2 (and our other desktop export options) permanently, and would only change technology again in extraordinary circumstances. In particular with Windows WebView2 and macOS WKWebView we are using the webview built in to the system, which is a key thing we want to avoid having to ship an entire browser engine with exported projects. No other technology can offer that other than the system built-in option.

    I'd have thought encouragement of Node.JS would be the path to promote

    It was different in the past, but at this point, the entire node.js component of NW.js is basically redundant. It provides a large API surface, but geared towards server-side development. It does not do things like out-of-the-box support for integrating the Steamworks SDK, and in fact it makes that a lot harder, as all your C++ integration has to go through the node.js layer, which also has some really awful compatibility issues (at least in NW.js). Our new wrapper extension model basically means you can write C++ code that directly interacts with JavaScript via a simple messaging system, which makes it much easier to integrate custom native code.

    I do apologize for the inconvenience of these technology switches, but in the long term they are absolutely necessary. I know they are painful and these are not decisions we take lightly. As I mentioned in the r450 release notes, Construct 3 has been around for about 8 years now, and we need to think about where we'll be in another 8 years and longer. These kinds of decisions are difficult but important to ultimately ensure Construct is still a great product that keeps improving and remains competitive.

  • Thanks for the kind words all!

  • In the import map, the relative paths are relative to the root of the scripts folder. So you don't need to worry about which subfolder you are importing something from if it uses a name defined in an import map.

  • So it's solved now? Can you share what solved it in case it helps others? In particular if disabling a browser extension fixed it, it would be useful to know which browser extension was the problem.

  • I've implemented this for the next release of the Steamworks plugin. If you're feeling brave you can try the code already on the GitHub repo which supports Windows, but otherwise I will update the macOS/Linux builds next week and release the update.

  • As with import statements, in the import map you need to start paths with ./ for them to refer to files in the project. If they start with /, that is (I think) interpreted as a URL relative to the root of the origin, which will happen to work in preview as that runs on preview.construct.net, but won't work on export.

    So you should start those paths with ./. I'm not sure what you mean by this:

    This makes you revert back to relative paths, but now you can't use the same import map key because the path to the file is different from different directories.

    You should be able to use the same import map key everywhere. The location you use it doesn't matter.