Ashley's Forum Posts

  • I just published an update to the Steamworks addon (v1.4.2) which includes the new expressions AppOwnerAccountID and AppOwnerStaticAccountKey (based on the Steam ID of GetAppOwner()). Hopefully that now covers everything you need.

  • Contact supportjnb@construct.net with any details you have and we will try to recover your original Construct 2 purchase. However I'm afraid we will need some kind of proof of purchase as otherwise we have no way to either find your old account or verify that you are the owner.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This was also reported here, but by the time it checked it was working for me. Is it working now?

  • This was also reported here, but by the time it checked it was working for me. Is it working now?

  • OK, I'll look in to exposing the app owner account details via the plugin.

  • My AI took a peek at the GitHub repo to understand it better, and noticed the user ID is retrieved from the UserStatsReceived_t callback.

    That's incorrect - the plugin actually ignores that event (typical AI hallucination...) It currently just logs to the console in that event and does nothing about it.

    A potential fix might be to use the standard SDK function SteamUser()->GetSteamID() instead. This synchronous call should always return the ID of the actual current player, which would resolve the issue in Family Sharing scenarios.

    This is what the plugin already does: it ends up calling SteamUser()->GetSteamID().GetStaticAccountKey().

    So I'm not sure what the problem would be - perhaps there's some other ID we need to expose with the plugin, but I don't know what that would be - it probably depends on how all the server-side validation works. It might be a good idea to ask Valve for support.

  • I'm not sure what you mean. It's not impossible to change the import - you can change it, but then you might need to update code that references it, because those imports work differently (e.g. with the first you can call GetMessage() directly, with the second you must call Main.GetMessage()).

    I don't know what you mean about forcing importsForEvents to update, nor why JavaScript would do this differently - it should work the same.

  • You don't need to extend that code for every sound file - an array with just a list of filenames should suffice, and you could do something like build a map of filename to loaded audio from that.

    I would say Construct's option to preload all sound is a pretty blunt instrument, particularly for large projects. With scripting it's easier to do better and do things like group sound files in to sets that are loaded and unloaded all together - in which case you'd need to write arrays of paths anyway. I guess we could add a script API to list all files the project was exported with, but then it won't reflect changes made after export, which I'm sure would end up tripping some people up.

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