Ashley's Forum Posts

    Folks, I'm not going to keep re-stating the same arguments over and over, but: this is the way the rest of the industry works. Encapsulation was invented decades ago to solve the problem of constant compatibility disasters. Everyone now uses it. We only didn't because of historical reasons about JavaScript not supporting it.

    If you don't like encapsulation, you don't like how the entire software industry works. But the industry works like that because continual compatibility disasters ultimately cause products to fall in to development hell, fail on the market, and get taken over by other products that are better designed.

    Accessing the internal engine may seem like "infinite features" or "endless customizability". It's a trap though. It ends in disaster. So nobody supports that. You can switch tool if you like. It will work the same as the Addon SDK v2, because it will have encapsulation.

    I honestly find it difficult to explain any better: if people want to continue arguing that we should ignore the standard industry practice and do something nobody else in the industry does because everyone knows it ends in disaster... sorry, that's not going to happen. To me, this is responsible management of the product: sometimes you have to take tough and unpopular decisions because it's best in the long run. If you claim that we're ignoring customers and developers because they want to force us to stay on a path that ends in disaster - yeah, sorry, we're not doing that. I suggest you go find other tools on the market and tell them to do that, because it will end in disaster for them, and ultimately that will be good for us!

  • Does WeChat use a webview with a real browser engine like Chromium or WebKit? Or is it still based on a custom browser engine?

  • At the moment TypeScript does require an external editor like VS Code. But as TypeScript compiles to JavaScript files, it's not much different for addon development, as that already needs an external editor.

    Private fields would absolutely make it much harder to do some of the bigger hacks that I've done in the past.

    I'm afraid these also all risk major compatibility disasters and so consequently it is our intent to make them impossible if we can.

    Again, I'd point out in virtually all other software on the market, encapsulation is the industry standard and such things are impossible to begin with. It's only due to historical reasons of the development of JavaScript language that there was no encapsulation in the first place. If JavaScript had private properties and methods 10 years ago, we would certainly have used them from the start, and this situation would never have happened in the first place.

    For what I've seen, most of your alternatives are "don't do it".

    The compatibility disasters that hacking the internal engine risks causing are so bad, that yes: "don't do it" is a better option. If it really is impossible to do what you want, you can file a feature request and move on - which is what we do ourselves with all other software when we need something more than they provide, because hacking the internals is generally impossible, because encapsulation is the industry standard.

    If this increases pressure on us to improve the addon SDK, that's good - in the long term we'll get there but in a sustainable way, without risking ruining thousands of people's projects. But I also think in many cases people will also figure out other approaches that get the job done but don't need to hack the internal engine - options developers should have chosen in the first place, but ended up never trying to research them because they could just access the internal engine.

  • I would just use private methods. They already have broad browser support and we're going to start using them in the core engine soon. Closure Compiler doesn't support them, but UglifyJS does (part of the motivation to move to it), and we're going to drop support for Closure Compiler as soon as we're confident UglifyJS works well enough (which it looks like it does so far).

    BTW I'd recommend setting up TypeScript for addon development - it will help catch errors like the one you ran in to. The type checker and autocomplete are really good.

  • We have no current plans to cover it, and to consider it it'd need to be posted as a feature request outlining the use case.

    I already know of at least one easy way to hack around the sdk2 limitations and expand the api to include whatever internal calls I want anyway - its just "slightly" more bothersome than just installing a plugin - until someone releases tool to automate it. At which point, poor little Timmy IS going to use that hack.

    ...which will work until we go through the engine and use private fields everywhere, which we've been planning to do for some time, and would also have permanently broken all SDK v1 addons that access undocumented internal features - another reason nobody should break encapsulation, and another reason we need to retire the Addon SDK v1 beforehand.

    There are usually better workarounds to accessing the internal engine anyway. I've also seen cases where people claim they need to hack the internal engine to do something, but there was a straightforward and perfectly good alternative. I think a big part of the problem is people got used to it and started to do that over better options. By enforcing encapsulation people will eventually learn to use the better options first. Even if you have to import a library, or write some extra code yourself, that is better than accessing the internal engine, since that is absolutely catastrophic for compatibility - basically any other option is better.

  • It's a typo in your code. You wrote o._setMyProperty(5) instead of b._setMyProperty(5).

  • Construct just returns the value of location.search. Try pasting that in to the browser console to see what the browser has it set to. If it's not set to what you expect, it's probably not Construct that's responsible.

  • There is not currently any SDK support for common ACEs. Those are implemented as an internal engine feature at the moment.

    As a response only the looping condition was mentioned, but what about other use cases of using the Event classes?

    There were no other use cases for those classes other than for looping conditions, which are still supported in the Addon SDK v2 but with different APIs. If you have a different use case involving those classes which is still not covered, please let me know and we'll consider options to add a new API to support it in the SDK v2.

    Honestly though, It still seems like letting sdk1 slowly vanish organically by virtue of blasting warning signs not to use sdk1 would more than solve the problem

    Again, as I explained earlier in this thread, the entire problem we are facing here is in part caused by addon developers ignoring a big red warning in the SDK documentation saying not to do something which lots of developers ended up doing anyway. People ignore warnings. We're certainly not going to make that mistake again.

    but all the crying we are doing here is completely ignored

    Again, 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. If you describe this as being "completely ignored", then I'm afraid I must point you to the Forum & Community guidelines, which include under the section on bad faith discussion:

    Accusing people of ignoring you or not caring, after they have tried to help

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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