Ashley's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Again, the best solution is to make sure it can update, not disable it completely. If it never updates on a correctly configured web server, please file a bug. But I strongly suspect it's a web server sending responses that are cached long term, which naturally precludes the ability to change the content. You need to make sure the cache can be bypassed or eventually expires at some point.

  • There's a difference with infrequent, long-term software releases that reach their pre-announced retirement. Nobody expects support past their end date, and people can plan for it. I know that even if you understand the way the support works and wouldn't complain, lots of people definitely would. This would also include cases like schools with a lab full of students ready to take a class, and then suddenly they find their software isn't working, even though we released a fix for it. Also as someone who really cares about producing good quality software, I just can't face the idea that we'd shrug this kind of thing off; we have an obligation to support our software and ensure it works for people who have paid for it, and we cannot simply shirk that responsibility without going through a formal retirement process. This is why people would rightly get angry about it.

    Meanwhile, as of right now, if you use Construct r182.2 or older with Chrome 80+, it crashes when you drag a bar. Old releases like r83 crash on startup. This type of thing happens. We have around 16 stable releases and the numbers always going up - supporting all of those with on-going bug fixes would be a nightmare. And doubtless we'd be dragged in to endless debates about precisely where we draw the line for what qualifies as an essential fix that gets backported to past releases - everyone will have their own personal bar for that.

    I'd add even with Construct Classic we had to make occasional updates to track things like new Windows versions, and even Windows Updates that broke things. I do remember checking once and I found it didn't work out of the box on one system without further configuration, so it probably is in need of maintenance, but it won't get it since we formally retired it.

  • Well, that's a problem with koji that they should fix. If the server is correctly configured it will auto-update normally.

  • The relevant error is "Error: behavior 'Lite Tween' not supported in this runtime". It sounds like a problem with the Lite Tween third-party addon. Normally Construct prevents you switching to a runtime that is not supported by a third-party addon in your project. Perhaps you updated the addon to a version that is incompatible with your project?

    You can send your project to ashleyzux@scirra.com and I'll take a look, but I'll need the exact version of the Lite Tween addon, and any other third-party addons you're using.

  • It's very difficult to say anything from this information alone. Press F12 and check the browser console for any error messages, that might help shed some light on it. Also sharing your project will let me look in to it myself.

  • What is the koji service and what's bad about the way it works there?

    People often ask questions like "X doesn't work on Y. Can I turn off X?" where really the right solution is "fix X to work on Y".

  • See this blog on the effect compositor I wrote a while back, and remember that all of that is written with low-level OpenGL commands like these.

  • Refer to the AJAX manual entry. It covers common mistakes, especially when dealing with cross-domain requests, or requests in preview mode.

  • It's a fundamental restriction of browsers. What are you trying to do? Why can't you use NW.js? That is the best answer.

  • A recent update to the Ukrainian translation has resulted in 155 mistakes. The list is available here: https://www.dropbox.com/s/8316gix9fcfj3qh/log-uk-UA.txt?dl=0

    They will all need to be corrected before the in-progress translation in the Construct editor is updated again.

    Please do not use machine translation, like Google Translate, when translating Construct 3. It is an inappropriate tool that results in poor quality translations. These translations will then fail later quality reviews and have to be re-done, resulting in wasted effort and taking longer before the translation is ready.

    • Post link icon

    I'm curious, are you using Construct's existing support for Xbox One? If not, why not?