Ashley's Forum Posts

  • Btw, another random question. When I started using construct, I used to get warnings about not going beyond 2048 pixels for sprites and textures. Now 4096 is the limit.

    Is it still recommended to go below the 2048 limit or going in-between 2048 and 4096 is okay?

    Several years ago there were still a few percent of devices in use that only supported a maximum texture size of 2048, so going over that could cause issues on those devices. However by now basically all those devices have fallen out of use and 4096 can now be relied upon to work universally, and we updated Construct accordingly. In several more years we might be able to go to 8192 or 16384, but it depends how much longer devices that only support 4096 remain in use.

  • 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 the File System plugin must use async operations. It is not possible to use synchronous file system operations either in the browser or in our desktop wrappers.

    We went through a similar process years ago with the WebStorage plugin, which used to use a synchronous browser storage API, which then got replaced with the Local Storage plugin which is asynchronous (and uses IndexedDB internally). Yes, async logic can be harder to work with, but it's necessary. We've also made various improvements over the years to better handle it, like with 'Wait for previous actions to complete', async functions in event sheets, and so on. People also then adapted how they use storage - rather than lots of individual keys, a popular option now is just to use a Dictionary with multiple keys and save/load it all in one go, which is much easier to deal with.

    You used to even be able to do things like synchronous network requests - nobody seriously considers that now, and it's widely seen as a mistake, and a terrible idea to keep using it. Storage usually responds quicker than the network, but IIRC I've seen data showing there's a long tail of devices where storage is shockingly slow - perhaps it's ancient hardware, perhaps it's failing, perhaps the system is busy in the background, but I do think it's naive to assume "storage always responds quickly and so synchronous is fine". All modern software uses asynchronous access for the network and most uses asynchronous access for storage - it's the best way, and, well, in this case outside of NW.js it's the only way. So my main point is this is the modern and proper way of doing it anyway.

    To address a few of the other points:

    - You have to 'List contents' even for known directories like "<documents>"

    Why would the app know what's on disk without checking?

    - 'Has file/folder' cannot be done with a folder path afaik, you have to 'List contents' again if you want a subfolder.

    I guess it could work recursively, but then that is potentially a very slow operation if it is going to end up reading through a lot of folders. That kind of thing definitely cannot be synchronous.

    - To read any file, you need another event, 'On file operation complete'

    That's just like with AJAX requests. You can also use the 'Wait for previous actions to complete' action and then read the data in the next action after that.

    I think the export option should have a "Bundle with WebView2 Version"

    It does - see the docs on fixed distribution modes.

  • There is no desktop download any more. The main reason is there's no reason for it, as you can do everything (such as saving to a folder project) in browsers like Chrome now. We mainly provided the desktop download to be able to do things like that before browsers had the capability, but now that's not a reason to have it any more. Add on top weird bugs and stability issues that only happened in the desktop edition like Jase00 mentioned, and it didn't make sense to have it any longer.

  • I'm afraid exported projects are deliberately designed to be as hard to modify or understand as possible, to prevent reverse engineering, which lots of people don't want to be easily possible for their published games. You will need the Construct project to make modifications. You should keep regular backups for any important digital work you do, whether in Construct or other software - unfortunately sometimes that's a lesson you learn the hard way.

  • For what it's worth, in r417 I've updated the Windows WebView2 exporter to specify NvOptimusEnablement and AmdPowerXpressRequestHighPerformance in the executable. I haven't been able to test this myself as I don't have a dual-GPU laptop any more, but this should mean it has the same thing as nvpatch does but built-in. It'd be good to know if anyone can confirm this solves the problem of being able to use the high-performance GPU with Windows WebView2.

  • I don't see how that improves security at all, though. Even if you encrypt values on the client, the client can still see them before they get encrypted. So you are not hiding anything from the client.

    Once the request goes over the network using HTTPS, then everything is encrypted. Usually the main concern is: can someone else on the network intercept and read the traffic? With HTTPS the answer is no. Adding extra encryption to the URL or request data does not affect that answer.

  • You could always just use an actual array object to store data in before calling a function.

  • What problems have you read about?

  • From the manual entry:

    A wake lock might only be granted in a user input trigger, such as On touch end.

    It's like with audio playback - you can't automatically do it on startup in a web browser to prevent abuse.

  • It's a known issue - there's a workaround here in the mean time.

  • Try using the Platform Info object's 'Request wake lock' action.

  • Preflight requests are a normal part of CORS and can happen in a variety of other circumstances. I think it's best just to accept it and update the server configuration accordingly, and then it shouldn't be an issue again. We could add some kind of setting for this, but as I mentioned preflight requests can happen in other situations so I think it's best just to get the server configuration to cover preflight and then all cases are covered.

  • These aren't default values, they're pre-filled autocomplete entries. You can use autocomplete in the SDK with the autocompleteId property for string parameters. The SDK doesn't currently provide a way to provide pre-filled entries like this, but I'm not aware of any use case for that currently - File System is a one-off case.

  • Web Workers don't have access to the document and so can't directly read the URL parameters. In this case the easiest solution is just to turn off worker mode in Project Properties, and then your code runs in the DOM with access to the document. If you then use JavaScript to start your own Web Worker, that won't be able to directly access the document either, but you can then read whatever URL parameters you want and post them to the worker.

  • It looks like the problem is that since the AJAX plugin added support for 'On upload progress', cross-domain requests have changed from simple requests to "preflighted" requests. These make an OPTIONS request before carrying out the real request. It looks like your server is configured to respond with Access-Control-Allow-Origin: * for GET requests but not OPTIONS requests, so it now fails with a CORS error as the preflight request is not allowed. So I don't think it's a bug, it's just that the way requests are made has changed, and you now need to update your server configuration. There's more information in the MDN guide on CORS and I added a note about this to the AJAX manual entry.