Ashley's Forum Posts

  • I don't think anything has changed, it's just a (not entirely appropriate) warning message that you can ignore. It doesn't stop you publishing - if you can't publish it must be for a different reason.

  • See the AJAX manual entry which covers this.

    • Post link icon

    Really? It should have just transferred it locally. If it's that slow it sounds like it's taking a roundtrip over the Internet for some reason.

  • There's an existing official tutorial How to collaborate on projects with SVN. It's aimed at C2 and using SVN, but it should work similarly using both C3 with folder saves and Git.

  • I don't know, I can only guess from descriptions like that. It's easiest to share a project demonstrating the issue.

    • Post link icon

    Towards a replacement for previewing with NW.js, here's a simple way to get Remote Preview working in NW.js:

    • Download nwjs-remote-preview.zip
    • Download a version of NW.js from nwjs.io (note: download the "SDK" version if you need dev tools)
    • Extract both zip files to the same folder
    • Run nw.exe - you should see the Remote Preview page
    • Remote Preview from the browser-based editor, and paste the remote preview ID (or the full URL, it still works) in to the ID field in the NW.js Remote Preview and click 'Go'

    Then you should be previewing your project with full NW.js features enabled, e.g. writing to local files with the NW.js plugin.

    I'd be interested if you have any feedback on using that as an alternative.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I think the memory usage guide in the manual and tutorial on Construct 3's export optimisations should answer all of these.

    • Post link icon

    Third-party services are a lot of work and are also generally high-maintenance - Nepeo has done a ton of work for the Mobile Ad plugin and it requires regular updates too. We don't have the resources to cover all possible third-party services, especially when pretty much every individual user suggests different services that we should support. This is part of the reason we have an addon SDK, so other developers can pitch in without having to wait on us. Meanwhile in practice many developers continue to publish to the app store anyway, so the pragmatic thing to do is to add features to support that, which we have done with Mobile Ad.

    Remember there's a big difference between not having the resources to do something, and not being interested in something. I'd love to do hundreds of suggestions and integrate hundreds of services. It's simply not feasible though.

  • The approach taken in the manual is that since loops are part of the System object, they are documented in the System section. Since it is not strictly related to the Pathfinding behavior, it is thus not covered in the Pathfinding behavior section of the manual.

  • See the Integrating events with script example.

  • Our policy for some time now has been that Construct 2 is no longer going to get any new features and is only receiving occasional bug fixes. It was first released in 2011 and won't last forever - at some point it will be retired. So I would suggest starting to move over Construct 3 now so you have time to figure out details like any changes that need to be made in the switch (see our guides on Importing C2 projects and The C3 runtime). If you delay, the risk is you will end up being forced to do this work anyway but on a tight deadline. There's loads of new features in C3 over C2 too.

    • Post link icon

    The goal is to eventually delete all the desktop app specific code in Construct. A quick search shows over 60 places in the editor code where we branch off and do something different for desktop apps. It adds a lot of complexity and maintenance cost to the codebase, such as dozens of often awkward desktop-specific bugs, when we'd rather be spending our limited development resources on other things,. It also kind of defeats our generally very effective strategy of having a single product and single codebase, which is one of the reasons we've been able to keep up with much better resourced competitors.

    Removing this code means even third-party launchers will no longer be able to activate desktop features in Construct 3. Besides we could not offer support for that code if anything went wrong with it after that part of the product had been officially retired. Therefore even if we just left it behind and ignored it, there's a high chance it will eventually break and stop working anyway. So I'd rather fix any remaining problems, then retire the desktop builds, delete all the code they used, and get everyone to migrate off it in one go. Having a lingering usage of unsupported desktop apps with people still getting upset when it breaks is something I specifically want to avoid. I think dealing with the pain of a change up-front is actually better for everyone in the long run.

    There are still a few things to do, such as sorting out an NW.js preview alternative. I think Remote Preview should be able to handle that. Part of the plan is to identify these gaps and fill them in before we make the change. So please plan on the assumption you will be switching over - don't assume that there will be any support for desktop builds at all in the long term.

  • Collisions have nothing to do with SVG or the GPU. So I'm still confused as to what you're testing or asking about.

  • I just tried it and it worked fine. This is exactly what I would expect: without a full bug report following all the guidelines, it's impossible to investigate the problem, which is why we ask for all that information.

  • I'm not clear what you're testing any more. Are you now looking in to intensive collision benchmarks or something? That doesn't sound specific to SVG Picture in any way.