Ashley's Forum Posts

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

  • Open source is not the same as compatible with hacking the runtime. In a native engine, you could do things like identify memory addresses where useful things are and overwrite memory addresses with custom data to achieve new things. Anyone who knows anything about reliable software engineering will be cringing at that idea because it is obviously a disaster and you will end up with a total nightmare with everything breaking all the time. The main reason people don't do that with native engines is because it's particularly difficult. JavaScript lets you do something similar, but more easily. It does not make it a good idea. Again, this is not the same thing as whether or not the engine is open source. It is a matter of maintenance and long-term reliability. Being able to look at the code does not mean that hacking memory addresses in a native engine becomes reliable, and likewise, being able to look at the code does not mean that hacking internal JavaScript APIs is reliable.

    I'd say the open source equivalent would be forking the engine and making a bunch of modifications to the internal engine. Now you have a compatibility nightmare as the main branch diverges from your customized codebase. You might try to occasionally merge over changes, but then you might end up with merge conflicts and a huge mess in the codebase. The easiest thing to do is never update the engine. Now it's game over for support - nobody can support your customized engine, and you cannot easily merge in any new features or bug fixes in the main engine. Anybody who has been through this process knows the only good approach is to merge any changes upstream in to the main open source project, so you are still working with the single shared codebase shared and supported by everyone. If you have your own hacked fork, you do so at your own risk, and it will probably end in disaster for you, but that's on you.

    The difficult thing for me here is that this is all well-understood stuff learned over decades of the software industry. But right now people are already doing it with Construct, it looks like it works, and why would Scirra go and break it? It's because in the long run, it ends in disaster. This has already happened with Construct 2, and it is obvious to anyone else who has maintained a software platform for a long time, but it may not be obvious to people tinkering with the engine right now. So you can downvote and argue all you like, but our responsibility is to make sure the engine is reliable and will continue to be reliable even a decade ahead from now; we know what that involves; and we are advising people accordingly.

    The exception to all this is the documented, supported APIs. If you use those, we promise to support them indefinitely. That's why part of my advice is to stick to those.

  • The problem we have with integrating third-party services is there are literally hundreds of things out there that could potentially be integrated, and we already get far, far more feature requests than we could possibly act on. We just don't have time to jump in to every third-party service that appears.

    This is the very reason we have an addon SDK, which is ideal for integrating third-party services. We know we can't do everything ourselves, and so we have an SDK so someone else can do it without waiting for us.

  • When exporting a debug APK from Construct, the app runs in a WebView using the Cordova framework to communicate with the app that contains the WebView. It's not the same as a web browser, and so some things like opening links work differently, especially when trying to open a new tab/window: as it's not a browser it doesn't have the ability to use tabs or different windows, so it just opens in the same WebView.

    Construct's Browser object works around this, so if you can use the 'Open URL in new window' action, it will work correctly.

    If you are using JavaScript coding, you can also make use of the Cordova InAppBrowser plugin: calling cordova.InAppBrowser.open(url, "_system") will open the given URL in the system browser, which is what the Browser object does. (If you do this, add the Browser object to the project, as it includes the InAppBrowser plugin.)

    If you are clicking links inside an iframe showing other web content, it is much more difficult, as the web content inside the iframe is not under the control of Construct or Cordova and so neither of these things will work. You will have to do some customization in Android Studio as you were already looking at, but this is beyond the scope of what I can help with.

    Of course, a much easier solution is: publish a web app and skip the Android app completely. Then it always runs in a web browser and links will open normally.

  • Don't do this. You're using undocumented internals which are not supported and could permanently break at any time.

    You shouldn't need to manually suspend or resume the engine anyway. Construct handles that for you. If you want to do something like pause the game, set the time scale to 0 instead.

  • Do you mean in the addon SDK? The sample addons have code that includes a custom script interface, e.g. here which defines IMySingleGlobalInstance exposed to Construct's JavaScript coding.

    If you mean just when writing your own JavaScript code... sure, just use classes, modules etc.

  • It sounds like they came up with their own vector graphics renderer. It's the kind of thing browsers can already do (via SVG or canvas2d).

  • That code doesn't look right. You've written an array with a single string element, and then called it as a function. If you mean to call a global function, use globalThis["Inventory__GetScrollY"]().

    I would advise going through the Learn JavaScript in Construct tutorial series which covers the basics of JavaScript syntax such as this.

  • Or is it that there is a plan to obfuscate all internals at some point?

    This could well happen, and it could mean whatever internals you are accessing become permanently unavailable.

    A long-standing problem with JavaScript is it has typically had poor encapsulation: external code can easily mess with the internals of APIs. With newer features like private fields there is proper encapsulation support that makes it genuinely impossible for external callers to mess with internals. As encapsulation is a basic principle of software engineering and important for the long-term reliability of a platform and codebase, I would definitely like to use that throughout our codebase. This would however make all sorts of internals permanently inaccessible - much like they already are with any other game engine with any other technology that properly supports encapsulation, so bringing us in to line with the industry standard. This could permanently break engine hacks with no workaround. This is exactly why we have this warning, and why whenever possible I advise against it, since as per our policy we will not help anyone in this situation if they were using undocumented internals.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Try disabling any browser extensions you have, or try using a different browser. That's often the cause for weird error messages like this.

  • See the manual section on exporting with advanced minification.

  • There is a known issue with WebGPU that updating textures seems significantly slower than WebGL. In Construct, changing Text objects and a few other things require updating a texture, so these cases may be slower than WebGL for the time being. I filed an issue about it back in June but it hasn't been sorted out yet. As WebGPU is still pretty new I think there may be a few early issues like this to be sorted out, but I think it's likely it will end up as fast or faster than WebGL in the long run.

  • I'm afraid it's impossible to help from just this information. If you provide your project file we could take a look, alternatively file an issue following all the guidelines so we can investigate. Also try disabling any browser extensions you have installed as they can be a common source of problems, or try using a different browser.