Ashley's Recent Forum Activity

  • "<app>" should be used as the picker tag, not part of the path.

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,762,539 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