Ashley's Recent Forum Activity

  • It should just work. You don't need to do anything special. For example if I create a new project and import a project file image.png, then putting <img src="image.png"> in a HTML element object will show the image.

    On further reflection, I'm not even sure the discussion is still about the Addon SDK v2 and encapsulation. It seems to have broadened out in to an extensive discussion about the overall design of Construct. You may discuss that if you wish, including being critical if you really see things that way, but it isn't really relevant to this thread any more, which is specifically about the process of migrating Construct to a new addon SDK and the reasons for doing so.

    I suspect this thread has outlived its usefulness anyway, and that further discussion will no longer be productive. We try to lean towards allowing people to freely express their views on the forum, and I'd point out this thread started in May so there have been about 4 months of largely unrestricted discussion with everyone offering their (sometimes strong) views, but discussions like this end up producing more heat than light. As per our Forum & Community guidelines, under "reasons we may lock threads", we do state a couple of reasons that are happening here, such as chaotic changing of subject and repeating the same discussion points in a never-ending thread. On that basis I am closing this thread.

    I'm still happy to support any developers who have questions about how the new Addon SDK v2 will work and how to use it. However please start separate threads for those queries, or for any other general discussion points. I am not particularly willing to continue to discuss the rationale for the move to the Addon SDK v2 any more as I've already made our case ad nauseam in this thread; I will refer any future questions to my existing answers here, and if you are not persuaded then I suspect nothing I say will do. My previous post will probably suffice as my last remarks on the subject, as in summary we are moving from an unsustainable SDK that will end in disaster, to an industry-standard approach used by all professional software. I am fully aware of the disruption this will cause but I believe it to be absolutely essential for the long-term future of Construct, and so I am asking for the co-operation of addon developers to help the transition go as smoothly as we can manage. We have also introduced LTS releases - the first one came out today - in part to allow for more time for the transition to happen. This idea mainly came from feedback in this thread and elsewhere, so we are listening and thinking about what we can do to try to make things go better where feasible.

    I will keep the original post updated with the current status of the Addon SDK v2 for informational reasons. Any other key updates I will post separate sticky threads for in this SDK forum.

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,398,514 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
  • x3
    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