Ashley's Recent Forum Activity

  • I'll take a look at setting that up. Feature requests are regularly reviewed, but as I mentioned before, we get so many it is a very large amount of work even just to respond to them all in any useful way. If any suggestion you care about for any reason is closed due to expiring, and you still care about it, you can just resubmit it - you will only have to do that once a year.

  • It's normal that some cross-domain requests send a "preflight" request before the actual request, for security reasons. If the server is correctly configured then this shouldn't affect how it works. There's more information in the MDN guide on CORS.

  • See the guide in the manual on using an external editor.

  • The code in your initial post appears to be correct. Maybe you didn't set the right script purpose properties. The easiest way to get help is to share a project file, so others can see exactly what you've done - otherwise all we can do is guess.

  • As writing JavaScript code for a multiplayer game is a very advanced use case, the script API just gives you access to sending and receiving messages, and then you can write your own synchronization code on top of that. That's the approach used in Command & Construct.

  • Performance will most likely be absolutely fine and you don't need to worry about it. See Performance Tips in the manual for more advice.

  • Construct moved from UIWebView to WKWebView several years ago already. If you're seeing that message for an old app, exporting it with the latest version will move it to WKWebView. However if it's an old app, updating it may have some compatibility issues, so you might just want to leave it as-is - the warning only says they don't accept it for new apps, and existing apps can continue to use UIWebView.

  • I'd be willing to put each issue on its own 12 month timer, but I can't find an easy way to set that up - it looks like all the existing stock GitHub actions are for other management workflows, such as only closing issues if they are stale (inactive for a period of time), whereas I want to automatically unconditionally close an issue after a time delay.

    If anyone can point me to something easy that does that by mid-January I'll set that up, but otherwise I'll just manually close everything as originally planned - I'm too busy to spend long trying to figure out how to do custom GitHub actions.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If you're using PNG and JPEG, you're behind the times - at least use the modern WebP format, and if you are willing to reduce image quality to get smaller file sizes, then use the AVIF format for lossy images too.

  • There's not enough information here to be able to help. The easiest way to get help is to share a minimal project demonstrating the issue. E.g. make a new empty project with just a button that shares some test data when you click it; if that works, it's probably a mistake in your project, if it doesn't, then you can share that on the forum to ask why not, or use it in a bug report.

  • There's not enough information here to be able to help. In general if you believe there is a problem with Construct then please file an issue following all the guidelines, as we need all that information to be able to help.

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,447,881 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
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x63
    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
  • x36
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs