Ashley's Forum Posts

  • Yes, we could add read-only properties for those.

  • Those properties are not currently changeable at runtime, so there is no way to change them either with event sheets or code. (They are used to slice the image in to 9 GPU textures which are then shared across all instances, so it would take some work to allow them to be alterable, especially if it was meant to work per-instance.)

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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