Ashley's Recent Forum Activity

    As per the Forum & Community guidelines promoting piracy is not allowed, so closing the thread.

    There is a free edition of Construct, and we're happy for anyone to use that indefinitely as much as they like.

    Every year, Apple and Google change the publishing requirements to be able to upload an app. Sometimes the changes are quite onerous and involve a lot of work to comply with. Where details are changing rather than being removed, they would say all existing apps are still supported, but you need to change some details and upgrade your code to comply with the new requirements. It's a pretty normal thing to do in the software industry. In principle that is what we're doing here: everything that was supported still is supported, but you need to upgrade your code to the Addon SDK v2 to continue using it. I realise that is disruptive and sometimes a lot of work for addon developers, which is regrettable, but personally I have a clear conscience on this. I accept people might want to complain about all the extra work they have to do - and I've outlined why we feel this is absolutely necessary - but having to do extra work does not mean that things that were supported have become unsupported. For that to be the case, previously supported APIs would have to be removed with no forward support path available. In my mind there is a clear difference between those two things: it is normal that something remains supported, but you have to do work to continue using it in its newly supported manner.

    As I've described previously, we cannot meet the goal of preventing addons breaking user projects if we keep supporting Addon SDK v1. The current situation is there are loads of "timebomb" SDK v1 addons being used widely with which it is only a matter of time before they break and cause disaster. We face the prospect of this happening over and over again in an uncontrolled manner. Rather than sit around and wait for disasters to strike and keep ruining loads of people's projects, we're making difficult choices and taking action now to avoid this outcome. I realise some addon developers might not like this or disagree with it no matter how much time and effort I put in to making our case, but as I strongly believe the current situation genuinely threatens the usability of Construct and the viability of thousands of customer's projects in the long term, if some useful addons are not ported, as regrettable as that may be, in my view it is still better than continuing on a path that inevitably ends in disaster.

  • Yes, broadly speaking that's the plan. We're currently working on a new Linux wrapper with the long-term aim of improving support for the Steam Deck by using the same extension system as WebView2 to provide Steamworks integration. If it works out, we'll then likely extend the extension system to macOS WKWebView as well. After that (very long term here) I'd want to drop support for NW.js if possible, but that depends on any outstanding compatibility issues. But if our own custom wrappers can do everything NW.js can, and with easier maintenance and better customisability, then I don't think there's any reason to continue supporting NW.js. But anyone using NW.js now shouldn't worry - this is long term speculation, we're going to keep supporting NW.js for a while yet and only switch over if we have new options that cover everything people want.

    I think this thread has run its course and it looks like any further discussion is not going to be helpful, so closing.

  • The point is about traditional programming languages, not event sheets, though. There isn't yet any visual system that is comparable in reach across the industry to languages like C# and JS. Maybe one day that will change, but until then, if you are going to learn a traditional programming language, there are very good reasons to use an industry-standard language. That's the point it's making.

  • C# and C++ are also industry-standard languages. The point also applies to them, in the sense that those are also better languages than tool-specific languages - which it seems you agree with. It's talking about the disadvantages of tool-specific programming languages like GDScript and GML where that programming language is only used by one piece of software.

    For example, if you want to write some server-side code, you'll have a much easier time with an industry-standard language - C# and JavaScript in particular are great for that (ASP.NET, node.js etc). Suppose you want to branch out in to some other part of the tech world - those skills are far more useful and have far more jobs available than any tool-specific language.

    Education is also an important part of the business for us, and so we're also posing the question to teachers: do you want your students to learn an industry-standard language they can directly get a job working with? Or will they be learning some tool-specific language that won't provide as easily transferable skills?

    Perhaps you think C++ and C# are better languages than JavaScript for game development, but that's not the point we're making: I'd also say C++ and C# are much better options than tool-specific languages, for the same reasons.

    For me "don't invent your own programming language" is the hill I will die on - I think it's a big strategic mistake, even though it seems lots of people disagree. We're making the point that for developers writing code, there are a lot of benefits to using an industry-standard language, be it C++, C#, JavaScript, or any other major existing language.

  • Usually the manual is only updated at the next stable release in order to avoid documenting things that don't work in the latest stable release, and so possibly resulting in addon developers releasing addons that don't work for the majority of customers using the latest stable release. That method is currently only available in beta releases, but I did describe how it works in this forum post.

    I've already spend many posts and thousands of words in this thread explaining in as much detail as possible our rationale for this and why we feel it is absolutely essential despite the serious disruption that we are keenly aware it will cause. I'm afraid I'm not going to be drawn in to writing all that out again, so I would suggest you go back and read my previous responses in this thread.

    For anyone looking for a solution to a major engine issue and not unhelpful misdirection or shifting of blame

    Repeatedly blaming us for issues that are not our fault or responsibility, even after we've done our best to explain the situation, are against the Forum & Community guidelines, in particular in the section regarding bad faith discussion:

    Demanding impractical measures or infeasible solutions. If we say we can’t do something, it’s not because we don’t want to, or we’re being difficult, we genuinely can’t do everything!

    Therefore closing this thread. I've already indicated the best way to approach this problem and fix the root cause, which is the only good long-term solution.

  • As far as recreating vanilla behaviors, The runtime for Collision engine is missing the calls for pushing objects from collisions. I put a feature request in back in april maybe.

    These are ~10 lines of code for a completely-customizable version. See Collision methods

  • We don't publish any usage limits other than stating it's a free service that works on a best effort basis for reasonable usage, with the interpretation of those terms at our discretion. If you are not comfortable with that, you should set up your own TURN server.

    It's hard for anyone to tell what the usage would be anyway, as it is only used when direct connections fail, and it's difficult to guess what proportion of devices will be resorting to TURN for any particular game audience.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The only major difference between SDK v1 and SDK v2 is how you write the runtime scripts. Therefore the Runtime scripts part of the Addon SDK documentation is split in to two sections for each SDK version. There's also a porting guide.

    Am I able to simply use the same calls from the scripting reference for use inside construct 3?

    example:

    runtime.collisions.testoverlap(...)?

    Yep, exactly. One of the major design improvements with SDK v2 is it unifies all the scripting APIs so you can use the same calls as you would in Construct itself.

    I'd also recommend getting TypeScript support set up for addon development - it gives you precise autocomplete for all the available APIs, and is another new feature of SDK v2.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,378,075 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
  • x107
    Coach One of your tutorials has over 1,000 readers
  • x61
    Educator One of your tutorials has over 10,000 readers
  • x2
    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
  • x35
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs