Ashley's Forum Posts

    • Post link icon

    Please note: the feature will become unavailable in Chrome 85 after Wednesday September 30th. It will be available again in Chrome 86+, due for release next week.

    The underlying feature in Chrome for file system access was previously in an experimental state, and the experiment is ending on September 30th, making the feature unavailable in Chrome 85. The reason the experiment is ending is because it is now enabled by default and available to all websites in Chrome 86+, which is scheduled for release on October 6th. This means there's an approximately one week gap in between where the feature will be disabled in the latest Chrome release.

    The one-week gap is actually an intentional part of the way Chrome handles experimental features. It is designed to ensure websites using the feature rely on detecting the availability of the feature rather than a specific browser, since relying on browser detection has been a long-standing compatibility problem for the web. (Construct of course already relies on feature detection, which it uses to decide whether or not to show the save options - which is why you may see them disappear.)

    As I've previously noted, experimental features are subject to change at any time. (I've also updated the editor for future releases to more clearly state that experimental features are subject to change at any time). If you need to use the feature during the intervening week I would advise to use Chrome Beta, which is already on version 86 and therefore has the feature enabled. Alternatively you can temporarily go back to using the other save options like Cloud Save. Once everyone is on Chrome 86+ in a few weeks, the feature will have fully graduated to a widespread stable release, so there should be no further such interruptions to the availability of local file/folder save options in future.

  • The minify option on export is for extra processing of the built-in runtime scripts. We don't provide any support at all for directly modifying runtime scripts, nor do we want to encourage anybody to do that, so we don't really actually want to provide unminified runtime scripts. Use the addon SDK or the JavaScript coding feature to integrate your own JavaScript code.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'm afraid I've no idea what might help. Apple make Xcode, not us, I don't know what could be wrong or what might help. As I said, you need to be contacting Apple support over this, not asking us.

  • I've already done several iOS exports as part of my general testing and development work, and they all opened fine. To double check, I just did another iOS export and opened it in Xcode 12.0.1, and it opened and ran on an iPad just fine. So it seems to be working fine here. I'm sure Construct is exporting valid Xcode projects and so the problem is not with Construct.

    Anyway, as I mentioned, we can't fix problems in Xcode - that's up to Apple, so if you have trouble, you'll have to contact their support.

  • I'm afraid we can't help with issues in Xcode itself - it's made by Apple and any issues with it need to be reported to them.

    There was an Xcode 12.0.1 update recently which fixed a crash, so it may be worth checking for an update to Xcode.

  • If you use third-party addons, you frequently end up relying on them for long-term support. I don't think many people fully recognise this. That's why it's really important to make sure any third-party addons you use for any important projects have reliable developers who are willing to provide long-term support for them. Otherwise you end up in the situation where you really have to update something, but you're stuck because of a third-party addon. And I'm afraid that's not our responsibility - it's not us who caused the problem, it's up to the developer. And long-term support can be difficult, so probably involves paying somebody.

    It's kind of a similar point with bugs in browsers, OSs, drivers, etc. From time to time, people insist - sometimes forcefully - that we fix problems in other people's software. It's literally impossible though. Giving us extra money won't make it possible. Choosing other technologies and rewriting our entire engine in them won't make other people's software suddenly start working perfectly again. Insisting harder and more forcefully won't make it possible. This has always been the case, and is true for all software. Some people end up calling me stubborn or irresponsible for insisting we can't fixing these problems, but it is neither possible, nor our responsibility, to fix other people's software. We can sometimes add workarounds, but sometimes we're just stuck. It's just an immovable fact of software development and there's nothing to be done - except get the people who make the other software to fix it - if you can get them to care!

  • You should not need to modify any files. The iOS simulator should work with the latest Xcode 12+. (Older versions don't support it, because the bundled iOS simulator did not support WebAssembly, but Xcode 12+ does support it now.)

  • The Apps category on the Chrome Web Store was retired back in 2016.

  • You should only use WebM Opus audio - it's the only format that plays on all platforms. Construct provides its own Webm Opus decoder for iOS so that the format is supported there.

    Audio playback should work on iOS. It's hard to say more without more details, such as a sample project.

  • The first picture shows an Xcode project for iOS. The second picture shows an Android build failure report. You cannot convert Xcode projects to Android.

  • You can always disable Construct's JavaScript minification on export. But that doesn't appear to be related to this.

  • Another example is that the "Save to folder" option disappeared one day randomly

    FYI, that's an opt-in experimental feature, and experimental features are subject to change at any time (as indeed it did). It should be shipping as stable and enabled by default soon.

    Another observation I've seen from other users: Even though you're paying a subscription, you will find you will be asked to "report your bug to X company" and such

    We always had a similar policy with Construct 2 as well. If the problem is with another company's software, you need to report it to them - we can't fix other people's software for them. It's usually quicker to cut out the middle-man and report issues directly. And if we can't reproduce the issue ourselves, we can't file the issue on your behalf anyway, so reporting it yourself is the only option.

    Bugs and other quirks and issues always come up with software - we work really hard to make a reliable and robust product, but nothing will ever be perfect. Like most software, Construct 2 always had its own quirks and issues, and people often made similar remarks about Construct 2 as well based on that.

  • The information about mapping.txt appears to refer to a different type of obfuscation that is not related to JavaScript minification. So I don't think doing anything in Construct or adjusting your minify setting in export will have anything to do with this.

  • For the record, setting the text size to TextWidth/TextHeight isn't necessarily going to fit the complete text in. Text metrics are actually super complicated. You have all sorts of different baselines (e.g. hanging, middle, alphabetic, ideographic...), different languages extend different distances above and below the line, certain unicode combinations can extend indefinitely in an upwards or downwards direction (e.g. z̻̗͜a̦̥̱͖̝͓͉l̡̤͕̟̝̟̻g͎̹o̡̫̲ text), and so on and on.

    So when you say "how tall is the text?" it's not actually particular clear what you are measuring. Which baselines are you going from? Does it include all ascenders and descenders? Do you want it to keep extending with things like zalgo text? How do you make sure it never cuts off any of the text with any possible combination of text, font and languages?

    This is compounded by the fact the web platform currently doesn't expose all the text metrics we need to answer all of these questions (as noted in this old issue about vertical text alignment).

    This issue appears to refer to BBcode altering the text size not being taken in to account in the calculated text height, which is a different type of problem - but even if that's fixed, it still won't mean that setting the text size to TextWidth/TextHeight allows all the text to be visible, because of everything I just mentioned. Basically you just have to add some padding - but unfortunately at the moment there's no way to know how much padding is needed exactly, and it's different depending on the text/font/languages you want to cover. So, you'll just have to guess...

  • Measuring text immediately should work in the C3 runtime. The workaround where you had to wait a tick was something that only needed to be done in the old C2 runtime.