Ashley's Forum Posts

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

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

  • Closing, please see the bug report guidelines, a .capx is required. The guidelines describe why it's in our mutual interest for you to not send your whole project.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The only way we can actually verify we don't break or slow down people's games is to ship the change in a beta release, and my previous experience of this is much smaller changes had game-breaking results. Even just reordering the operations or putting brackets in a different place (e.g. (a * b) / c vs. a * (b / c)) can change the floating-point precision, increasing or decreasing rounding errors, and break some games which relied on the previous behavior. I already did a bunch of work optimising all this in the early days so it has pretty good all-round performance, and I just don't see the point of risking such enormous collateral damage for some pretty small changes.

  • This is due to the architecture of the Internet and affects any software trying to make connections. Your only options are either:

    a) run a TURN server and pay for the bandwidth costs of relaying all traffic for the users who cannot directly connect (this is what services like Skype do to work around it)

    b) wait for the IPv6 rollout which should alleviate the worst cases of NAT by having a much larger set of available addresses.

    • Post link icon

    We possibly did announce C3 too soon. Our intent was to

    a) start raising awareness of a new product coming out at some point in the future, and

    b) explain why Construct 2 development might be slowing down somewhat.

    However for the reasons I posted earlier we never felt like it was a good idea to announce anything further. So I can see the frustration. But I'm not sure what else we could do, other than e.g. announce something we're still not 100% sure will launch, and then distract sales away from C2 for something which doesn't even have a release date yet.

    We have actually been working on further hiring and are still looking in to some expansion - we just haven't made announcements yet. But Scirra has been bigger than just Tom and I for a while now.