Ashley's Forum Posts

  • I noticed a slight mistake in that manual entry - the actual condition name is Desktop features supported - I updated it to fix that. It means the action will only work when that condition is true, which is documented here. There's more context in the section further up about the permissions model, but in short, the 'Run file' action can only be used in Windows WebView2, macOS WKWebView, and Linux CEF exports.

  • To the extent feasible, the entire engine state is saved and loaded. It should cover virtually everything, with the sole exceptions being that linked issue, things like mid-flight network requests that are not possible to save, and things like Drawing Canvas pixels on the basis it's a large amount of data that you may well not want to include. The savegame system should be pretty bulletproof - it's been used widely for many years now, and we've fixed a bunch of bugs over the years.

    If something isn't working right, as ever please file an issue so we can fix it. I'd also point out often problems turn out to be mistakes in the project or misunderstandings - if you think the savegame system isn't covering something, prove it! Make a minimal project to test it and file an issue if necessary. I think the state of the feature is better than is portrayed in this thread but I am willing to be proven otherwise with issue reports, which we would then fix to make sure it works reliably.

    In my view it really doesn't make sense to tell people not to use a core engine feature and invent their own. Why did we bother making the whole feature if people are going to tell other people not to use it and to make their own? If there is something sub-par about the built-in feature, we should fix it so it does the job its meant to.

    Having said that, the savegame feature does include the full state of the gameplay and that can in some cases be a lot of data. The only time I'd agree it's fine to make your own save system is if it's very simple. For example if all you need to save is something like "reached level 5, current score is 120", then the savegame system is probably overkill, and you can just do something like save a small Dictionary with a couple of keys (or your own JSON data). If you want to include all the objects in the layout though, definitely use the built-in savegame feature - there is an absolute ton of stuff to take in to consideration if you want to handle that yourself, but we've already taken care of all that for you.

  • If you get a black screen, press F12 and check the browser console for any errors. You might have made a coding mistake and the error might tell you what it is. It's difficult to help from just screenshots - it's much quicker and easier to help if you share a project file.

  • It wasn't actually possible to directly access the save state JSON from JavaScript. I realized the savegame system isn't actually well integrated with JavaScript, so I've added some new APIs to cover this and some other capabilities (like making saves from JavaScript) for the next beta.

  • If you install Construct from a stable release, the installed app will always load the latest stable release. If you install Construct from a beta release, the installed app will always load the latest beta release. It sounds like you actually want to use the latest beta release, but installed the app from a stable release. So you should uninstall the desktop app, load the latest beta release, and then install the app from there.

  • It looks like this Chromium issue is relevant, so maybe post some feedback there.

  • Thought it might be that - it's probably some experiment they're running to save battery. DOM mode runs in the main thread, but worker mode doesn't, so it seems like that would be exempt. (I'm not sure that really makes sense - presumably they want to throttle all updates to 60 FPS, so I guess it's a minor Chrome bug, but I don't think it matters too much.)

  • Without knowing more I'd speculate that the browser might have a framerate cap to save battery (or possibly for compatibility reasons), but it only takes effect in DOM mode. In both DOM and worker mode, when v-synced, Construct uses the same browser API to schedule frames (requestAnimationFrame) so it seems unlikely Construct is responsible for the difference.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • See also the manual guide on HTML layers for more information.

  • Just use the System 'Create object' action instead. All 'Spawn another object' does is create an object, and set its initial position and angle according to the object that spawned it.

  • The memory management actions have no long-term effect. They do the thing they do and then that's that, and everything else works normally afterwards. For example if you load some content in to memory on Layout A, and switch to Layout B, they are subject to the normal memory management rules: if the same content is on Layout B, it's kept in memory, and if it's not, it's released from memory.

  • Thanks for the update, we'll update the dependency in the Mobile IAP plugin for the next beta.

  • See the manual guide Performance tips for our official advice.

  • It still looks like a third-party addon (or possibly a browser extension) is causing that crash, as it's not a crash inside Construct's own code.

  • That error looks like it was caused by a third-party addon "EMI_INDO_CloudMessaging". Contact the addon developer for support, or try clearing your browser cache, which will uninstall all addons.