Ashley's Recent Forum Activity

  • Honestly if this is causing you so many problems and affecting the support of a published app, you should not be using beta releases. It can sometimes take a few weeks just to review bug reports, because most of our resources are going on C3 now. Also the whole point of beta releases is so we don't have to scramble around issuing fixes ASAP (which puts additional strain on the development process) - we'd do that for stable releases, but not betas, the whole point is they're there for testing.

  • It's probably easier to publish to the web (which runs on Chrome OS) than Android, so I'm not sure how compelling this really is. I guess if IAP/purchases work as well that could be interesting?

  • It probably depends on the minimum version/build number chosen when publishing to the Windows Store. For example if you chose a minimum build 10586, all the devices still on 10240 will be marked unsupported.

  • The bug report guidelines explain what to do in this situation.

  • Sorry, Steam's distribution means you can only have one version installed at a time. The standalone version can have multiple versions installed at once.

    Beta releases are mainly for testing - we've always said it's important to back up your work and only use them if you're willing to face issues.

  • It's probably a problem with the adblocker. I'm not sure there's anything anyone else could do unless you report it to them.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I don't think any of that changes the basic fact that you can't pretend asynchronous code is synchronous. It breaks assumptions like the events will run in any particular order, which the existing system makes obvious by making you use triggers in a separate event. Anything which looks like a simple comparison/access but really is asynchronous in the background would be even worse than we have now - it would just silently break or fail to work as you expect in random situations!

    I wrote up an idea for a "then" event to try and make things like this easier, but it's not supported and I'm not sure how much it would really help anyway: https://www.scirra.com/forum/idea-make-async-easier-with-quot-then-quot-event_t128870

  • A common technique is just to load and save an entire Dictionary object's JSON which covers most of this.

    LocalStorage is asynchronous (i.e. setting/getting fires a trigger after a moment, rather than being immediately available) which means it can't really be mapped to anything synchronous (like setting/getting global variables). If a "get global variable" or similar turns in to a "get localstorage value", that value is not immediately available, and may fail as well. So that's not actually possible, without some kind of internal caching mechanism, which is basically the same as doing the save/load dictionary object technique.

  • The rationale for why Ejecta was deprecated was explained in this blog post (it was done over a year ago): https://www.scirra.com/blog/154/evolving-construct-2s-export-options

  • It's most likely your network configuration preventing it working rather than anything to do with Windows 10. See Troubleshooting Construct 2's preview server.

  • In general, I really can't help without a minimal .capx demonstrating the problem (ideally with just 1 or 2 events).

  • This is my main point:

    By all means hack away and experiment for your own learning purposes, but we will probably not use any of the changes, and we cannot offer any support if you have made a single change to the engine.

    So you can hack away if you like, but we can't exactly copy-paste snippets of code from the forum to our engine. (There's also copyright concerns and code licensing - I just thought of that )

    Off-screen collisions always count, and if you have a lot of different collision checking events, they all count too. So if you have 25 objects and you test collisions between all of them, that's already 600, suppose you have four repeated sets of events which makes it 2400, then at 60 FPS it's 144,000 checks per second. So you can easily fill large collision check numbers even with a small number of objects. The key is to reduce collision checks to only objects which need it, and eliminate redundant collision check events. (i.e. use sub-events to a single collision check event, rather than making the same check in different places)

    Again, nothing specific to Construct 2 there, it's just maths. But C2 does make it easy to accidentally make loads of checks, because things like checking every combination are implicit.

Ashley's avatar

Ashley

Online Now
Early Adopter

Member since 21 May, 2007
Last online 27 Oct, 2026

Twitter
Ashley has 1,832,537 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
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x6
    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
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs