Ashley's Forum Posts

  • For the record some discussion and details was covered in this (now closed) issue.

  • Moved to "How do I" forum. Sami424 - I don't think the question involved AJAX.

  • If Android manufacturers ship devices with out-of-date software and updates disabled, I don't think there's much we can do about this. It's the same problem as shipping an old version of Chrome with updates disabled, and then finding that certain websites don't work. Obviously if you want to make sure new content works then the software needs to be up-to-date. If you disable updates then you make newer content broken by default. So it's a terrible decision to make it the default.

    The C3 runtime requires more modern browser features than the C2 runtime, but it should still work if there is a webview available that has been updated any time in the past 2 years. I am mystified as to how even older webviews could have any kind of prevalence on the market...

  • It's telling you what to do to fix that. Is there a reason you haven't updated those apps? Is the message not clear enough?

  • Yes, it covers that.

  • It's very difficult to help without a lot more information. What exactly is the full text of the error you are seeing?

  • Are you using the C2 runtime? There was a bug where the action was accidentally exposed in the C2 runtime, but it is only supported in the C3 runtime. It's fixed in the latest beta.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If you are happy to write JavaScript code, you can communicate between local frames and windows using the postMessage() API.

  • That won't work if you minify the export, because the runtime method names will change.

  • Well, thats exactly the kind of thing you should be able to make your own performance measurements of... but for what it's worth, Construct does drawing work for every individual tile, so the total drawing work will always be proportional to the number of tiles. However I think in the C2 runtime, if the tile texture is the same it doesn't need to switch the texture, which is faster. (In the C3 runtime it can render the entire tilemap without switching texture at all, even if every tile is different, hence the large performance improvement.) But either way it's doing drawing work per-tile; in the C2 runtime the amount of work per tile depends on the tile.

    The technologies involved are super complex - few deeply technical questions come down to a simple "yes/no" answer. You shouldn't expect things to be so straightforward, and you shouldn't get upset if you can't reduce complicated topics to such a simple answer.

  • So try switching to low quality fullscreen mode instead.

  • To fully remove an object, delete it from the Project Bar. Note this will delete any events using it, so first you'll probably want to add the Local Storage plugin (which was introduced to replace Web Storage), move all your events to using that instead, then delete the Web Storage plugin.

    FYI Web Storage was replaced with Local Storage back in 2015, so it must be a pretty old project!

  • The C3 runtime always uses high DPI display mode. If you want to render at a lower resolution than the display canvas, use low-quality fullscreen mode. Turning off high DPI was essentially an inconsistent device-specific way to get low-quality fullscreen mode.

  • AFAIK that workaround is correct. We used it ourselves for Construct's debugger and it solved the problem. So there must be something else about your case that is breaking it. Unfortunately I could not say what that is. iframes aren't specific to Construct, maybe you could ask on another site like StackOverflow.

  • If it works, it works. It means if you change any of the existing properties in the layout, newly created objects will also get changed values. Sometimes that's what you want, other times not. The only unpredictability is if you have multiple instances in the layout with different properties; in that case Construct will pick one of them as the one to copy from (and deleting instances or changing properties may or may not change the values a newly created instance gets). However it's common that all the objects in the layout have identical properties, so it doesn't make a difference.

    Maybe calling it "safe" or "unsafe" is the wrong term, it's just a game design point really. In general this approach seems good enough to not unexpectedly cause values to change as you work. Even if they do change, you just need to add some actions to set the values you want for newly created objects and it works around it. So it seems like a pretty minor point.