Ashley's Forum Posts

  • I'll take a look at setting that up. Feature requests are regularly reviewed, but as I mentioned before, we get so many it is a very large amount of work even just to respond to them all in any useful way. If any suggestion you care about for any reason is closed due to expiring, and you still care about it, you can just resubmit it - you will only have to do that once a year.

  • It's normal that some cross-domain requests send a "preflight" request before the actual request, for security reasons. If the server is correctly configured then this shouldn't affect how it works. There's more information in the MDN guide on CORS.

  • See the guide in the manual on using an external editor.

  • The code in your initial post appears to be correct. Maybe you didn't set the right script purpose properties. The easiest way to get help is to share a project file, so others can see exactly what you've done - otherwise all we can do is guess.

  • As writing JavaScript code for a multiplayer game is a very advanced use case, the script API just gives you access to sending and receiving messages, and then you can write your own synchronization code on top of that. That's the approach used in Command & Construct.

  • Performance will most likely be absolutely fine and you don't need to worry about it. See Performance Tips in the manual for more advice.

  • Construct moved from UIWebView to WKWebView several years ago already. If you're seeing that message for an old app, exporting it with the latest version will move it to WKWebView. However if it's an old app, updating it may have some compatibility issues, so you might just want to leave it as-is - the warning only says they don't accept it for new apps, and existing apps can continue to use UIWebView.

  • I'd be willing to put each issue on its own 12 month timer, but I can't find an easy way to set that up - it looks like all the existing stock GitHub actions are for other management workflows, such as only closing issues if they are stale (inactive for a period of time), whereas I want to automatically unconditionally close an issue after a time delay.

    If anyone can point me to something easy that does that by mid-January I'll set that up, but otherwise I'll just manually close everything as originally planned - I'm too busy to spend long trying to figure out how to do custom GitHub actions.

  • If you're using PNG and JPEG, you're behind the times - at least use the modern WebP format, and if you are willing to reduce image quality to get smaller file sizes, then use the AVIF format for lossy images too.

  • There's not enough information here to be able to help. The easiest way to get help is to share a minimal project demonstrating the issue. E.g. make a new empty project with just a button that shares some test data when you click it; if that works, it's probably a mistake in your project, if it doesn't, then you can share that on the forum to ask why not, or use it in a bug report.

  • There's not enough information here to be able to help. In general if you believe there is a problem with Construct then please file an issue following all the guidelines, as we need all that information to be able to help.

  • Existing ideas aren't deleted - they will just be closed and tagged with something like "Archived 2024", so you can still see them all, but they won't be under active consideration any more.

    There are all sorts of ways we could organise this and I don't think there is any one perfect way. Sure, we could auto-close suggestions without enough votes, but there is now unlimited voting, so everyone could just vote everything up enough so nothing much ever gets closed, and then the system has failed to keep things fresh again. It's also possible something gets highly voted, but then sits there for several years, becomes redundant for other reasons, but then never gets closed because it remains above the threshold.

    The main thing I want to avoid is the feature suggestion list building up with 10+ years of work with such a huge list of individual suggestions that it's too much time for us to even review or administrate it all properly. Over long periods of time it then also ends up full of all sorts of older ideas that are redundant or no longer important for other reasons (e.g. at one point "make an OUYA exporter" would have been popular - now it's irrelevant). Then from our point of view it becomes something of a millstone around our neck: it's such an impossible amount of work it's stressful to even prioritise or consider it, and people start to get more negative about it ("this has had X votes for Y years, why haven't you done it already?", "look at Scirra ignoring the community", etc.)

    So by that point it's no longer an effective system. That's pretty much what happened before, and I'd rather avoid anything that might end up the same way. Closing everything and starting afresh every year might be annoying for some, but submitting an idea you care about once a year isn't a huge amount of work. If you have dozens of ideas we probably can't do them all anyway as that ends up creating an infeasible amount of work for us, so we want people to think carefully about their requests, and only submit the most important ones, not flood us with impossible amounts of work. If something remains important and popular, then I expect it will keep coming back every year and being voted up again, and we'll take notice of that.

  • If you believe there is a problem with Construct please file an issue following all the guidelines - that's our process for sorting out anything that might be working incorrectly.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It sounds like webview2 was more of an experimental thing, that hasn't really worked out.

    NW.js is pretty much unmaintained at this point, and is gradually accumulating weird problems that aren't being fixed and are getting harder and harder to work around, and is also very difficult to integrate custom native code with. I would not be surprised if NW.js is retired at some point soon, so part of our recent efforts is to mitigate this if it happens. WebView2 on the other hand is actively maintained by Microsoft, they've already added a significant feature I requested, doesn't require constant maintenance from us, and is much easier to integrate custom native code with our wrapper extension architecture (some of which are also significant benefits over Electron too). So I'd actually say it's the other way round.

    When it comes to the handling dual GPU systems (and other things like the Steam Overlay), I think these come down to the multiprocess architecture of browsers and the way third-party tools work which are outside of our direct control. These also remain risks for NW.js and Electron - if you have to rely on hacky workarounds to get things to work with them, and one day the workarounds mysteriously stop working, what then? You need a proper solution, which is what we need to get working with things like WebView2. The best way to do that is to contact GPU vendors and ask them to fix it. I've got in touch with NVidia and AMD to see if they can adjust how their drivers work to support WebView2 with the NvOptimusEnablement/AmdPowerXpressRequestHighPerformance approach. However I would encourage all those affected to also get in touch and request the same thing. People commonly over-estimate how much influence we have: we don't have friends in high places and we usually can only do what anyone else can, and so the best way to make sure our requests get noticed is to have as many of the affected people also request the same thing so they see the popular demand for it. So if you're concerned about this, or other issues beyond our direct control like the Steam Overlay, please add your voice and get in touch with the companies responsible and request changes. Given the risks and maintenance difficulties of NW.js and Electron, we're going to be going ahead with retiring NW.js anyway, but there's going to be ~2 years more of support via LTS for NW.js. So assuming we get some co-operation from the community and the companies responsible, that should be enough time to make sure everything we need for WebView2 is in place before NW.js support is finally fully retired.

  • What GPU does the device have? Going from 1080p to 4K will require about 4x the GPU power in high quality fullscreen mode, but using low quality fullscreen mode will keep it about the same. 4K is really very high resolution and you'll generally need a powerful GPU to match, so often if you upgrade your display to 4K you may well need a new GPU to power that many pixels.

    If you want to render at 1080p quality and then upscale to 4K, the way to do that is to have your project's viewport size set to 1080p. But if you've already designed your entire project for a different viewport size, that might be a tricky change to make.