If Construct adds an expression that is already used as an instance variable/behavior/effect name, you'll see an error when opening the project explaining the problem and indicating that you need to rename the item to be able to open it in the newer version.
That's normal - the console basically works in global scope, and it can't access variables declared in other functions (and script blocks in event sheets are actually inside functions), just like how you can't write code in one function that accesses a local variable inside a different function.
That's right, images added as project files are just copied to the export as-is and aren't processed any further.
Electron is very similar to NW.js and so shares many of the downsides noted in this blog.
NW.js provides both sync and async file system operations. Basically it was a mistake that when making the NW.js plugin we used sync file system operations. We should have chosen async.
I'm not sure what you're trying to achieve with the other details about the File System plugin. I imagined most games would do something like write a handful of files for save data and that would be it. If you have complex use cases involving listing lots of files and passing data along with file system operations, what is it you're trying to achieve? It might be better to move to the forum to discuss this.
I'm afraid file system operations must be asynchronous to support both browsers and wrapper extensions.
For what it's worth, pretty much all modern storage APIs are asynchronous, so it is normal that doing something like file system access is asynchronous. Synchronous operations for that kind of thing have poor performance and can heavily jank the game, or in some cases cause it to freeze for periods of time.
I can't find anywhere to publicly report it. I've repeatedly tried to report it to them privately, and they either say it's supported and should work, or that there are workarounds (which don't actually work), and then they stop responding to further messages. I think the only thing that will persuade them is if lots of people get in touch with them and ask them about it.
Are there any issues in particular you are concerned about?
I don't think the Steam overlay works for the macOS WKWebView exporter. People really need to ask Valve about this - I really don't think there's much we can do about it.
You can submit feature requests here: github.com/Scirra/Construct-feature-requests
I'm afraid we have to rely on an extremely complicated workaround due to limitations in Steam. For better support please ask Valve to fix the Steam Overlay - the main problem is it just does not work for Windows WebView2 and Valve need to make changes to support it.
We have a workaround in place for Windows WebView2. It should work if you add the Steamworks plugin and make sure 'Enable overlay' is checked.
See the Steamworks addon documentation here.
There is a comprehensive list of changes in the beta releases in all intervening releases - they're all linked at the start of the release notes. I don't believe anyone reported any such issues during the beta period - if you can please do file an issue about any new problems and if they are regressions since the previous stable release they will be prioritized.
The File System plugin lets you directly access files and folders in special paths like AppData in Windows WebView2 and Linux CEF exports, and in the next release cycle it'll support macOS WKWebView too.
Member since 21 May, 2007
The official blog for all things Construct and Scirra run by our employees!
Wider technology issues from Ashley's perspective.