Ashley's Forum Posts

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

  • Take a look at the voice recorder example which should be a good place to start. You can also save recordings to Local Storage as binary data.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It depends: Touch with mouse input enabled can work if all you need are left button clicks and drags. If you want something like detecting the mouse cursor hovering over an object, you still need the Mouse object for that, as the concept of hovering doesn't apply to touch input, or if you want to make use of middle/right clicks or the mouse wheel.

  • It's difficult to help from a forum thread like this, as all anyone can do is speculate. By far the best way to get the right help quickly is to share a project file demonstrating the issue.

  • Perhaps take a look at the Flowcharts questionnaire example which shows how to display a sequence of questions based on the user's choices.

  • Various project settings can affect memory use, including the downscaling quality and max spritesheet size.

  • There is a big difference between being an addon developer running in to the limitations of an API, and the entire product stability getting so poor that it risks the failure of the business. I don't think it's fair to use the same "development hell" term for both of those.

    I would rather nobody did make another platform behavior. This kind of feature duplication causes a bunch of other problems too. Again, we saw much of what happened when people tried hacking around with the official engine code in C2: broken projects, incompatible changes, no good way to switch between them, the official addons ending up superseding them but people being stuck with old buggy third-party versions of addons, confused users who don't know which they're "meant" to use... some of which takes years to play out, and leaves us having the support headaches of trying to help people with things like broken projects long after the third-party developer responsible has left the community. As I was saying previously, the consequences end up with us and our team, and as a small company with limited resources it is especially painful.

    Of course, it is possible to make a comprehensive and well-supported public API. It just takes time. We routinely get far, far more requests than we could possibly act on, and things like developing a large API that we promise to support indefinitely is potentially a major project and a major long-term maintenance burden, and we have to balance that with literally hundreds of other things. If I could click my fingers and have it all done, of course I would, that would be great! Unfortunately we have to deal with the real world and limited resources.

  • It's difficult to comment on suggestions. They can seem simple but turn out really hard. Sometimes they can seem difficult but turn out not too hard. You don't really know for sure until you actually implement it. Having said that, the effects system is one of the most complicated parts of Construct and very difficult to work with, and on top of that at the moment we are maintaining two renderers - WebGL and WebGPU - which means any graphics features have to be implemented twice with considerably different technologies. So overall I would say this would be a complicated change, regardless of what anyone claims about it. I'd add that we do not really want to end up making a full 3D engine - that would involve years of work and potentially amount to an entirely new kind of product, and I think we're already seeing a stream of "just one more 3D thing... just one more 3D thing..." that is trying to push us all the way down that road, and I'd rather not go very far down that road. Finally I must point out that for this and other reasons, the feature request guidelines state that we do not guarantee implementation of features, even for the top voted ones.

  • Changing the contents of just part of the text is not currently supported, but you can achieve a similar result another way, by building up the string with variables. For example "xxxxx [tag=mytag]" & SomeVariable & "[/mytag] xxxxx", and then changing SomeVariable and updating the text to that expression again will have the same result as if the contents of the tag were changed.

  • There is a fundamental tradeoff between a small well-supported API which is reliable in the long term, and a large API which keeps breaking in the long term. The worst case scenario is to refer to undocumented engine internals. This can break at any time and we will not provide support if this happens due to use of undocumented internals.

    Long, painful experience has shown the downside to just letting developers loose on the codebase results in unmaintainable software. This point is obvious to experienced software developers who have maintained a platform other developers use for the long term, and is the reason why decades ago the industry came up with concepts like encapsulation. It's not always obvious to people who run in to the limitations of the public API. The risk is that you end up in a situation where every single release of Construct breaks hundreds of projects and causes constant chaos with rolling waves of breakages on every release. Normal users do not care whose fault it is when things break. They blame us, blame the product, leave negative reviews, and tell other people not to use it because it ***** and keeps breaking all the time. Sometimes addon developers even blame us because they do not understand the tradeoff. Avoiding that means stopping improving the product: no more bug fixes and no more features, so eventually the product ossifies and becomes uncompetitive. This has happened to us to some degree in the past, and we've seen it appear to happen to a couple of competitors over the years, sometimes with catastrophic consequences. Once you fall in to development hell it's already too late. The best approach is to avoid that outcome happening in the first place, at all costs.

    Calling a set of APIs "experimental" does not mitigate this risk. Someone might use those APIs, leave the community, then years later we change them, lots of people's projects break, and then we are forced to reverse the change, and accept we are no longer able to improve the product in the way we want to.

    The cost is a small and documented public API that we promise to support indefinitely. Relative to the risk of the failure of the entire product, that is not such a high cost to pay.

    We can and do increase the public API over time at the request of addon developers, but we have to think carefully about every addition - we know we are committing to still support that in 10 years time, possibly long after any developers who wrote code using it have left the community. We already do this kind of thing, as Construct 2 first came out in 2011, and we are still maintaining backwards compatibility with projects and from back then (this blog post includes a section on how adding a single seemingly obvious action led to significant work to maintain backwards compatibility, which illustrates the kind of complex work we occasionally do with the engine to avoid mass breakage). Even the C3 runtime alone is about 6 years old now, and we are still committed to supporting addons using the public API from ~2018 and will still be doing so in 2030 and beyond. When you've felt the pain of decisions made a decade ago, it gives you a new and deeper perspective on how to best manage an SDK.