Ashley's Forum Posts

  • It should work in the Safari browser. It's hard to say more without more information. Note the feature will only work on a secure (HTTPS) host.

  • The details around exporting and distributing are covered in the tutorial Exporting to macOS with the WKWebView wrapper. (Note WebView2 is specific to Windows, macOS uses WKWebView.)

  • The default instance is an arbitrary one in the project. Even if this was changed to something more specific like "the first instance placed in the editor", this too can easily change as you edit your project - e.g. imagine cloning the first placed instance a few times, then deleting a couple including the first placed one. Since you just deleted the default instance it will have to choose a different one, so everything changes again. So in general I don't think there's any way to choose a default instance that is immune to changing based on editing your project, which is why it's left as an arbitrary one.

    The intent of the design is either they're all the same, so it doesn't matter, or you set the properties you care about by actions after creating the instance, in which case it doesn't matter what the starting properties were.

  • I believe this is a problem with some Android devices, not Construct. An issue has been filed with Google so they're aware of it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The only reliable way to remove an addon from a project is to have the addon installed, open the project in Construct, and remove all references to it. If you delete things from the project files directly, you could easily corrupt the project.

    You can also use the 'Bundle addons' feature to ensure the addon is saved with your project, avoiding any problems with having to install the addon to open the project.

  • I'm afraid we don't support languages with a right-to-left writing direction at this time.

  • It's difficult to help without more information. We can see in our stats that opening project folders is used hundreds of times a day, and as far as I'm aware it's working fine for everyone else. This is why we ask that if you run in to problems to file an issue following the guidelines.

  • You do not have permission to view this post

  • The error is reporting a missing file named testspritefont.png. Perhaps you accidentally deleted or renamed it? Putting it back should fix it.

  • Press F12 and check the browser console for any further error messages.

  • I know file system access is used by lots of games, which is why I talked about still implementing it, but in a way compatible with browsers. Then you still have file access, and you can test it in the browser.

  • Project folders are specifically designed for extra-large projects. As far as I'm aware they're working fine, and we have many users with projects hundreds of megabytes big who like to use that option.

  • Yes, the change has been live since r235:

    IAP: update cordova-plugin-purchase to v10.5.0, which uses Google Play Billing Library v3

  • I think it's rotating the camera, not the actual layer.

    I guess it's kind of inconsistent, but unfortunately this type of thing is pretty much impossible to fix without breaking thousands of existing projects. So we'll probably just have to live with it.

  • NW.js itself has been a regular source of difficult and complicated bugs and issues in the past, which is why I would prefer everyone moved over to using it in the browser instead. It tends to work better there.

    The only reason now to use NW.js editor is really just for convenient testing of the NW.js plugin. But even then you could use the editor in the browser, and use Remote Preview for NW.js to test the NW.js parts. You could also design your events to still do something useful when NW.js is not supported, e.g. fall back to placeholder data instead of reading files from disk, so you could do most of your testing in-browser anyway and then just occasionally remote preview or even fully export to test the NW.js parts.

    The new Windows and macOS desktop wrappers are much simpler and should be highly compatible with browser features. It's also possible to add extra runtime features like file system access in a way compatible with browsers (e.g. how Construct can use files on disk in Chrome). So in the long term I'd like to move to a world where the NW.js plugin is basically replaced by browser-compatible alternatives. Then there shouldn't be much need for NW.js left at all by the end - especially not for the editor. (But for backwards-compatibility, we'll likely keep supporting the NW.js export option for a long time anyway.)