Ashley's Forum Posts

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

  • Please file issues here following all the guidelines, otherwise it is impossible to investigate the problem.

  • The free edition is limited to 2 effects. Your project uses 3: 'Lighten' effects on PRESSSpace, PRESSShift, and ButonFake.

  • Support for specific gamepads is usually determined by whether a driver for the gamepad is installed on the system. Different systems come with drivers for different sets of gamepads preinstalled, so if it doesn't work you might need to find an additional driver.

  • Sorry, I missed this first time around. I've added a AddCommonSceneGraphACEs() method for the SDK in the next release, which is currently what determines scene graph support. Note to support scene graph your plugin must be prepared to have its geometric properties controlled by the runtime when it's attached to a parent, and it must support all the possible transforms like position, size and angle.

  • It must be something listed in the comparison table. I can't tell which without seeing your project.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This sounds an awful lot like: "being at the mercy of Microsoft", if any new major issues occur. I know that NWjs and Electron aren't perfect but with those bloated wrappers, developers can at least stay or up/downgrade the version at any time, to workaround any new major issues.

    On the contrary, I'd say NW.js is actually the cause of most such issues, and avoiding using it will avoid these issues. The unmodified browser engines go through very stringent testing, including testing labs, and broad release on the canary, dev and beta channels with active use by global developer and tester audiences, before arriving at stable. NW.js makes various modifications and doesn't go through that testing process (or not as thoroughly), resulting in a regular series of of NW.js-specific issues where things actually work fine in the unmodified browser but are broken in NW.js. Therefore I think using an unmodified browser engine, which is what WebView2 does, should actually be more reliable than NW.js. As I mentioned before, many web exports have been working fine for years, so I think historically the compatibility has proven very good.

    It's also possible to distribute WebView2 with a fixed browser engine, but you lose the size advantage, and have to go back to shipping your own updates. Given how good web compatibility has been historically, I think getting browser engine updates for free is actually a benefit.

    I think Android's webview implementation, is already a prime example of webview not being the best option.

    Android is a whole other operating system so I don't think this has any particular bearing on Windows. I'd add that on the whole I think the Android Webview does work well. People don't tend to write forum posts saying "everything worked fine", so you can get a skewed impression from the forum sometimes.

    WebView2 feels more like an opportunity to improve Construct 3 Desktop to me.

    My goal is to not have to have a Construct 3 Desktop at all, and do everything in the browser. I think we're actually quite close to achieving that, especially since the editor can use file access now.

    (Maybe this is also a great time to look into Electron as another option for desktop distribution but that goes a little off-topic.)

    Electron is architecturally the same as NW.js (Chromium browser engine + Node.js), so I wouldn't expect anything to be materially different with that. The point of this experiment is to remove a significant amount of complexity, maintenance complications, and release management, and go as far as possible to having a minimal lightweight wrapper. Having nobody else involved between us and the WebView actually makes things a lot simpler and, since complexity always adds bugs, more reliable. That's part of what this WebView2 experiment is aimed at. The fact it makes different tradeoffs also makes it a more interesting alternative to NW.js - for example if you really want a tiny file size overhead, Electron is not particularly interesting as it has a similar overhead to NW.js, but WebView2 is as it has a tiny overhead.

  • There are several free edition limits other than the event limit. You can see the comparison table here.

    Subfolders are not allowed in the free edition, so if your project has a subfolder, it exceeds the free edition limits.

  • Could the WebView2 auto-update feature ever break games?

    Just like with publishing HTML5 games, it's possible that browser updates can break projects, but it's generally rare. There are old Construct 2 exports from years ago that still run just fine AFAIK.

    Avast currently recognizes the file as a threat

    That's a concern, but there's probably not much we can do about it - generally all unsigned executables are viewed with suspicion by both the OS and antivirus software. Usually if you are a serious about publishing to Windows you'd digitally sign the app, which increases the level of trust. Without signing trying to evade antivirus is a losing battle - there are probably dozens of security tools out there, and lots of malicious people have spent years trying increasingly clever ways to evade them. The best approach is probably to report false positives to the antivirus vendor. One of the under-appreciated benefits of web publishing is you never have this type of problem!