Ashley's Recent Forum Activity

  • It's much easier to help if you can share the full text of any error messages. Also, do you have any browser extensions installed? If so try disabling them, as they can often interfere with Construct and cause problems.

    ERR_BLOCKED_BY_CLIENT usually means something on your computer decided to block Construct loading something. So it's quite possibly a browser extension that's blocked a resource Construct needs to work correctly, which then subsequently causes an error.

  • Do you mean something like their system user name? For privacy reasons browsers do not expose that or anything like it to web content. Maybe just ask them to type in their name at the start...

  • Unfortunately Linux systems often have poor graphics drivers, which is often the main cause of crashes and glitches. If you are exporting with NW.js, my advice is to export with 'Ignore GPU blacklist' unchecked - since if it's checked it will try to run even on graphics drivers that are known to be broken; if unchecked it will switch to slower software rendering when the driver is known to be broken, which doesn't use the GPU, but should at least work correctly. Alternatively you can try updating the graphics drivers or try using different drivers if some are available, but I should warn you I once bricked a Linux system trying to update the graphics drivers, so good luck...

  • It must be an ancient library. It relies on "sloppy mode" global assignments, where you can merely write myvar = {} and have it create a global variable, as opposed to var myvar = {} or globalThis.myvar = {}. "Sloppy mode" was essentially retired with "strict mode" JavaScript which was introduced around 2011 if I remember right. JavaScript Modules always run in strict mode, so you have to adapt such old scripts to work correctly in strict mode.

    The easiest fix is to replace the line if (typeof (_pio) == 'undefined') { _pio = {} } with var _pio = globalThis._pio = {};. This explicitly creates a global variable named _pio, and also creates a variable scoped to the file named _pio, which the rest of the script expects. Then you need to fix a few other cases where it just assigns to something without declaring it as a variable - putting var before those appears to then fix it and have it load successfully.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It looks like you can use _postToDOMAsync in conditions. Is it correct that this doesn't work with expressions?

    You can call the function, but I would say it's not useful, because conditions and expressions must return a result synchronously, so you can't wait on anything in them. If you want to do async work it should be in an action, since that is the only thing that the engine allows to finish working later on.

  • I would say that is some kind of fault either with the measurement, or the Steam Deck, or NW.js - Construct itself won't be using that much memory, so I doubt there is anything we can do about it.

  • As noted in the manual, downloading is a browser-only feature. When running as an Android app, it's not a real browser, so the download feature is not available. Consider using the 'Share' object instead.

  • Open Settings and change the UI mode to 'Desktop'.

    Ed2: Also may I suggest "normalizedVolume()" as the expression if this is going to be a thing? "linearVolume()" might cause... confusion ;)

    I think that's a good point - let's use these terms to avoid confusion:

    • Linear volume: applying volume as a multiplier in the range 0-1, which does not represent perceived volume
    • dB volume: applying volume as a dB level from 0 to -Infinity
    • Normalized volume: representing volume as a percentage range, but actually applying it in dB as that matches perceived volume

    For the next beta I've added a NormalizedVolume expression which takes two parameters: the normalized volume in the range 0-100, and the dB threshold which represents the dynamic range of the volume slider (e.g. -40 means to ramp down to -40 dB at the bottom). It then returns the equivalent volume in dB to use. However as it's a built-in expression and can be a bit more complex, it includes a nice-to-have: the range 10-100 actually goes from the dB threshold to 0, and the range 0-10 actually goes back to a linear ramp. This means even if you choose a fairly high dB threshold which is still audible, it doesn't snap from audible to silent when going to volume 0 - instead it just more rapidly fades down to silent. I think that's a reasonable option to handle very low volumes and some of the references online describe this as a decent way to smoothly reach silence. The cutoff at 0 is probably fine in practice assuming the dB threshold is low enough, but this is just a little bit of polish.

    So I think we got there in the end with a useful addition to Construct - but it doesn't mean Construct itself accepts linear volumes in the Audio object, because I still struggle to think of cases that's useful, outside of perhaps coming up with advanced custom volume calculations - but you can still do that and just convert the result to dB at the end. And if you want to make a volume slider that reads 0-100, you can use the new NormalizedVolume expression.

  • I saw the news about WebView2 and it is disappointing - it would have been great to have WebView2 running on Windows, macOS and Linux. It'd have been a consistent approach which makes it as easy as possible to port between platforms with a broad feature set. Unfortunately Microsoft kept us waiting for a few years promising future support before then retracting that, so we had worked on a long-term plan that isn't going to work out any more.

    I have been considering our options for the long term. I would prefer to ultimately move away from NW.js and Electron. The whole node component of these frameworks is both redundant and a major complication to supporting things like Steamworks. The node APIs are really complicated and difficult to maintain - I'm not sure what the situation with Electron is, but for NW.js every native addon has to be recompiled for every new version, which makes maintenance way more painful than it needs to be. Maybe things would be a bit better with Electron, but we'd still have node sitting in between native code and web code which makes everything harder. This blog outlines how the Windows WebView2 exporter is our ideal architecture: node is not involved at all - it's basically a webview that talks directly to our own simple extension system that involves posting JSON messages, and means we can write our own native integration with things like Steamworks, and they are forwards compatible so require minimal on-going maintenance. It's much much nicer than having to deal with node and our hope was to roll that out to macOS and Linux too.

    On macOS we already have the WKWebView export option, and it's possible we could add our extension system for that export option too. I was hoping to use WebView2 as it uses the Chromium browser engine and has better features for things like file system access. We could probably set that up and work around the missing features, although it will be more difficult.

    These days I think Linux support is actually more important, as it's what we need for Steam Deck support. NW.js does the job there for now. But we could perhaps look in to using something like WebkitGTK to essentially build a custom in-house wrapper for Linux, and then integrate our extension system for things like Steamworks support. This is a significant project and I don't have much Linux development experience so I'd have to get up to speed on that, but I think that's our most likely future direction, as a minimal in-house wrapper like we have with Windows WebView2 is actually much easier to customise and maintain. This is all long-term stuff though - it may be months or perhaps a year or two before anything appears on this front. For the time being we'll get by with NW.js.

  • The compositing mode option caused several other bugs. We don't want to support it because of all the other problems it caused. The problem here appears to be a bug in AMD's software, so they'll need to fix that - it's out of our hands, and working around bugs in other company's software by reintroducing a mode that causes a bunch of other bugs is not something that it's tenable for us to do. As ever the best approach is to go to the root cause and get it fixed there.

  • You do not have permission to view this post

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,378,260 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x107
    Coach One of your tutorials has over 1,000 readers
  • x61
    Educator One of your tutorials has over 10,000 readers
  • x2
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x35
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs