Ashley's Recent Forum Activity

  • Existing ideas aren't deleted - they will just be closed and tagged with something like "Archived 2024", so you can still see them all, but they won't be under active consideration any more.

    There are all sorts of ways we could organise this and I don't think there is any one perfect way. Sure, we could auto-close suggestions without enough votes, but there is now unlimited voting, so everyone could just vote everything up enough so nothing much ever gets closed, and then the system has failed to keep things fresh again. It's also possible something gets highly voted, but then sits there for several years, becomes redundant for other reasons, but then never gets closed because it remains above the threshold.

    The main thing I want to avoid is the feature suggestion list building up with 10+ years of work with such a huge list of individual suggestions that it's too much time for us to even review or administrate it all properly. Over long periods of time it then also ends up full of all sorts of older ideas that are redundant or no longer important for other reasons (e.g. at one point "make an OUYA exporter" would have been popular - now it's irrelevant). Then from our point of view it becomes something of a millstone around our neck: it's such an impossible amount of work it's stressful to even prioritise or consider it, and people start to get more negative about it ("this has had X votes for Y years, why haven't you done it already?", "look at Scirra ignoring the community", etc.)

    So by that point it's no longer an effective system. That's pretty much what happened before, and I'd rather avoid anything that might end up the same way. Closing everything and starting afresh every year might be annoying for some, but submitting an idea you care about once a year isn't a huge amount of work. If you have dozens of ideas we probably can't do them all anyway as that ends up creating an infeasible amount of work for us, so we want people to think carefully about their requests, and only submit the most important ones, not flood us with impossible amounts of work. If something remains important and popular, then I expect it will keep coming back every year and being voted up again, and we'll take notice of that.

  • If you believe there is a problem with Construct please file an issue following all the guidelines - that's our process for sorting out anything that might be working incorrectly.

  • It sounds like webview2 was more of an experimental thing, that hasn't really worked out.

    NW.js is pretty much unmaintained at this point, and is gradually accumulating weird problems that aren't being fixed and are getting harder and harder to work around, and is also very difficult to integrate custom native code with. I would not be surprised if NW.js is retired at some point soon, so part of our recent efforts is to mitigate this if it happens. WebView2 on the other hand is actively maintained by Microsoft, they've already added a significant feature I requested, doesn't require constant maintenance from us, and is much easier to integrate custom native code with our wrapper extension architecture (some of which are also significant benefits over Electron too). So I'd actually say it's the other way round.

    When it comes to the handling dual GPU systems (and other things like the Steam Overlay), I think these come down to the multiprocess architecture of browsers and the way third-party tools work which are outside of our direct control. These also remain risks for NW.js and Electron - if you have to rely on hacky workarounds to get things to work with them, and one day the workarounds mysteriously stop working, what then? You need a proper solution, which is what we need to get working with things like WebView2. The best way to do that is to contact GPU vendors and ask them to fix it. I've got in touch with NVidia and AMD to see if they can adjust how their drivers work to support WebView2 with the NvOptimusEnablement/AmdPowerXpressRequestHighPerformance approach. However I would encourage all those affected to also get in touch and request the same thing. People commonly over-estimate how much influence we have: we don't have friends in high places and we usually can only do what anyone else can, and so the best way to make sure our requests get noticed is to have as many of the affected people also request the same thing so they see the popular demand for it. So if you're concerned about this, or other issues beyond our direct control like the Steam Overlay, please add your voice and get in touch with the companies responsible and request changes. Given the risks and maintenance difficulties of NW.js and Electron, we're going to be going ahead with retiring NW.js anyway, but there's going to be ~2 years more of support via LTS for NW.js. So assuming we get some co-operation from the community and the companies responsible, that should be enough time to make sure everything we need for WebView2 is in place before NW.js support is finally fully retired.

  • What GPU does the device have? Going from 1080p to 4K will require about 4x the GPU power in high quality fullscreen mode, but using low quality fullscreen mode will keep it about the same. 4K is really very high resolution and you'll generally need a powerful GPU to match, so often if you upgrade your display to 4K you may well need a new GPU to power that many pixels.

    If you want to render at 1080p quality and then upscale to 4K, the way to do that is to have your project's viewport size set to 1080p. But if you've already designed your entire project for a different viewport size, that might be a tricky change to make.

  • I don't think support for modules covered the editor scripts. You could use something like a bundler though to combine some editor modules in to a single editor script.

  • If a server is responding with a 403 error, that usually means "Forbidden", so that would be a permission or configuration issue with your server.

    Construct projects now only support iOS 15+ and cannot run on older versions of iOS and will show the "software update needed" message on those devices. I'm afraid it's simply not feasible to support old iOS versions forever, and we have to occasionally increase the minimum requirements to be able to keep improving Construct. The vast majority of devices in active use support iOS 15+. For example the newest iPhone that only supports up to iOS 12 is the iPhone 6 which came out in 2014. That's a decade ago, and quite often the device battery simply won't last that long and so people end up buying a newer device; if they did, it will support iOS 15+ (see this table).

  • In that post, I mentioned an update in r417 that may help, but nobody has responded to that yet - it'd be interesting to know if it made a difference for anyone.

  • We've seen a number of such reports but we've not yet been able to identify what causes the problem. Our best guess is a browser extension is interfering with Construct and causing the problem. Try disabling any browser extensions you have and see if that fixes the problem. It would be useful to know which browser extension caused the problem if you can identify that (try disabling them one-by-one).

  • Try using the File System plugin.

  • Is there a way to animate an icon?

    You can use [tag] in BBcode to tag a region of text - perhaps just a placeholder icon - and get its position. Then you could put an animated Sprite object there - which allows for using any other features in Construct (effects, behaviors, other kinds of objects like Particles, etc.)

  • Even if we did this, I'm not sure it would be sufficient for all those use cases - if you want something like a private message channel to multiple users, or different levels of group chat, then you need a dynamic number of Multiplayer instances. Even if you can add more Multiplayer instances, then how many do you add? Then setting up your event sheet to be able to manage them as if they were an array sounds complicated.

    Things like an "Alert" server that just sends a global message out every now and then would be a relatively simple case for a WebSocket connection to a custom server - re-using Multiplayer for that seems a bit overkill.

    Another option is to run the host on a traditional headless server - it's not especially straightforward to set up, but then you have better privacy as things like private messages are routed via a generic server rather than a player's machine. Even with the host being a player, it's possible to set up an encrypted messaging system between two peers so the host still can't read their messages, but that's a fairly complicated cryptography case. (Maybe the Cryptography plugin could help...)

    So I think if we wanted to do this properly, the single Multiplayer object alone would have support for connecting to multiple rooms simultaneously. I think that would be a pretty complicated change to make though. Even if adding multiple Multiplayer objects is straightforward, in the long term there will probably still be a need for truly dynamic room joining, and so there'd still be a need for the proper multiple simultaneous rooms support; then if we did implement that, we're left with a messy design, as there is no longer any need for multiple Multiplayer instances but we're stuck with that short-term measure for backwards compatibility reasons. So with a long-term view, I'd rather do this the proper way, even if it's more difficult. It's always tempting to choose the easy option, but it can make a mess in the long term, and we'll still be here dealing with that.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This just came up in this thread as well where I already responded.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,397,861 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
  • 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