Ashley's Recent Forum Activity

  • 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.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,762,603 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x125
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs