Ashley's Recent Forum Activity

  • If you run in to a problem please file an issue following all the guidelines, as we need all that information to be able to help. Notably that includes a project file demonstrating the issue which this post doesn't appear to include, and without it there's little we can do.

  • It's difficult to help from just scattered internet reports - often these combine multiple separate issues, and in fact your linked thread claims the issue is resolved in iOS 17.1 in the last post, so if it still happens in newer iOS versions, either that thread is talking about some other issue, or the information is incorrect.

    I've been doing this a long time and it's generally not possible to help without clearer information, so if you'd like us to properly investigate this, please file an issue following all the guidelines, which ensures we have everything we need to be able to help.

  • I've never heard of that problem and it's difficult to help without knowing why it's happening. Would you be able to share a project that demonstrates the problem happening?

  • The crash appears to be caused by a browser extension, as the crash message includes chrome-extension://ihcjicgdanjaechkgeegckofjjedodee. The extension ID appears to be that of the Malwarebytes Browser Guard.

    Unfortunately there's not much we can do about browser extensions that interfere with Construct and break it - either remove the browser extension or report the problem to the browser extension developer.

  • There's more details in the manual entry on deprecated features.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I've added IRuntime properties tickCount, projectId and projectUniqueId for the next release cycle.

    I really think CallAction() and CallExpression() were a mistake to add and I would rather never support them in SDKv2. You shouldn't need them to call your own plugin's actions or expressions - just add a shared method or script interface instead. Calling the action or expression of a different plugin is in my opinion a design mistake. Can you do without them?

  • Export your game as NW.js and enable the Node-Webkit and NW.js File System options.

    Beware of using AI. This sentence is nonsense.

  • Periodically all data in construct is erasing, which means installing all plugins, doing setup, searching for recent files from scratch

    Check if any of your browser settings periodically delete data, or if you have any browser extensions that would do that. Commonly privacy-focused extensions will clear all data ostensibly for privacy reasons, but that will also wipe all data saved in Construct. Further they may refer to this data as "cookies", which is an unfortunate term which I don't think makes it clear this will happen.

    If something tried to clear data while Construct was also accessing storage, you may see write errors like the one you showed.

  • It depends on the server configuration - for security reasons servers have to specifically allow cross-domain requests. It's subject to the same rules as described in the AJAX manual entry section on cross-domain requests.

  • Construct doesn't use QtWebEngine for any official feature, so that must be something to do with the way you are loading or running your web export from Construct - I'd guess it's part of Broadsign.

  • It doesn't mean it takes up twice as much space - it just means a 32x32 image takes up 34x34px on the spritesheet, and that doesn't fit neatly as spritesheets are always a power-of-two size. For example a 128x128 spritesheet can fit 16 images sized 32x32 (assembled in a 4x4 grid), but only 9 images sized 34x34 (assembled in a 3x3 grid).

    However for small images this doesn't matter much - suppose you need a whole other 128x128 spritesheet - that would only use another 64 KB memory. It generally only matters for much larger images.

  • It's a very old part of Construct and has been like that for many years. I think the original thinking was that if you have 100 sprite instances, then you load 10 animation frames which they all load as individual images per-instance, then you just actually loaded 1000 images and you may well then run out of memory. Tiled Backgrounds are generally used with few instances with a single image so it is less likely to be a problem if they can have per-instance images.

    Even if we supported per-instance images for Sprite, it would mean solving that problem: there would need to be some way to actually say "share this image among these instances; share this other image among those other instances" as opposed to the naive and highly wasteful case of "every instance load its own copy of this image". I'm still not sure what that kind of design would look like in terms of the event system - I don't think there is precedent for that anywhere else in Construct. Perhaps it could happen automatically in the internal engine, but that might be a complicated feature to implement.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,472,661 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x66
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x36
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs