Ashley's Forum Posts

  • I just published an update to the Steamworks addon (v1.4.1) which includes the authentication ticket features. Let me know if it's all working for you.

  • My telepathic debugging skills aren't working in this case and I have no idea. You'd need to file an issue following all the guidelines for me to be able to look in to it.

  • Yes, in summary, NW.js is fully removed in r450+. We marked it deprecated in r421 back in January, and support for NW.js will continue in the r449 LTS releases until the end of 2026, so that's an approximately two year time span over which it will have been phased out.

    This also came up on Reddit and I explained in much more detail why we've done this in this comment. I won't repeat what I wrote there here, so do go and read that for the background on this.

    Broadly speaking it is time to move everyone over to our own desktop export options. The maintenance work is a key consideration as we are a small company with limited resources, and maintaining two options for desktop exports is a significant drain on resources, particularly given how tricky NW.js is to maintain and customize.

    runtime.js:1 Uncaught (in promise) TypeError: this._runtime.IsNWjs is not a function

    Oops, that shouldn't happen - fixed that for the next beta.

    I also presumed that we could still choose to use NWJS, but no support provided from Scirra

    If you are happy with that, you will still be able to use NW.js in the r449 LTS releases indefinitely, even past their official support period. We have never taken down old releases. Every past release we've ever made is still available on the releases page and it'll stay that way.

    What if Scirra decide WebView2 is not the path to go with

    I am well aware how difficult these transitions can be, and I can assure you we absolutely plan to stick with WebView2 (and our other desktop export options) permanently, and would only change technology again in extraordinary circumstances. In particular with Windows WebView2 and macOS WKWebView we are using the webview built in to the system, which is a key thing we want to avoid having to ship an entire browser engine with exported projects. No other technology can offer that other than the system built-in option.

    I'd have thought encouragement of Node.JS would be the path to promote

    It was different in the past, but at this point, the entire node.js component of NW.js is basically redundant. It provides a large API surface, but geared towards server-side development. It does not do things like out-of-the-box support for integrating the Steamworks SDK, and in fact it makes that a lot harder, as all your C++ integration has to go through the node.js layer, which also has some really awful compatibility issues (at least in NW.js). Our new wrapper extension model basically means you can write C++ code that directly interacts with JavaScript via a simple messaging system, which makes it much easier to integrate custom native code.

    I do apologize for the inconvenience of these technology switches, but in the long term they are absolutely necessary. I know they are painful and these are not decisions we take lightly. As I mentioned in the r450 release notes, Construct 3 has been around for about 8 years now, and we need to think about where we'll be in another 8 years and longer. These kinds of decisions are difficult but important to ultimately ensure Construct is still a great product that keeps improving and remains competitive.

  • Thanks for the kind words all!

  • In the import map, the relative paths are relative to the root of the scripts folder. So you don't need to worry about which subfolder you are importing something from if it uses a name defined in an import map.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • So it's solved now? Can you share what solved it in case it helps others? In particular if disabling a browser extension fixed it, it would be useful to know which browser extension was the problem.

  • I've implemented this for the next release of the Steamworks plugin. If you're feeling brave you can try the code already on the GitHub repo which supports Windows, but otherwise I will update the macOS/Linux builds next week and release the update.

  • As with import statements, in the import map you need to start paths with ./ for them to refer to files in the project. If they start with /, that is (I think) interpreted as a URL relative to the root of the origin, which will happen to work in preview as that runs on preview.construct.net, but won't work on export.

    So you should start those paths with ./. I'm not sure what you mean by this:

    This makes you revert back to relative paths, but now you can't use the same import map key because the path to the file is different from different directories.

    You should be able to use the same import map key everywhere. The location you use it doesn't matter.

  • In the second video you need something to start playback at runtime. The easiest option is to use the 'Start on layout' property of the timeline.

    In the first video it's hard to say much without seeing the full project. Perhaps you have another behavior or some event sheet logic that is also moving the same object and conflicting with what the timeline is doing.

  • It's not entirely clear to me how this all works - looking at GetTicketForWebApiResponse_t in the documentation, it looks like you get both a HAuthTicket (really a uint32) and m_rgubTicket which appears to be a block of binary data up to 2560 bytes long. Do you only need the HAuthTicket?

  • No, exports are one-way (very much by design, as lots of people are concerned about their exported projects being reverse-engineered). You can however export and only extract the exported web assets, which I think end up in app\src\main\assets\www. That will update the project but preserve your existing Android Studio project. Note however if you do make a change that affects other parts of the Android Studio project, such as adding plugins or changing settings, this approach won't update the Android Studio project to match. So another approach could be to use source control and every time you export over your Android Studio project, you can review all the changes and decide which to keep and which to discard.

  • Well, for now the answer is "use the Android Studio" export option.

    What reason do you need to change those settings though? For example turning off resizableActivity should not be necessary, as Construct content generally supports any window size with its letterbox scaling mode. I don't think hardwareAccelerated affects much for Construct content - it always uses hardware-accelerated GPU rendering to the canvas regardless of that setting. Enabling usesCleartextTraffic sounds like a bad idea - you should just be using HTTPS for everything these days.

  • There are lots of things that influence the content of the Android manifest, but they are all either built-in or handled by plugins. What is it that you want to change that is not covered?

    Construct's build service doesn't give you an opportunity to edit the Android manifest as it just directly uploads your project and builds it for you. Part of the reason we have the Android Studio export option is to provide an alternative where you can do things like make more advanced customizations if you need to.

  • By far the easiest thing to do is to publish the game to a new URL, and point everyone to that new URL.

  • I think it makes sense - another way to phrase it would be "collisions only include solids with these tags" (inclusive) and "collisions exclude solids with these tags" (exclusive).