Ashley's Forum Posts

  • See the section on cross-domain requests in the AJAX manual entry.

  • Workers should work in Windows exports. It's hard to say more from just this information - the fastest way to get help is to share a sample project demonstrating the problem.

  • This turned out to be easy to add so there's now an option to auto-increment the version on export in r418.

  • Iam using Construct r327 on Windows 10

    That version is about 2 years out of date now. My first suggestion is to update to the latest version of Construct. Maybe it's a problem we already solved in the past 2 years.

    If you still have trouble try pressing F12 in the preview window and check for any errors in the browser console.

  • This post was originally in French. Please only post in English as per the Forum & Community guidelines. I've translated your post using Google Translate.

  • Apparently this comes down to a problem with the HTML specification. I reported it in 2021, and still waiting on a resolution...

  • It's hard to comment without knowing more about what you're trying to do. In general, in software there are often several ways to achieve something, and the best way depends on your goals. However if you're comfortable with it and it works for you, it's probably not a bad option.

  • I'm afraid it's impossible to investigate unless you file an issue following all the guidelines.

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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