Ashley's Forum Posts

  • I'd point out that, much like with our own bug reports, it will be much easier for the issue to be dealt with if you can share a public demo. A bug report may be handed off between multiple developers and teams before it's even assigned to someone - that works smoothly with public details, but if it's private, that process can become slow and complicated.

  • It seems to run perfectly smoothly for me on a Pixel 3.

    Usually if you have device-specific performance issues, it's something involving the system GPU driver. The best way to investigate that would be to file an issue to Google at crbug.com so they can investigate.

  • The console is showing connection lost errors. I tried another build and it worked fine with no connection lost errors. This suggests there's some kind of problem with the internet connection between you and the build server.

  • I had a quick look at this and there is actually a bug in Chrome that causes a problem in playable ads when using module scripts. I reported it to Google and they'll need to fix it. In the mean time it's best to switch the scripts type back to "Classic".

    I tried to work around this for the next release, but the restrictions on playable ads is so extreme, we basically have no good options to explore. I think playable ads can actually work with a zip of a HTML5 export, so you could try that as an alternative. The Facebook playable ad preview tool also seems pretty broken, so it's really hard to test this. I previously repeatedly tried to get them to fix it and they completely ignored me, so I'm not sure if the preview tool will ever really work...

  • I just tried an Xcode export and it worked fine. Maybe check your Internet connection is working.

  • Well, once again, if the object is half-way initialized, you can't guarantee all siblings will be there. It's a good case to illustrate this actually: suppose you create 3 siblings. When you create the first sibling, suppose you try to get the other siblings. They don't exist yet. You're only half-way through creating the first of 3 instances. It's impossible for the engine to resolve this: even if it created siblings on-the-spot when you asked for them, another sibling might ask for the first sibling again, which still isn't fully created, and you have an unresolvable cyclic dependency.

    In the engine we have post-constructor 'OnCreate' methods which run when everything has finished initializing, so we avoid this type of problem. I'm not sure if we exposed that to the SDK though.

    If not, I'll just move all the sibling and iid related initialization steps out of the constructor.

    If you can, that's the best solution, since you avoid all these complicated half-initialized problems.

  • Not all developers publish their addons to our website, including some people with commercial addons they sell independently, so we still wouldn't reach everyone if we did that.

    We made this clear in the release notes, in this forum posts, and by actually implementing the change in a beta release, so if it was broken presumably users would have been reporting that to you. This is the same way we approached the changes to the minifier last summer. Besides there seem to be lots of addon developers who aren't actively maintaining their addons, so I would think even if we reached out to everyone we could find (which as noted would still be an incomplete list), a bunch of developers would still not act on it until it's too late. We also can't be sure whose addons will actually keep working fine, and whose will be broken, and also it's not clear if most addons are actually fine and there's no significant problem, or if there's going to need to be wider changes. In this case since if you'd used strict mode - good practice since 2011, and already built-in to the addon SDK downloads - there was no problem, which seemed to be a signal it was probably a minor issue.

    I appreciate maintenance issues like this can be frustrating, but many platforms require regular maintenance (especially mobile platforms, as iOS and Android often have annual changes to their requirements), and it's impossible for us to force addon developers to check or fix their addons no matter what we do. I think there is some level of responsibility for addon developers to keep an eye on developer news, release notes, listen to feedback coming from users, and maybe do a quick test every couple of months after a new stable release comes out. It's something we have to do with Construct itself, and even then we occasionally miss things, which can be a pain but then we just take action and fix it as soon as we can.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I don't think it will be feasible to fix this, since IIDs are lazy-assigned (so GetIID() will actually go and assign IIDs), and if you do that during a constructor, the object has not finished being created yet so won't be found for IID assignment. There's probably a bunch of things that don't work in the constructor, because in the constructor, you're still in a halfway initialised state, and the engine is usually going to expect to see a fully initialised instance.

    So my advice would be: don't call GetIID() in a constructor. Why would you need to anyway? If I "fixed" this, I'd probably just make that throw an exception.

  • It is exposed in the scripting API, but as cssPxToLayer.

  • It looks like this issue, which is fixed for the next beta.

  • The Android WebView does not require Chrome. The Android System WebView is a separate pre-installed app that auto-updates. It does not matter how old the device is: so long as it has Android 5+, it supports the auto-updating Android System WebView, and so long as apps have had the chance to update since ~2017, it will be up-to-date. So it doesn't matter if the device is from 2015 or whenever - if it has Android 5+, and apps have had the chance to update in the past 4 years or so, it's supported. Again, I have no idea how any number of devices could fail to meet this requirement, or why any significant numbers of people would have the WebView disabled.

    Construct has been exporting Android apps this way since 2018, and such problems seem rare, so it does seem like a small number of devices are affected, although perhaps they are concentrated in certain markets. I'd also point out that the scale of distribution can magnify problems: if an app works for 99.9% of users, and you distribute it to 500k users, it will be broken for 500 people. So you might get a few hundred complaints and think there's a huge problem, but actually it's pretty small relative to the scale of distribution. You could also easily have comparable problems with native software, e.g. if some graphics driver bug crashes the game for <1% of users. Getting software to work for exactly 100% of users is really hard, no matter the technology.

    A huge range of apps, even native ones, require the WebView to work properly: mail clients, fitness apps, hybrid apps, all Cordova apps... if the WebView doesn't work, it will actually break tons of apps, including a wide range of non-Construct apps. So anyone who has a disabled WebView will probably have loads of other problems too.

    I think to complicate the matter some Android versions actually could use Chrome to serve the WebView if it was installed, which is why the Android System WebView could appear disabled on those devices, because Chrome was taking its place. If Chrome was removed, the Android System WebView presumably reactivates and takes over providing the WebView. This should all be working fine but complicates the picture when trying to figure out who has a disabled WebView, whether that actually breaks anything, and whether Chrome is required (it's not).

    The iOS equivalent is WKWebView, which is built in to the system and updates with iOS system updates. I don't think it's possible for it to ever be disabled.

    Google seemed to be moved by your request, cant you guys try to pressure a little bit more?

    Lots of people seem to think that we have loads of influence over Google. We don't. I file issues like the ones mentioned and regularly bring up issues affecting us whenever I get the chance to talk to anyone from Google. Believe it or not, a huge international megacorp does not rush to fulfill every whim of a small British software company with a handful of staff. I genuinely think it is more likely that they will act on these things if a large number of affected users are all also filing issues and also raising the problem. The more independent voices they see talking about a problem, the more likely they are to consider it a priority.

  • Hi! I hate being that pain in the neck guy who criticizes everythings but... Couldn't you like send like a dedicated email like about exactly that?

    We don't have an email list for all addon developers. We don't actually know who they are - addon developers work entirely independently to us. We also don't know whose addons are already compatible and whose addons actually need an update, since as the post explains, lots of addons should keep on working fine, especially if you were already using strict mode that's been a part of JavaScript since 2011.

    This change has also been live in Construct since r226 in late November, so if you needed to update your addon, it should have become clear at that point.

  • I've already spent a long time trying to optimise the event sheet layout. Unfortunately though the layout is all calculated by the browser, and improving layout performance in browsers seems to be a kind of dark art that is barely covered by any documentation or official performance advice. You can find some blog posts on the subject but they cover just the most simple, trivial changes that we're long past. So I don't really know what else could improve it. Maybe different browsers perform better.

    In short the more content that is visible (i.e. expanded) in the event sheet view, the more layout work the browser has to do. It's possible some combination of CSS properties would improve it, but we have little more than sheer guesswork to go on, and I already spent a long time on it. You can play around with it yourself tweaking styles in dev tools. If you find anything that makes a significant difference, I'd be interested to know what that is.

  • The browser layout is a bit slower than Construct 2's layout. It can make a difference in extremely large event sheets.

    As noted splitting events in to separate smaller sheets should help a lot, and is probably a good idea for organising your project anyway. Collapsed groups also don't need to process layout so help speed it up.

  • The Android System Webview is installed by default on all Android 5.0+ devices. It also needs to be v57 or newer - i.e. if it's had an update any time since 2017 - any time in the past 4 years - it will be able to run Construct games.

    Why any number of devices out there wouldn't meet this criteria is simply a mystery to me.

    If someone says to go and disable system components of Android, firstly that is not actually a good idea, and secondly that means the user manually broke the app, so there's not really anything we can do about that. The 'WebView not up-to-date' message does include instructions on how to fix the problem, but they're in English, so I guess maybe that's a hurdle. It's hard to comment further without understanding what's really happening. I'd have thought that by now, 99%+ of Android devices would meet the above requirement.