Ashley's Forum Posts

    digitalsoapbox please note from the Forum & Community guidelines:

    Be polite, respectful and welcoming

    Be supportive of the products we all use and the team behind it, and make sure feedback is constructive (no pun intended.)

    Having a persistently antagonistic, cynical, combative, sceptical or complaining attitude. For example, no software is perfect, but if you continuously claim that our products are absolutely terrible in every way, you may quickly wear out your welcome.

    Deliberately trying to provoke a reaction.

    Your recent posts have repeatedly gone against these guidelines and are not acceptable. I am closing this thread and please be warned that if your posting continues to go against the Forum & Community guidelines, further moderation action may be taken.

  • It's very difficult to help just from screenshots and descriptions. By far the quickest and easiest way to get help is to share a project file.

  • I would advise to file any problems to the issue tracker, as we have a process designed to help identify and resolve problems there, and issues only mentioned on the forum are easily lost and forgotten.

  • If this only happens in preview or remote preview, try clearing your browser cache. There were some server-side changes for the new preview system. They should have already come through by now, but I guess old or rarely used devices might not have updated yet.

  • There has not been any intentional change in support. If you think there is a problem with the latest release, please file an issue.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • They're designed for things like conversation trees or finite state machines, where a visual 2D layout lets you more easily track how things progress over time. The 'Sniff and fetch' visual novel example shows the kind of thing it's designed for. If you try to use JSON or arrays or some other data structure for this kind of thing, you can't so easily follow the different branches. You can also do things like put in back-references which are trickier to express in formats like JSON.

  • Generator functions return iterables (and inside the function body they can use yield). An iterable is basically anything you can write for (const thing of iterable) or [...iterable] with. (The definition is a bit more complex but in practice that's what it means.) As ever there's lots more info on MDN.

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

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