Ashley's Recent Forum Activity

  • Support for the Game Center plugin was deprecated in r413. As far as we can tell it gets very little usage, very few iOS users use Game Center, and it was difficult to maintain.

  • With the File System object in a Windows WebView2 export, it can be done like this:

    • When you want to save (e.g. on pressing 'S'), use the Save to JSON system action
    • In the system trigger On save complete, use the File System action Write text file to write to something like picker tag "<documents>", folder path "mygame/mysave.json", with text set to the system expression SaveStateJSON

    That will then save the current game state to a path like Documents/mygame/mysave.json in a desktop exporter like Windows WebView2.

    To load you can do what amounts to the same thing in reverse:

    • When you want to load (e.g. on pressing 'L'), use the File System action Read text file to read from the same details (i.e. picker tag "<documents>", folder path "mygame/mysave.json") - but use a file tag like "loading"
    • In the File System trigger On file operation complete, enter the file tag "loading" again - this triggers when the save file has been loaded. Then use the system action Load from JSON to load the expression FileSystem.FileText.

    That's the basic pattern - once you get that working it shouldn't be too hard to vary it for multiple saves (just change the file path). You could also use List content to find the existing save files.

  • My experience with using AI for coding even with very widely used languages (e.g. JavaScript and C++) is it's good for beginner level questions but is pretty clueless when it comes to advanced questions - and it never seems to say "I don't know", instead it makes up answers that are either wrong or useless. Another problem is it often uses out-of-date techniques. It seems if something has been correct for 10 years, and then a year or two ago it was deprecated and replaced with something else, the AI keeps advising to use the deprecated approach, probably because there's more training data for it. It doesn't seem to know about relevancy or API lifecycles - after all they ultimately come down to predicting the next word - and so even when correct often the information is still out-of-date.

    Construct is less used and so has less training data than those other languages, so unfortunately that means it will probably struggle even with some more basic questions. It's a problem on the forum too, where sometimes people answer questions with what look like AI-generated posts which sound plausible but are in fact completely wrong or misleading, and then I (or others) feel obliged to step in and issue a correction, which takes up more of our time. For this reason we've had a "Please don't use AI" rule in our Forum & Community guidelines.

    Perhaps AI will end up changing the world but I have to say, at the moment, it doesn't seem to be that clever yet.

  • It looks like this has already been reported here.

  • Take a look at the MIDI input and MIDI output examples. You can find them in the Example Browser.

  • The official multiplayer signalling server at multiplayer.construct.net appears to be working normally and has a lot of activity on it at the moment indicating a lot of people are currently using it.

  • I'm not sure you need to do either of those things - if you want to swap one sound for another, you could have a variable of the name of the sound to play, and then just change that variable when you want to switch it for another sound. That way there's no need to delete or modify actual sound files.

  • There did indeed appear to be a problem with iOS exports using Mobile Advert - we did some server maintenance yesterday and it looks like some of the build service configuration got changed. I just changed it back and it looks like it's working again - apologies for the inconvenience.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Really the only reason we use CEF on Linux is because Linux doesn't provide a built-in system webview (or at least nothing consistent enough to depend on) like WebView2 on Windows and WKWebView on macOS.

    If we have two export options for the same platform it's twice as much as much work to develop, maintain, support, document etc. and that directly reduces our capacity to make other improvements to Construct, so overall I think such a move would overall be a bad outcome for Construct.

    The Steam Overlay is a known issue, but:

    • Steam has fallbacks to handle the in-game overlay not being supported - it shows the actual Steam UI instead
    • I don't think that is a serious enough problem to warrant the large amount of work both up-front and on-going work it would take to have a secondary export option
    • I couldn't actually get the Steam Overlay to work correctly on Linux desktop with CEF either - so even doing all that work is no guarantee it will end up working
    • The Steam Overlay never actually worked that well with NW.js either - we had a bunch of hacks to get it working (and it would be the same for CEF), and those hacks could stop working at some point, which would leave us in the same situation needing Valve to fix it
    • It's entirely possible that Valve could fix it for our existing export options and then it's all sorted with no need for secondary export options (and Valve fixing it would also make sure it works much better with NW.js/Electron/CEF)
    • The Steam Overlay works fine on the Steam Deck, because it works differently (drawing in a layer over the game instead of intrusively modifying the game executable). So that demonstrates if desktop platforms worked the same, it would work fine there too.

    In short, if there are two major features to do the same thing, it is a lot more work and a continual drain on our limited resources, and it's confusing for users too. In my view the best approach for the long term is to focus on one solution and resolve any problems with that. In other words: if you have one major feature and it has a problem, and your solution is to introduce a whole new second major feature, now you have two problems.

    I found tons of reddit threads of people uninstalling their WebView from Windows because they don't like too many background processes.

    Well, that's a crazy thing to do in my opinion, but our WebView2 exporter is designed to prompt the user to install WebView2 if it's missing, so it should not be a major problem - if someone uninstalled it, a Construct WebView2 export will prompt them to reinstall it.

    Maybe as a side-note: are there plans for Scirra to also develop their own Mobile Wrappers?

    At the moment Cordova does the job well, so I don't think there is any reason for us to do that. In particular there is a large existing ecosystem of Construct plugins using Cordova plugins, so moving off that would be far more painful than changing the desktop export technology.

  • If there isn't an API covering it in the documentation, then it's not supported and you'd need to post a feature request. However your workaround looks reasonable - get the URL from the event sheet and fetch that as a blob. I've definitely seen worse workarounds!

  • Construct does now require Intl.Segmenter support in the browser. Firefox only added support for this in v125, but that was released in April last year - the current version is v134. The latest Extended Support Release (ESR) is v128 released back in October, so even those sticking to ESR releases have a supported option. Therefore we deemed support good enough to rely on it in Firefox. The error message advises what to do - the browser is out of date and needs updating.

    Support in Chrome was indeed added in v87, but that was released over four years ago, so I don't really know why anyone would still be running such an old version of Chrome unless their entire system is no longer supported. In general it's just not feasible for us to support old browsers forever - the web platform keeps improving and we want to make the most of that, and sometimes that means increasing the minimum requirements. With Chrome and Safari we try to make sure we're compatible with around 4 years of past releases. In this case we made an exception for Firefox and brought the minimum version up as it was the last browser to support a key feature that allowed us to make internationalization improvements, we waited long enough for the latest ESR release to support it, and these days Firefox usage is (sadly) much lower than Chrome or Safari so the impact of such a change is reduced.

  • Please don't cross-post the same feedback in multiple places - I already addressed this in this comment, but now the discussion is split over two places. (See the Forum & Community guidelines)

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,422,587 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
  • x108
    Coach One of your tutorials has over 1,000 readers
  • x62
    Educator One of your tutorials has over 10,000 readers
  • x3
    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