Ashley's Forum Posts

  • Please download the standalone version from www.scirra.com, install that and test it.

    • Post link icon

    Please, feel free to develop your own console engine. But note you'll be shouldering the costs and risks I mentioned earlier. If you find a third-party company who have already dealt with Construct games, they will be a long way ahead.

  • Yes. It is only used on the server responding, it doesn't apply anywhere else.

    This is an essential part of security on the web. For example, it prevents random websites obtaining your Facebook profile picture without your permission.

  • As far as I'm aware iOS and Android publishing has been working the whole time. Our stats show thousands of users publishing to Android and iOS every week.

    The main problem people have with Xcode and Android Studio seems to be that ultimately these are tools aimed at developers with programming experience, and involve a certain degree of complexity. It can be difficult for non-technical Construct users to make the jump, especially since these tools are not themselves perfect, and have their own bugs, quirks and configuration requirements that are nothing to do with Construct, and will have to be dealt with no matter what tool or framework you use.

    One example is there appears to be a bug in Google's own AdMob library that causes the app to crash if it is misconfigured. If you configure it correctly it works, but you have to follow the steps carefully and do everything right. The crash is nothing to do with Construct, it's squarely Google's fault. But unfortunately as with any complex technology, people don't always recognise the different layers involved and end up blaming us instead.

  • I don't think it's possible, I'm afraid.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I asked if the standalone version is affected, but it doesn't seem clear from your answer whether it is. If you use the non-Steam version of Construct 2, does that also slow down?

  • The image on cloudfront.net does not send an Access-Control-Allow-Origin header. So no, it's not correctly configured. You can check the headers it sends in the networking panel of browser dev tools.

    • Post link icon

    I'd point out that as I mentioned, people can, and do, publish their Construct games to Switch and PS4 using third-party companies.

  • Construct has long supported collaboration using existing source-control tools like SVN and Git, through its folder-based projects. See this tutorial on using SVN for more details (it's written for C2 but applies to C3 as well).

  • Can you identify the specific release where this changed or are you saying it's always been like that?

    Is the standalone download affected?

  • Note that string syntax like that will be broken in advanced minification mode. If you want it to work even with advanced minification, use dot syntax: 

    runtime.globalVars.myglobalvar = value;

  • That would be a cross-domain image then, so the usual CORS stuff applies.

  • Have you looked at the safe area expressions in the Platform Info object?

    • Post link icon

    I'd add that while it's technically possible, for us as a small company I don't think we really have the resources to pull off official console ports. A very significant reason Construct has as many features as it does is because we truly have a single codebase that works on all platforms. There are also significant hurdles to writing native ports - this blog post on the prospect of native engines is quite old and a bit out of date now, but still covers some relevant points.

    Even if we only aimed for a single console, it would probably take around 12 months, tie up basically all our development resources essentially putting everything else on hold; being web-first, many features would probably be infeasible to port (e.g. do consoles do iframes? SVG? form controls? video? networking?), making for a complex support matrix and increasing the difficulty of actually porting your games to console; and it would likely tie up significant resources even beyond completion, as console SDKs are a moving target with regular changes, and opening a whole new class of bugs where there are differences between the web and native engines. Meanwhile there are considerable risks: I'm still surprised at how few people appear to use or even talk about the Xbox One exporter, so it seems entirely possible we do all this work and hardly anyone uses it; maybe it takes so long that by the time we finish the next console generation is out and we have to start over; maybe they actually do add support for HTML5 games at some point making much of our work redundant; and due to all the risks and complexities involved it could end up being extremely expensive - if you think $99/year is expensive for Construct 3, note GameMaker charge $799 per year per console exporter, or $1500 per year for multiple console exporters - and they're a bigger company with more resources to put towards that.

    Don't get me wrong, I'd love to have more console support for Construct. It would be huge and a dream for many people. However looking at all of the factors involved, it seems awfully close to an extremely risky bet-the-company gamble, and I don't think we can justify it. The de-facto setup of a couple of third-party porting companies who maintain their own engines based on compatible subsets of C3 is kind of awkward, but seems like the best compromise we have right now.

  • Is it a remote URL? If so, the cross-domain stuff applies.

    If it's a local URL, it's tricky since your game is not actually uploaded. Requesting something like "image.png" will send a request to "preview.construct.net/image.png", and your image does not exist at that URL. Normally you can just use sprites and tiled backgrounds anyway, loading a local URL seems like an unusual thing to do when you can just embed it in the game.