Ashley's Forum Posts

  • There isn't currently a script interface for 9-patch instances. However currently I don't think there's anything to expose on its script interface, as there isn't anything unique to 9-patches that is dynamically configurable (see its event sheet features - there are no conditions, actions or expressions unique to 9-patch). Therefore as it stands it's appropriate that it's represented by the generic IWorldInstance interface. Was there something specific you were hoping to access?

  • Construct does save layer visibility and lock settings. I just tried it and it does work as I thought.

  • It's hard to tell from that, but my best guess is you have a browser extension installed that is interfering with Construct and causing problems. Try disabling any browser extensions you have installed.

  • If you run in to a problem please file an issue following the guidelines, as it's generally impossible to help from just an error message. In this case, the error refers to code that does not exist in the latest release, so it should not be possible for that to be happening there. So try updating to the latest release if you haven't already.

  • pakyawan - your recent posts have some strange phrasing and in some cases incorrect information, which look like they are possibly AI generated. If you're using AI to write your posts, please note our Forum & Community guidelines do not allow that, and continuing to do so may result in a ban.

  • Take a look at the link I provided which explains how to check for errors in the browser console.

  • If you load the editor from editor.construct.net it always auto-updates. There's a complicated mechanism using a Service Worker to handle that which I think would be difficult to change, and besides I think it makes sense that the base domain always serves the latest stable release (it's not like a new user visiting for the first time wants to load an old release there). If you install Construct as a desktop app, it does exactly the same thing as the browser, so if you install from editor.construct.net that's still the update process you'll get.

    If you load an old stable release in the browser it does still notify you. I actually thought we'd already added a setting to cover that, but I must have forgotten. I've added a setting to turn off update notifications for the next release, so you can make sure loading old releases doesn't keep prompting you to update. Note however this does not affect the update process for editor.construct.net: as the actual files served there are updated, then it will still update you even if you turned off update notifications, and so the editor still also shows an update notification to tell you that's going to happen.

  • It would be extraordinarily wasteful if Construct loaded the same image 1000 times for 1000 Sprite instances. Therefore all Sprite instances share the same set of images. When you load an image from a URL, it replaces an animation frame in the shared set of images, therefore updating it for all of them. When you look at it that way, I think it works logically.

    The Sprite manual entry does note:

    All instances of Sprite objects share their animations. In other words, there is a single set of images comprising the animations which belongs to the object type, and these images are referenced by instances.

    To clarify the point about loading an image from a URL specifically, I've just added a note to that action:

    Note that as all Sprite instances share the same set of animations and frames, loading an image will replace the image for all instances of the object type. If you want to dynamically load images for individual instances, try adding animation frames and loading a different image in to each frame.

    That note advises what you can do instead. It looks like you linked to a thread about 2 years old, and I don't think dynamic animations were implemented back then, so you may have fallen in to the trap of digging up out of date information. It should already be possible to use dynamic animation frames to load images from URLs on a per-instance basis.

  • The error is "failed to fetch", which suggests some network request failed. Try looking in the browser console for a more detailed error message. If you send your project to supportvit@construct.net we can also take a look.

  • You can load a specific release from the releases page. If you browse to editor.construct.net it will always serve the latest stable release.

  • Please report problems by filing an issue following all the guidelines. Things only mentioned on the forum are easily lost and forgotten, and it's not possible for us to investigate problems solely from exported projects.

  • It's hard to tell from just that. You generally will need to share an actual openable Construct project for anyone to be able to help you. All I can say is it looks like tempNickTeam1 and tempNickTeam2 are null.

  • How do I see the memory consumption of each sprite? In the debug screen I can only see the total memory consumption.

    Sprites aren't actually loaded individually - they are placed on sprite sheets and then an entire sprite sheet is loaded. If you right-click the project name in the Project Bar and choose Tools - View Spritesheets, you'll see the set of spritesheets Construct has generated for your project, including the approximate memory usage and download size per sprite sheet. (Those details can change after export though, depending on export settings.)

    Another question, I know there's a recommended maximum pixel size for each sprite (4096px). But if I put a smaller sprite on a tiled background, and increase it to one above the recommended size for the sprite (for example: 8192px), is that a problem?

    Just to be clear, because an earlier reply was incorrect: that's fine. So long as the source image is 4096 pixels or smaller, you can resize it as large as you like and it won't be an issue.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'm afraid SDK v1 addons cause catastrophic compatibility problems and the risk of keeping them is unacceptable. Due to the lack of encapsulation, addon developers have written lots of addons that manipulate the internal details of the engine that were never meant to be used. If I merely rename something or move something around to better organise our code, it can break addons, causing problems for hundreds of customer projects, who then all contact support and blame us for breaking their project in the latest release. This has, and will, happen over and over again. In the long term all parts of the engine eventually change, and so eventually all such addons will probably break. It will leave us in the position of having to either stop making improvements to Construct, or break lots of projects.

    This is thoroughly understood stuff in the software industry. For these reasons no other professional tools allow unrestricted access to internal engine. The industry standard for decades has been to use encapsulation and enforce that only a specific documented API can be used. Then you can ensure everything keeps working in the long term, even when doing major internal upgrades, and even after the addon developer left the community many years ago. The only reason Construct ended up with a lack of encapsulation is historical reasons - basically JavaScript did not used to support it.

    I know this will be a painful transition but unfortunately I believe it is absolutely necessary to make Construct reliable and trustworthy in the long term. The next LTS release will be supported for another 18 months so there is still a long period of time that SDKv1 addons will still be continued to be supported in LTS.

  • IIRC Construct doesn't cache any project logic when you export, so it will regenerate all project logic on every export. If it isn't updating something correctly, it should be easy to prove it with a minimal project that you can file a bug report with. However I don't recall ever seeing such an issue with Construct.

    Honestly my best guess is that with large complex software projects, you probably forgot about something and have a bug in your own project logic, or made some mistake somewhere in your testing process. It's easy to do - I sometimes get mixed up with things like preparing Construct releases. There's a lot of moving parts and things like whether or not storage is clear or whether it's running in release vs. development mode are easy to confuse. In particular if you move it all over to a new fresh machine and it works the same, my best guess is it is actually working correctly.

    Other than that, based on your other thread, it sounds like maybe something weird is happening to your system. Try using a different machine for a while.

    That's the best I can do with telepathic debugging - our bug report guidelines are there because that's how to make sure issues get fixed.