Ashley's Forum Posts

  • 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...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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

  • newline is a Construct expression. Those cannot be directly accessed from JavaScript.

    In JavaScript, if you want a string with a newline in it, use "\n".

    I think based on what oosyrag wrote, and what I was also explaining, using dB for volume is the easy intuitive way to do it.

    If Construct has a 0-1 linear volume, then either your volume control works wrong (nonlinear perceived volume), or you have to do some complicated logarithmic math to get a linear perceived volume (e.g. doing the dB conversion yourself, or some other exponential formula). As oosyrag pointed out there is a simple linear calculation you can use when the units are dB.

    So if you think linear 0-1 is actually the simple intuitive option, are you saying you want a nonlinear perceived volume - which AFAIK no other software does - or that you want to do the logarithmic math yourself - which I wouldn't describe as the simple or intuitive thing to do?

    Or if you want Construct to map 0-1 to dB for you, then surely someone will want to control the dB range and cutoff, so it actually makes it a more limited option.

    Perhaps all we need is an expression to map 0-1 to dB for you - e.g. linearVolume(-50, x) will map x as 0-1 with a -50 dB range/cutoff.

    I'm not sure what the standard approach is, because I don't know what every software developer in the world has done with their volume slider, but I would say an easy solution is that each step is a lower amount of dB, with a special case for the bottom one being -Infinity dB (or just enable mute). Maybe -10dB per step will do it, I don't know, I'd just play around and come up with something that seems right.

  • It looks like you were exploiting the lack of proper encapsulation in JavaScript to use undocumented and unsupported APIs. The addon is already at risk of breaking at any time. We had a big red warning in the documentation saying not to do that.

    This is the very problem we're trying to solve with the Addon SDK v2 - you should not have done that, we said we wouldn't support anyone doing that, and that support for such features could be removed at any time.

    You'll need to find a new way to do this in the Addon SDK v2, or submit a feature request.