Ashley's Forum Posts

  • The easiest approach is to block the Internet but allow domains of the form *.construct.net. There's more information (including a full list of domains Construct may use) in the education FAQ.

    Alternatively a more low-tech approach would be to get in early on a Monday morning, turn the Internet on, reload Construct on every device, then turn the Internet back off.

  • Thanks for confirming - we'll have a stable patch release out soon (r487.2) to fix this.

  • Does this still happen in the latest beta release r488?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 68kStudios - can you reproduce the issue by adding a 3D model to a new empty project? If so, please file an issue with that project.

  • I'm afraid there's little we can do with this report - if you can please file an issue as then that will provide the information we need to be able to help.

  • NW.js had a raft of other issues that regularly caused all sorts of problems and we had to work around, notably including relying on an undocumented feature to support the Steam overlay (via a Chromium command-line flag) which broke shortly after we moved off it and it took several months for a fix - so that would have been a significant problem had we stayed with it, but nobody noticed as we had already moved off. There are still a bunch of outstanding issues that were filed long ago such as #6485, #7658, #7659, #7685 and #8162. Things that broke in the past include gamepads (more than once), WebGL, file dialogs/file system access, a whole bunch of crashes that never happened in real browsers, performance issues, and regressions. Other issues with NW.js include:

    • Continued support for important features like Steam Overlay support relying on undocumented features that could break or be removed at any time without warning and with no workaround (at which point we'd probably be forced to move off to another technology anyway)
    • Infrequent/poor enough maintenance that I suspect it may be retired at some point soon
    • Bundling all of node.js significantly increasing architectural complexity for no benefit (as Construct no longer needs the node.js part at all), can cause weird bugs, and presenting a significant hurdle to conveniently integrating SDKs like Steamworks
    • Bundling the entire browser engine with the game (adding 100-200MB of file size)
    • Asset bundling relying on extracting a zip on startup, which is too slow to be usable for large projects - our own asset bundler is directly readable and so far more efficient on startup
    • No support for bundling in to a single EXE file, as the latest release supports (with a small file size too)

    In short from our point of view NW.js was kind of a nightmare to support, actually - it didn't "just work", it was a constant source of problems, had limitations we couldn't work around, and was risky as we had no way to guarantee long-term support for things like the Steam Overlay.

    Contrast that to the current desktop exporters - as of the latest release we have support for the Steam Overlay, a pretty comprehensive Steamworks plugin using our own simple and lightweight extension system, support for file system access including accessing known folders like 'Documents', support for windowing features, support for pointer lock and gamepads (via GameInput for Steam on Windows, for the time being), a high-performance custom asset bundling format, support for exporting a small convenient single EXE file, and more. In short I think we do cover everything NW.js used to, and then gone further with additional improvements. There's a few things that would be nice if it was smoother, but overall I'm happy we made the change, and I think by now Construct's desktop exporters are in a better place than we had with NW.js.

  • I'm afraid to me that looks a lot like a graphics driver issue. Inconsistent glitches that only occur on some devices are often caused by driver issues. Unfortunately the state of graphics drivers has always been poor, all through my carrer, and it's a constant problem for the industry, including being responsible for ruining the launch of major titles. It's not an issue specific to Construct, it's an issue with all computer graphics really.

    One workaround may be to switch the project back to WebGL if WebGPU is enabled, which you can do in Project Properties. Perhaps the older renderer technology is more consistent, especially on older devices.

    In some cases it's possible for us to work around driver issues in Construct itself, but we need detailed information from affected users to be able to do that. If you can get a few users who see the glitches to get this information and share it, we may be able to work around it:

    1. Open Construct 3 at https://editor.construct.net
    2. Choose Menu > About
    3. Click Copy platform information for issue report
    4. Paste the copied text and share it

    For example in the past, with sufficient evidence from affected users, we've determined that WebGPU has rendering glitches due to graphics driver issues on Intel Gen7 GPUs, and worked around it by disabling WebGPU on those systems. It's possible we could do something here, but only if we have the necessary evidence.

  • Well, Construct is a game engine, and so it's designed accordingly - normally everything fully suspends in the background because it's the most user-friendly thing to do and is sometimes a requirement for store publishing or some kinds of application certification. Construct provides the suspend and resume triggers so you know when it is changing state, but that's about it. If you truly need some process to run in the background, you could look at finding a third-party addon for running in the background, developing a custom wrapper extension for a desktop app, or just use a different tool such as a node.js service which is better suited to running like a server.

  • There's a relatively small set of changes in that release which potentially narrows it down a lot, but I'm afraid from your description alone it's not clear what change could be responsible. Perhaps there is an accidental side-effect from an unrelated change. I think we will need a smaller project demonstrating the issue to be able to resolve it. The bug report guidelines includes advice on stripping down a full project to a smaller reproduction project for a bug report.

  • You need to configure your Steam app to run the GameInput installer when installing the Steam app. I'm no expert on this as we do not publish content to Steam ourselves, but it looks like the way to do that is with install scripts.

    it turns out to be that he can use gamepad without any issue while I cannot

    This is probably because they had GameInput already installed by something else, whereas you did not. You need to run the GameInput installer to make sure it is installed.

    when I checked another C3 game(which gamepad is also working for my laptop) file downloaded from Steam, there is no "scirra-gameinput-x64.ext.dll" in the package

    There have been some recent changes to support the Steam Overlay. Older games may either work differently or not support the overlay.

  • In general, you shouldn't do that because it will waste system resources. Either the operating system or browser will commonly put background apps to sleep to prevent wasting system resources, so this is not always something you can work around.

    The catch-up time example shows how you can essentially fast-forward time when resuming, and the offline builder example shows a simpler approach based on measuring how long the app was closed/asleep for. Both can create the impression of the app running in the background, but don't actually need it to be really running.

  • One way to get a summary of changes over the past few years is to look at all the stable release notes over time. You can also go to the releases page and click a category, e.g. new features or additions, and see all the past changes of that type since then.

    For example a stable release from about 4 years ago is r302. Some of the biggest new features since then are:

    • 3D models
    • 3D editor
    • Custom actions
    • Instances bar
    • Asset Browser
    • Flowcharts editor (good for conversation trees, finite-state machines, etc)
    • New plugins: Construct Game Services, Clipboard, QR Code, Cryptography, File System, CSV, Internationalization, MIDI, BBC micro:bit, Steamworks, Epic Games
    • Show icons in Text objects
    • Dynamic layers (add/remove layers at runtime)
    • HTML layers (show sprites on top of HTML objects)
    • Support for coding with TypeScript
    • Linux CEF export option (also supports Steam Deck)
    • Tile randomization

  • I have a project that works perfectly in 476.4 but not in 487.

    As I said before, one of the most helpful things you can do is test every beta release in between those release numbers, and identify the specific release number the problem first started in. That can narrow it down from hundreds of potential changes to maybe a dozen.

    You can also speed things up by testing the half-way point - e.g. test r481, if it works then test half way between that and r487, if it doesn't then test half way between that and r476.4, etc. So you split the range in half each time.

  • It sounds like a bug - please file an issue and we'll look in to it.

  • Folks - we're happy to help but unfortunately there is just nothing we can do if you only write a forum post saying something's broken. Please file an issue if you can. If you really can't figure out the problem from a new project, you can send your full project to supportdnd@construct.net where we will do our best, but it is often impossible to work out what is wrong from a large and complex project, which is why our bug report guidelines ask for a minimal project.