EDIT: Rewrote to be more concise, despite being a wall of text still.

Is NWJS "fully" removed on r450?

If I save a project that has the NWJS plugin, then upgrade to r450, then preview, I see error along the lines of:

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

I presumed that NWJS was deprecated, so that you can still use your project with NWJS if you had the plugin added, but most stuff is "hidden away", so no exports and no adding the plugin. But judging by this, I take it that NWJS is removed from the core of C3 in whatever way C3 used to detect NWJS? This would mean all past projects with NWJS plugin cannot be run on r450 until it is removed?

I also presumed that we could still choose to use NWJS, but no support provided from Scirra, so we would be on our own to export via HTML5 and mash it together with NWJS if we wish, or if a new NWJS version broke the deprecated NWJS plugin, then Scirra won't support this.

If it is intended that existing projects with NWJS plugin must remove the plugin entirely to use their project:

This feels rough, my choice to use NWJS has backfired and stalled me. I abruptly need to remove NWJS plugin, which is deeply ingrained into my project. Maybe there were warnings (or maybe it is unintentional that projects are erroring), but oh mann I was eager to try the new Text improvements in r450 (which deeply affect my project when I unexpectedly encountered this when migrating my project to WebGPU-only effects. I had worked around it for a month or two, with poor results, but didn't want to pester Scirra, and assumed it was a Chrome bug, but then got excited to see the update).

Repeating what is known - WebView2 is not quite there yet. Very close but not equal to NWJS. Steam Overlay (fallback not ideal), supress the "fullscreen/Mouse pointer lock" popups. WebView2 feels more restrictive whereas NWJS feels more adaptable. I liked how C3 integrated fixed builds for NWJS, but WebView2 we must follow a guide externally. An advanced user may enjoy other aspects of NWJS, such as using Node Modules for further enhancement of their game (e.g. enabling Toast notifications on desktop).

NWJS's Steam Overlay relies on an experimental Chrome flag, a risk that some players cannot play or get crashes. Personally? No hesitation, I'd enable that flag, it's important for my case. I'd rather my game behave like a standard game and not split into many processes, I want Steam Overlay/Achievement popups, I want OBS to behave as it does with any other game that is a single-process (Yes you can still record a window, but, if there's a choice to make it consistent with how OBS detects other games, I'd choose that). I don't care for any performance/stability reasons to avoid that flag, it is an optional flag that we can choose to use, it works fine for most, but if it didn't, you can offer a 2nd build on Steam with the flag disabled. All doable with NWJS, but WebView2 prevents all of this, there is no choice, and that sucks bad.

I feel distrust towards WebView2 and slight distrust on following the Scirra path of EXE solution (again, only if this NWJS plugin issue was intentional and expects us to remove the plugin to preview our projects). Had I used Electron years ago, I wouldn't be suddenly panicked about what to do to update to the next beta. I'm thinking "what if" since this is now occurring: What if Scirra decide WebView2 is not the path to go with, due to slow rate of Microsoft response to WebView2 bugs/requests (such as the slow response to the "fullscreen" popups), or if Microsoft/Valve both say "No" to resolving the Steam Overlay issue and C3 cannot ever have Steam Overlay unless changing EXE solution - Some plausible situation like this happens, then Scirra move on to the next EXE solution, repeat this loop of killing projects until they remove the old plugin, etc. Such a time-sink for us trying to work on our games (and I empathise with the headache this causes Scirra to deal with). Where I mention distrust to Scirra's EXE solution, this means that I currently seek to find a way to continue using NWJS and am opposed to moving to WebView2, at least as of now. Still love practically every other decision Scirra makes, I am not going anywhere.

Another point of distrust to WebView2, was what we saw with WebView2 being cross-platform - a promise then a rejection, so it's not far-fetched to distrust the future of WebView2.

I also struggle to find "real-world" examples of WebView2 games on Steam, I think I encountered one months ago, but it's so rare to find, whereas NWJS has indeed had success out there with big named titles from RPG Maker and such. I can't peek at reviews to gauge what players experiences are like with WebView2, I can't Google info about it, it's way too new/experimental.

I think I've missed the point of why NWJS is no longer viable. It had been for years, since C2 days. I recall FileSize being the downside, but surly I am mistaken - FileSize matters for browser-based games, but rarely for Steam games.

I want to crack on and work on my game, but I'm rewriting stuff to fit in with SDKV1, WebGPU, and now WebView2. I'm happy to, and really try to recognise Scirra's goal and follow the philosophy. SDKV1 feels necessary, WebGPU provides a tangible benefit, but WebView2 is a downgrade as of now.

LTS will support NWJS still and have build server and presumably NWJS gets new versions added and bugs that arise will be fixed for LTS, the workload for Scirra still happens for the duration of LTS to support NWJS but the primary version of C3 won't benefit from this work.

I could use LTS version, it's a great addition, but what awful timing for my case with the WebGPU Text improvements, it's vital I can utilise that, especially after all the months of effort of mangling my project to not use WebGL effects.

Last lesser point, it feels antithetical for WebView2 to rely on C++ addons. I don't believe there's many addons for over a year, besides one companion addon? I imagine it's more difficult than the typical addon to create, and may have less chance of attracting community members with the skillset to make these. I'd have thought encouragement of Node.JS would be the path to promote - More JS shenanigans to mess with and unlock more power for desktop builds (not to mention the huge repo of nwjs modules that exist now).

The community has aided me to understand that, you can still use NWJS, just do it as JS event blocks. This is viable, but must I really have to re-interpret every NWJS action (as I made essentially full-use of NWJS plugin) into a JS event block/function, and figure out the more complex ones like loading into a Binary Data object (which again, heavily used in my case). Whyyy when it was working so fine just one version ago. :(

My apologies for the reactionary post. I fear the workload of having to move to FileSystem plugin, which may not be a simple swap-n-replace since NWJS was sync and FileSystem is async - And it feels like work that will just result in a downgraded end result when it comes to exporting.

Everything can be hacked but webrtc is encrypted and can only really be exploited with complex man-in-the-middle attacks where the attacker already had access to the victims device (which, as you'd know as a pen tester, is already the worst possible situation if the attacker has admin access to the victims device).

The fake game scenario, what message could be sent that allows RCE attacks? And if an exploit was found, this would be patched by Google/other browser devs.

Let's assume an attacker could send messages to fire "execute javascript" actions - this would be limited only to the game/tab and would behave accordingly as a browser does, e.g. The attacker tries to get geolocation, then the victim will see a popup asking to allow/deny geolocation, which they would likely deny.

File transfer, again I would not worry: let's say someone sends a virus exe file. Victim receives this... The victim cannot run this exe through a Construct game (unless very specifically using NWJS - Open Shell action, which, I would imagine is rarely used). Even if somehow the exe could be transmitted and executed, the victims device would have windows defender/antivirus software, most of which test an exe in a sandbox, or simply delete the exe if it is potentially dangerous, so no worries there.

But, yeah, any game engine, godot, unreal, unity, anything - can be used to make malicious software, esp with multiplayer functionality.

It's not the company's or Scirra's fault if someone designed their game poorly where geolocation data is easily sent unwillingly sent due to an oversight from the game dev, or easy packet sniffing/sending (I presume webrtc makes resending packets not viable).

Things like NWJS have already been used maliciously outside of Construct, to make cryptominers and such that run silently on the victims device. It's probably why antivirus software flag innocent exports of NWJS (or it relates to the exe being signed, who knows).

All in all, I wouldn't worry about this, and would only worry about how a game dev designs their multiplayer code - hopefully not having a game that relies on geolocation to play and has multiplayer, and peers have a button that a peer can click, to get host to gather all peer's geolocation data to send back to them. That'd be foolish and that game dev would certainly have a tarnished reputation after a stunt like that!

EDIT: Ninjad by dop2000, lol. I echoed similar things, but yeah.

for example, if he using the global object as invisible while the Construct says is invisible cause is a html5 interpreter u are correct... but u have to take in consideration all objects in screen are rendered by canvas... even if the system is saying is "invisible" once in screen they are actually transparent

This is incorrect. An object marked as invisible is simply not rendered. You can test this with a blank project, have 3000 onscreen objects (and 1 other object moving so that the game ticks and provided measurements in the debugger), make them visible and invisible, and see the gpu improvement when they're invisible.

now in ur suggestion if is 1 object shouldnt do a big impact... however stacking that invisible object with 100000 variables that will take over globals to save "events" is a trade off i wouldn't even consider.

Its worth considering, but it's nice we have the choice on which path to take. An object's instance variable list, for all intents and purposes, is a dictionary - you can have 1000s of inst vars and would barely notice cpu difference, even if reading/writing to them often.

from mistakes like "forgetting what that invisible sprite does" to lets say u have a project team member coming in sees a object that has "seemingly no purpose" and deletes it, then all the game engine brakes.

This should never happen, because a team of C3 devs would know to right-click and use "find all references" on object they are unsure about. If they find references on the mysterious hidden object, they'll quickly realise what it's for in all the events they are listed. If they use "find all references" for the specific instance variable, again, helps here. Lastly, when you delete an object that has any events, it will warn you about deleting and ask if you'd like to "find all references", which the dev should be checking before deleting.

thats why i suggest better use json, arrays, dictionary anything that its purpose is to keep number values, text values by default.

I do agree with this! Dictionary is like an enhanced "instance variable" list, with extra benefits like getting the variable by name (which inst vars cannot do) deleting and adding new ones at runtime (again, inst vars cannot do) and link them to many different objects at once if ever needed, rather than adding inst vars repeatedly to multiple objects, or using family instance vars (which, both are great, but a dictionary being able to just link up to any object type, or even a family, is excellent).

The one benefit to a hidden sprite, is behaviours, like tween or line of sight. But you still could use a hidden sprite for those, but store vars in the dictionary.

i find myself more then 50% of the time, implementing ideas, patching things, then not commenting and going back to comment and i forget what everything does, and just stare at it and im like "it works, it made sense at the time, but what does it all mean" xD

Lolol yes, many times this happens. Or better yet, you think "wow wtf why did I design it this way, it could be way better!".

but considering C3/C2 is mainly used for tablets and phones, i know from past experiences sprite objects, and many instance variables on them, will glitch, like the variables will fail to be read and written.

This, I have never heard of, nor encountered. It should be reported as a bug if you can reproduce it. Does this bug happen with like 1000 inst vars, and does it happen with a dictionary with 1000 keys?

especially a sprite is easy to delete by mistake, or change its designated state by simply adding it in a familly by mistake, and then "woops" the familly gets destroyed when shot, and now ur invisible sprite that holds all user data gets removed or cleared.

I disagree - you could add a dictionary or JSON or array into a family by mistake, too! But if someone does this, then that's user error. Even ignoring the topic of a hidden sprite, if it's just regular game and someone decided to add an FX into a family that doesn't belong there, then they would indeed get unexpected results and must fix this or remove them from the family.

now memory wise you are correct once outside the screen no memory is used, C3 engine doesnt render nothing that is outside the screen.

Correct, and it doesn't render when onscreen but invisible. (it renders if visible but opacity is set to 0, iirc).

but is easy to remove a sprite by mistake once outside the screen.

But why? What if a preloaded particle was offscreen and invisible, why is it easy to delete it? Devs need to be more alert when they're tampering with the unknowns in a project!