Ashley's Forum Posts

  • You must also tell Construct about your script interface class by returning it from GetScriptInterfaceClass().

  • I think this amounts to multiple inheritence: you want classes to inherit from multiple locations - the Construct provided base class, and a separately written base class also inherited by other classes. If you search for JavaScript mixins you should find a few ways to do that.

    Another simpler way (and one I tend to prefer these days) is to use composition over inheritence - create a complex custom class that you want to be shared, and just add it as a property on multiple other classes.

  • See Exporting to Windows with the WebView2 wrapper, which covers this. As of Windows 10+ all Windows systems should have the WebView2 runtime installed automatically. However some out-of-date systems may not have it installed, but in that case, the exported app will automatically download and install it.

  • Don't get hung up on whether or not we do it deliberately: the point is everything could break unintentionally, by accident, due to cleaning up our code, due to refactoring to reorganize things, due to performance optimizations, due to upgrading or replacing internal components, due to adding requested features, or for any other conceivable reason. Everything could break anyway. This is the risk everyone is running by using undocumented features, and this is why we have that warning. If that happens we reserve the right to say "sorry, you shouldn't have done that", otherwise we basically lose the ability to upgrade the engine.

    It sounds like stuff is already occasionally breaking and addon developers have to update their code. What happens when these addon developers decide to move on and stop maintaining their addons? We start facing backwards compatibility disasters and we are left to deal with the consequences.

    How do we avoid this risk? The industry-standard solution of using encapsulation to ensure people only use public, supported APIs and can't mess with the internals. It's nothing to do with Apple or the open web. The situation is JavaScript has weak encapsulation, so we've ended up in an especially bad situation for compatibility that other tools don't face, and we want to try to avoid the disasters that are inevitable if we carry on down this path.

  • As you will always have some form of text rendering in the engine it's save to assume that while it might change, maybe even drastically, it is near impossible to be removed completely.

    No, this is an incorrect assumption, and text rendering is actually a good example of why. I have been monitoring the canvas formatted text proposal, which lets the browser do the text layout for formatted text when rendering to a canvas. Currently we have had to implement our own custom text layout engine in JavaScript, which is both extremely difficult, has lots of difficult bugs and edge cases, and is reimplementing what the browser already does. Ideally we could switch the implementation to a browser-based one with the canvas formatted text proposal and delete our entire custom implementation. It could then have more features, better performance, better consistency, broader internationalization support, and so on.

    However if we did that, all third-party addons which rely on hacking the internal text layout engine will be broken. All the internal text layout code would be deleted, so there is no more scope to modify it. It may then be impossible to achieve the same thing with the browser built-in feature, as from our point of view, we only need the new text engine to be compatible with the old official features. It is possible that third-party addon compatibility is then such a severe backwards compatibility problem that we have extreme difficulty implementing the new, better engine; or even we have to cancel the project to upgrade it. For us, that's game over: now we can't upgrade the engine, or it is far more difficult to do so, and so we end up stuck with inferior systems in the long term.

    This type of thing can happen with literally any part of the engine. The undocumented features warning is there because we want the flexibility to be able to upgrade the engine in the long term. So really the problem here is developers assuming it is fine, when it is not. It is meant to be a serious warning that is taken literally. If you ignore the warning and assume it will be fine, and then everything breaks, we reserve the right to say "sorry, we warned you about this" and proceed anyway, to avoid the outcome that we are unable to continue making improvements long-term.

    Do you want to support 3rd party development?

    Obviously yes - if we didn't, there would be no addon SDK at all. Exposing a controlled public API is the industry standard, and as I keep saying, the only reason people can bypass that in Construct is because of weak encapsulation features in the JavaScript language.

    Would it be possible to set up a way for folks to more easily get access to an expanded api?

    I think perhaps a good way to do this would be to put the addon SDK behind the scripting interfaces used when doing JavaScript coding in Construct. That is already a more comprehensive, documented API, which does have encapsulation, and it avoids us needing to implement and document APIs twice (once for the SDK, once for scripting) - by adding an API there it then becomes available to both addon SDK developers and JavaScript coding simultaneously.

    Again, you needn't promise eternal stability, just a way to get the job done

    Yes, we do need to promise indefinite stability. Otherwise if we change it say 5 years down the line, it breaks a popular third-party addon, thousands of projects are broken, and the original addon developer has left the community, then we have a huge compatibility mess which we are left to deal with. This has happened. Again, this is a case of people assuming things will be fine, but it is not. The only way to avoid this is a public, documented API that we promise to support indefinitely.

    Do actually believe that behavior alone addresses all needs within the genre in a scalable, and sensible way?

    Maybe the behaviors don't do everything. They are designed to be flexible. But beyond that, you can use custom logic in event sheets, or JavaScript coding within a project, to implement things like custom movements. You don't have to jump to hacking the engine internals. There are usually several ways to get things done.

  • function getRuntime(runtime) {
	return runtime;
}

    This function is pointless - it just returns its parameter. 

    var playerInstance = getRuntime(runtime).objects.iPlayer.getFirstInstance();

    This line is run at the top level, so it is run before the Construct runtime exists, therefore runtime cannot be used. The runtime only exists when the callback to runOnStartup() is executed. So you have to wait until at least that point in time or later before trying to use the runtime.

    A typical way to do that is to declare the global variable as set to null initially, and then assign it later on.

  • To help clarify the point, I've updated the wording in the Addon SDK documentation to read:

    To be clear, it has always meant this - I'm just adding a clarification to emphasize the warning includes that possibility.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It went from "undocumented features could change or be removed at any time" which is perfectly fine and understandable to "we plan to make sure nobody could ever access and use an undocumented feature".

    "We plan to make sure nobody could ever access and use an undocumented feature" is a case of "undocumented features could change or be removed at any time". It is precisely what the warning was warning you of.

    It is not removing engine customization completely. Engine customization remains, but with the provided APIs.

    As I said before though, if we do this, I promise we will do our best to approach it in a responsible fashion, and roll it out gradually and in phases and deal with compatibility issues where feasible.

  • But, isn't it a similar situation to any support request that Scirra receives: if a project has correctly-made third party addons and sends it to Scirra to fix, Scirra wouldn't touch these until the addons are removed?

    No, there is a distinction here: it is not Scirra's responsibility to provide support for third-party addons. If there is a bug in a third-party addon, then the third-party developer needs to deal with the report and fix the problem. However if the addon developer themselves identifies a bug in Construct's supported APIs, they can file an issue with us and we will fix it. (Note if the bug is in an unsupported API, we are not obligated to fix it, as per our warning about using unsupported features.)

    Overall, it really hurts my trust/faith in Construct, and I'll think more carefully about my choice of game engine for upcoming projects.

    I would point out nothing has changed. That warning has been there for a long time and it has always meant this. If this was not clear to you, I am not sure how to make it any clearer. Do you think the wording should be different? If so, what should it say?

    You can of course stick to the documented APIs and do anything you like, and we promise to support that indefinitely. I am pretty sure there is a lot more flexibility in using officially supported features than most people appreciate. As I said many engines make it difficult or impossible to hack the runtime code, especially at runtime, so this entire pattern of hacking the engine mainly via the weakness of JavaScript's encapsulation is not typically used in the industry. Everyone uses different approaches, like creative workarounds, or other implementation techniques. You can do all of that with Construct too, and have no risks or problems. As I said before, I think people are too quick to reach for "hack the engine" as their solution, rather than more thoughtful approaches that would be more reliable in the long run.

    I think you need to understand our stance on this Ashley while you are working on software architecture and striving to have something that will still work in 10 years, we are not.

    I realize game development may be different, but it doesn't change the fact we are in a different position having to maintain software for many years, and that imposes different and more stringent engineering requirements.

  • Yeah, normally a web page cannot start a server. So even lots of built-in libraries in Python would not work out of the box. That's my point: the pure language interpreter alone does not actually do that much - you need a whole range of libraries and APIs for it to be practically useful. I suppose you might be able to do something like set up a way to pass JSON data to a Python interpreter in WebAssembly, do some processing on that, and then return some JSON data, but that's an awful lot of trouble to go to when you could just write some code in JavaScript instead.

  • So you can guarantee the Runtime API won't become like the Editor API in the future where only the documented exposed stuff is accessible while the rest is obfuscated and impossible to use ?

    The point of the warning is: we reserve the right to do that! You should not be surprised if we do, because we warned you.

    People messing with undocumented internals causes disasters. This has happened. Who gets the blame, takes the reputational damage, and has to spend hours picking up the pieces and helping desperate customers whose projects are ruined? Us. How do we avoid that ever happening in the first place? By enforcing a properly supported API with language-enforced encapsulation. The fact the runtime does not already do this is in my view an architectural mistake, and we are continually running the risk of some change causing disaster. I would like to fix this architectural mistake (as it largely is for the editor, so we have removed the risk there), but I don't know if or when we would do that. As ever we are extremely busy and have to constantly prioritize lots of different work. If we did do it, I promise that we will try to do it in a responsible fashion, slowly rolling it out gradually in the API over time and where feasible fixing compatibility issues as and when they come up; but as the warning says, we reserve the right to say "sorry, you shouldn't have done that".

    To be clear, obviously I don't want to make one big change that breaks everything deliberately - that would be irresponsible. But the problem is this could happen anyway for some other reason, such as simply by accident, or due to some major upgrade. In general the longer you leave it the worse the compatibility problems will be, so in general, the sooner we can bite the bullet and start imposing proper encapsulation and long-term supported public APIs, the better it will be in the long run.

    For what it's worth, this is how we develop Construct itself. Supporting software for 10+ years is tricky, and involves taking great care and judgement over every change over a period of many years. We almost never use any undocumented, internal or experimental APIs in any of the other third-party software or services we use, and where we do so, we do it in the most minimal possible way and with the understanding it could be 100% broken at any point in the future and then it's entirely our responsibility to deal with it. In general if we need something but it's not supported, we file a feature request, and go away and do something else. Maybe it's added eventually, and maybe not. But we don't hack it in, because in the long run that's a recipe for disaster, and that's not how you build software that still works 10+ years later.

    I think there is a simple analogy for all this: if you use undocumented internals, you void your warranty. If you buy a brand new car with a warranty, but open up the engine and put in a part you designed yourself, you void your warranty. It's the manufacturer's way of saying "we can't possibly support what you've done, so you're on your own now". If the car then explodes and renders it worthless, tough luck, that was on you. Welding down the engine cover so nobody can get to it is however a step too far in the other direction. Being able to access the engine, but specifying what is supported (such as a list of manufacturer-approved parts), is a sensible middle-ground. The software equivalent is: stick to the public, documented, supported APIs, and you're fine; use undocumented internals and you void your warranty, anything at all could happen for any reason, you're on your own, and you should understand that is a real risk and act accordingly.

  • Most of the details of the report are omitted from your post, so it's difficult to know if it relates to any known issue. Please include the full details otherwise it's harder to help.

    Without knowing anything more, I would guess a browser extension is interfering with Construct, so try disabling any browser extensions you have, or try using a different browser.

  • What I was getting at before is a WebAssembly build of a Python interpreter is a fraction of the necessary work. By itself it would do no more than a basic interpreter running in a terminal, with no access to any Construct objects or any browser APIs. For it to do anything useful it would need bindings to a wide range of APIs, which would likely be far more work than just getting the interpreter working in the first place.

    If anyone wants to try it out anyway, you can probably get a WebAssembly Python interpreter working with the addon SDK!

  • The addon SDK may be limited. I appreciate that. However I suspect most of the time, there are workarounds to what you want to do. I'm pretty sure at least some of the time you don't have to go hack the engine. As I mentioned, with a traditional native engine, usually there is no scope to hack the core engine at runtime, and so everyone resorts to other workarounds and gets by; only JavaScript makes it easy for people to hack the engine at runtime in this way. I get the impression people realize they can, and then they reach for it as their first solution when there are better options. There is also the feature request system, which I also appreciate is slow, but that's the official way to get new things supported.

    Sure, if an engine has an open source runtime, you can hack it to your heart's content. But as I explained before, that's a double-edged sword: you could well end up in development hell, and some people learn that the hard way. Someone giving you source code doesn't mean they'll support you if they make a mess, it's more just "here you go, good luck".

    do you plan to obfuscate the whole undocumented runtime and only let us use the documented features ?

    There is this warning in the addon SDK documentation:

    That warning is there precisely because it is a real possibility! It could happen unintentionally, it could happen because of some major upgrade or new feature, or it could happen because we want to improve encapsulation for better long-term reliability. We don't want to break things, but the point of this warning is if you use unsupported things, it definitely can; we will do our best to avoid causing major disruption where reasonable, but it may be infeasible or go against our long term plans, in which case, what can I say other than we tried to warn you?

    If you ignore that warning, you should be working under the assumption that the undocumented features you are using can change or be removed at any time, just as it says. I would say if you are going to ignore that warning, the only responsible way is to have a plan in place for what you are going to do if the thing it warns you about then happens, so then you can fall back on plan B. But then in that case I would say, just do plan B first, and you won't have the trouble with undocumented stuff changing or disappearing.

  • So stop the audio too! Don't go hacking the engine just to perform tasks like this.