How do I NWJS killed by Scirra when i need local file with

(I tried to ensure my word choice and tone didn't violate Scirra's censorship bias, so I repeatedly put my speech into Google Translate to make the article look more friendly.)

I'm going crazy. This company keeps removing its features even as its user base dwindles. The only correct update over the years is single-file the playable ads one. Other features, like SDK V2 and now the potentially huge NWJS, have been removed instead of being enhanced. Many of my projects that depend on it are now like garbage. Unlike addons I can upgrade from C2 to C3V1 and then to V2 myself, but remove NWJS in this closed-source terrible doesn't allow i change my export selection. Or I supposed to develop a Node.js environment for C3 myself? This is insane. I believe this is like the Qing Dynasty or ancient Indian royalty: Scirra comes up with some cool ideas, and then a few followers reinforce their determination to make the wrong decisions. I don't care anymore; let's see how far they go in one of many wrong direction. Maybe being acquired is a good outcome. Anyway, how am I supposed to manipulate local files as easily as before? Now I can only run two C3 projects: one for the actual work of the new version, and one for manually pasting event sheets into .net/r449-3/ LAST VER OF REAL C3. I don't know how much longer I can continue like this, it's not cool at all, C3 has a bunch of inexplicable limitations. It knows how to unreasonably prevent various behaviors, but it won't clearly tell you when something goes wrong. Anyway, I don't care anymore. Is it really as convenient as NWJS now? That poor webview for Windows is truly poor. What's the point of this kind of webview in 2026? Is it just for 8 years old students to use, is it just a decorative item to make C3 look cool because it supports many platforms, but it has no native functionality? I'm really disappointed. After so many years with C2 then C3, I'm questioning whether I should be like the blindly loyal minority, unconditionally supporting Scirra, even if they push themselves to an extremely wrong position. Should I still praise them? No I Can't! In the Web3 era, since everyone agrees that Sprites object are extremely inconvenient, why not just release a Web3 standard "Image"? At least I could just paste data or a URL to just display an image, instead of going through many complicated steps to play with Sprites. One line of HTML + JS code in C3 becomes many lines. And today I want to use NWJS... Is Scirra now forcing me to develop even NWJS myself? I've already developed many unnecessary plugins, such as multi-multiplayer. They could do it in minutes, but they refuse(Not just me, search the forum will see at lease 3 guys making the same addon, Now i am the only one guy who finish this horrible job, at last).

They're making things increasingly complicated, deviating further from a simple, direct, and user-friendly approach, and moving towards even more extreme closed-source development. I suspect C3V3/C4 might even block upload addons altogether. Their current Store development direction strongly suggests they'll directly connect C3/4 to their Store, depriving you of your last bit of freedom, right?(They are proud and dislike "overly free" communities, so a central add-on store aligns well with their current direction, Otherwise, the forum removed a place to publish addons, now half-forcing you to pay developer fee to their store. It's laughable, why? cuz Scirra has forgotten the success of C2 and is resting on its laurels, They think success is achieved through their own efforts. That's why they will to block or delete any posts? Happy to "remove" loyal people away, leaving only those who blindly support them. Eventually, the community becomes quieter and quieter, with fewer and fewer people. Enthusiastic people leave year after year.

Okay, How am I supposed to use C3 like I used to with NWJS? I can't possibly read every single Scirra post in 2026 like I did ten years ago (besides, they don't seem to be doing anything serious these days; it's more like they're pursuing diversification, deleting good stuff and adding what they think is good, wasting a lot of time like still the best: Animation lol, I'm sure Scirra will suddenly release some great ideas soon this year that waste a lot of effort but are ultimately unpopular).

How can i use new C3 like NWJS C3? or i should remove myself from construct.net

What's your question? How to use local files without nwjs? Use the file system plugin.

Or are you asking how to export a windows executable?

What's your question? How to use local files without nwjs? Use the file system plugin.

Or are you asking how to export a windows executable?

like work in native a line of code to read file, not the limited file system plugin

This does the same thing. What limitation are you having trouble with?

i copy your code and that's not working, even if this code works, it turns what was originally a simple line of code into a huge amount of code. I don't understand why events in 2026 will become more and more complex every day, doing the same thing, but with fewer features (such as resizing the window/retitle).

Did you export or just test in preview? The predefined folder tags only work in export. As for why it's more complex, the simple answer would be for security.

Browsers impose security restrictions to ensure that general web browsing is safe. Therefore they start with no access to local files or folders at all. The only way to gain access to local files and folders in a browser is to show a picker - a "save file" dialog, an "open file" dialog, or a "pick folder" dialog.

Desktop exporters like Windows WebView2 are an exception to this rule and can have direct access to certain special folders like the user's documents folder without any dialogs or permission prompts

In Windows WebView2, macOS WKWebView and Linux CEF exports, the browser permission model can be bypassed to directly access folders such as the user's documents folder. This is done by using pre-defined folder picker tags like "<documents>". These act like the folder was already picked on startup. You can check if these are available on startup by using the Has picker tag condition.

The security part is no free access local disk access from browsers without user input, thus requiring picker tags. On export the local safe folders are fine, but the preview runs in the browser, so it won't work.

Besides that, asynchronous file operations to local files has its advantages and disadvantages, and asynchronous is what we have to work with now.

Exaggerating something 10 lines of code doesn't help your case much - it went from one to two events. And could probably go back to one if you used the wait for previous action to complete action, but I haven't tried. If you're experienced with large projects then one additional event out of thousands should not make any noticeable impact on anything in your workflow, besides having to learn something new (which you also have an option not to, by using whatever version of C3 you are more familiar with if you want).

Otherwise if you're going to keep this belligerent approach then I'd just assume you're just rage baiting and not actually looking for help. Then good luck with your project.

For context, this Reddit comment I posted a while back explains some more of the reasons from moving away from NW.js. I know these transitions can be disruptive, but in the long run it's necessary to improve things, and by now the new exporters should support pretty much everything NW.js used to, such as with the File System object for accessing files and folders on disk.

I'm actually glad we moved away from NW.js, because shortly after the move, this bug broke support for Steam. As the relevant feature is undocumented and unsupported, nobody is obliged to fix it, so it may well be broken permanently now. I always knew it was a risk relying on things like that because of the chance of exactly this scenario, and that was part of the motivation to move away from NW.js. Luckily we avoided that particular nightmare. Presumably if we had stuck with NW.js, that bug would be causing serious problems, and everyone would be demanding a fix or talking about other better technologies we ought to be using instead. Also moving to new technologies has enabled further improvements, such as better support for dual-GPU devices in the latest releases.

In these cases we have to choose between continuing to suffer the faults of the technologies we've already chosen, or switch to better technologies and do our best to smooth the transition between them. If we have to choose between short term gain with long term pain, or short term pain with long term gain, in the end it's always best to choose the latter.

If you want to keep using NW.js, you can - it's still there in the r449 LTS release. Our stats show the vast majority of users are on the latest Construct release and also the vast majority of desktop exports are now for Windows WebView2, macOS WKWebView, and Linux CEF instead of NW.js. So I'd say that basically the switch has already happened, which means it's a bit late to be asking to change anything back.

If you want to keep using NW.js, you can - it's still there in the r449 LTS release. Our stats show the vast majority of users are on the latest Construct release and also the vast majority of desktop exports are now for Windows WebView2, macOS WKWebView, and Linux CEF instead of NW.js. So I'd say that basically the switch has already happened, which means it's a bit late to be asking to change anything back.

Okay, I have said what I want to say. I hope the development direction is benign. BTW, which one does nwjs.appfolder correspond to in the new one? to get the location of the c3 running file .exe?