Ashley's Forum Posts

  • I tried that project on an iPad running iOS 16.7 and it seemed to work fine for me.

    This happens a lot, which is why we ask that any problems are reported to the issue tracker following all the guidelines - normally we need all the requested information to be able to help.

  • It's difficult to help without more information. Are all your audio files in WebM Opus format? Can you share a minimal project demonstrating the problem?

  • Press F12 and look in the browser console - are there any error messages?

    Try disabling any browser extensions you have installed, or try using a different browser. A common cause of people having weird issues loading Construct is buggy browser extensions that interfere with Construct and break it.

  • I set up dual boot to Ubuntu 22 LTS. WSL is good for command-line stuff but its support for GUI apps is clunky and a bit weird - I don't think it's worth using. A VM should probably work as well, but I just boot in to a real system to remove any complications from VMs (particularly around GPU drivers, which seem to not always work so well in a VM, and Linux has enough trouble with GPU drivers as it is).

    I'd note the OS version you build on has significant compatibility implications: due to the way glibc seems to work on Linux, it requires the glibc version of the system you build on - so in short it won't run on any older OSs than the one you build on. This seems to be a particularly horrible aspect of Linux development: use too old a system and all the compilers are out-of-date and you might not be able to build anything at all, but if you choose too new a system it won't support some older OSs still in use. You can work around this with various options for virtualization, building your own toolchains, or integrating runtime environments (Steam has one) - I researched those and they all look like a total nightmare. So I just use Ubuntu 22 LTS and build on that and it seems good enough and the right balance between old and new.

    Also you have to install Steam directly from steampowered.com (I noted this in the Steamworks documentation). Ubuntu's app store has Steam, but if you install it from there, integration doesn't work. I haven't looked in to this too much but I'd guess that Ubuntu's app store uses some kind of emulation to install the Windows version of Steam and be able to run Windows games, whereas the official version is a genuine Linux version; as Construct's Linux export is a genuine Linux export, I guess it can't talk to a Windows emulated version. Just a theory though. To help debug it you can run the exported Linux app from a terminal and you should see some messages logged to the terminal about whether the Steamworks plugin was able to initialize. If it doesn't load it at all, probably something else is wrong, like the .so was built incorrectly (e.g. perhaps built on a system using newer glibc or something like that).

    Fortunately it looks like Valve have done a good job of making the Steam Deck easier to work with - obviously you can't do things like install the wrong Steam, its glibc is pretty up-to-date so that doesn't cause a problem, and generally if it runs on Ubuntu it just works on the Steam Deck too. I don't think I had to actually change anything at all specifically for the Steam Deck.

    For IDEs, I just use VS Code - I'm already familiar with it, and if you install the C++ and CMake extensions you can build, run and debug in VS Code, and it's good enough. Of course you can use different tools, build setups or whatever, but in my limited experience you quickly end up going down a rabbit hole doing things like spending hours configuring a build system to build a custom tool to build something else, and I'd rather do something straightforward so I can actually get real work done.

    In short I learned a lot about Linux development, and it's overall a huge pain, and no surprise lots of people don't bother (sorry Linux fans - at least sort out the glibc situation and the whole thing will be a lot better). However I focused on getting as simple and straightforward a setup as possible, and that makes it tolerable. Perhaps I should write this up in a blog or something.

  • I wonder if it's possible to switch from NWJS to WebView2 in an already published Steam game?

    I think the only serious problem is how to handle Local Storage specifically. Local Storage data goes in to a database somewhere in the app data folder. I don't think there's any good documentation on how it works - despite the fact both use the Chromium browser engine, I wouldn't be surprised if there were weird issues that come up with pointing WebView2 at an NW.js app data folder.

    On the other hand, using files for storage will work with either kind of exporter. So if your project writes storage as files to some known folder that both NW.js and the File System plugin can access, then both can read/write safely to the same files.

    If you have an existing project deployed using Local Storage though, this is a tricky migration to pull off. You'd probably have to go through three versions:

    • Version A: existing NW.js export using Local Storage
    • Version B: an updated NW.js export that uses files instead, and automatically copies any existing Local Storage to files for backwards compatibility
    • Version C: a WebView2 export that only uses files and does not attempt to use Local Storage

    This is tricky to set up so definitely test anything like this carefully and thoroughly. However with this approach so long as everyone updates A -> B -> C, it should continue working without anyone noticing anything. One particularly difficult problem though is that even long after version C is out, anyone updating directly from A -> C will lose their save data. With software updates it is very difficult to guarantee exactly 100% of people have updated - usually it approaches but does not meet 100%, going 99%, 99.9%, 99.99% etc. and a few people end up left out for whatever reason. One way to mitigate this is to move to version B as soon as possible, but I doubt that will completely solve the problem - you'll still have a few people who lose their data. Another way to mitigate that is to have explicit "export your data" and "import your data" options in the user interface, so you can document this and provide manual instructions for anyone left behind, ideally with instructions on how to roll back to version A if they need to.

    We've gone through such migrations with Construct a few times over the years and they can be a challenge. My advice: approach with a great deal of caution and do it slowly over time.

    The other option is: just stick to NW.js. It's a lot easier as it means not having to do anything different! I think we will continue to support it until the next LTS release, which should mean at least LTS support until the end of 2026. Even after that, if anyone had major published projects that desperately needed some change, we'd still do it if at all possible - I appreciate there's lots of long-term projects out there still using NW.js and we don't want anyone to be left stuck with problems out of support.

  • It looks like this was previously discussed here.

    If the command-line switch works, you can use it - but it's a workaround, and usually we try to avoid making workarounds built-in, as it ends up getting messy in the long run. Construct already asks for the high-performance GPU (respecting the GPU preference in Project Properties, which defaults to high performance), but at the moment the Chromium browser engine ignores that. In an ideal world Chromium would support that and everything would run on the high-performance GPU by default without having to do anything. This issue looks like the most recent time it's been filed with Google, so I added a comment there - more votes on that issue might help.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'm happy to keep small and simple APIs in the official Steamworks plugin - or even accept pull requests for them if they are limited in scope. The contributing guidelines are mainly about our reluctance to merge large, complex changes, as it's likely we end up obliged to maintain those changes indefinitely. I don't currently plan to implement the more complex APIs like UGC, networking/matchmaking, or the full remote storage APIs (I think auto-cloud should be fine for most games anyway). So if you have small simple changes, you can propose those to be merged in to the main plugin, but for the larger and more complex stuff, a companion plugin is a better option.

  • As of today's r412 there is support for wrapper extensions with the Linux export option, which the official Steamworks (formerly "for WebView2", but dropped that part of the name now) add-on plugin uses for Linux/Steam Deck support. The code on GitHub for both the wrapper extension sample addon and Steamworks now include the source code changes and build instructions for Linux (a pretty straightforward minimal CMake setup).

    We're aiming to get wrapper extension support for macOS in the next release cycle, so at least a couple of months away for that, but then the Steamworks plugin should work on all of Windows, macOS and Linux. After that we'll be looking at the feasibility of dropping support for NW.js entirely, but we'll be asking for community feedback on that at the time, and I suspect we will be supporting NW.js for quite a while longer to ensure nobody with important projects gets left unsupported.

  • Yeah, you can't use any of this new modules support with SDK v1 addons, only SDK v2.

  • AFAIK the File Chooser object does work on mobile - it's File System that doesn't work on mobile, but Google appear to be working on adding support for the File System Access API on Android, so it may work in future soon. As noted the NW.js plugin is exclusively for NW.js exports and so won't work with any other export option.

  • The Browser object 'Request fullscreen' action works in Windows WebView2 exports as well, without the user input restriction, so you can use it in 'On start of layout'.

  • I use the downloaded Construct app version.

    Do you mean using the "Install as app" option in Chrome/Edge? There is no official downloadable Construct app - if you found an unofficial one it's completely unsupported and we can't help any further.

  • I tested this carefully when I developed it, and it should all be working.

    Note there is a difference on how modules work after export depending on if you minify: without minifying, then it preserves the file structure and keeps your imports; if you minify then everything is bundled in to a single source file, but that should not break anything as the bundler follows all the imports and preserves cross-references. If you do a dynamic import, things get tricker, but I think you can still configure that using a file dependency.

  • runtime.platformInfo.exportType === "preview"

    Previously that required the Platform Info object to be added to the project, but as of r408+, it's permanently available without needing the Platform Info object.

  • I think those kinds of glitches usually come from buggy graphics drivers. Try checking for updated drivers or installing any available system software updates.