Ok so if I understand correctly you've modified the NW plugin to have a "close app" action. But to me there should be a way for the basic behind-the-scenes runtime scripts to automatically incorporate that action when the window's X is clicked.

I don't really know Javascript at all but I think it should be something sorta like this:

var win = nw.Window.get();

"var gui = require('nw.gui');

nw.Window.get().on('close', function() {

gui.App.quit();

}

Closing the game seems to work properly (and not leave behind background processes) with having the Browser object execute the Javascript code "var gui = require('nw.gui'); gui.App.quit();". Can anyone else confirm that?

If so maybe there is a way to work that in so that NW.JS will automatically execute that code on the window close event.

I worked on the problem today and I got the feature working by simply changing the part of the code that disables it when not in preview mode (in preview.js). But I'm still left wondering if there's a good reason why it was disabled in the first place. Can't be that it doesn't work, glerikud, since it does now (for NW.JS at least).

Looks like someone here is having the same issue: https://github.com/nwjs/nw.js/issues/4493

Mind uploading the exported game (win32 please)? I want to take a look but I don't want to install the new NW.JS until these sorts of bugs are ironed out.

If you open the exported game's package.nw file (it can be read as a zip file) and then open the package.json manifest (can be read as a txt file) you can see what the starting width and height of the game are set at. You can also add a maximum width and maximum height to that file.

I'm wondering why the project setting "Pause on unfocus" is specified as only available during preview? I'd like to have that feature as part of my exported NW.JS app.

Maybe there's another way of achieving the same thing? Any way to do that by editing the code itself? I think I found the relevant part in the preview.js script but I have no idea how to get it into my exported game's data.

Has anyone tested this issue with the new NW.JS builds released today?

Why not just have the physics behavior disabled until the collision enables it?

Whatever you have set for the normal Construct 2 loader will always show up until the loader layout is itself loaded.

To turn off the loader layout just delete or move it in the layout list, then in the project settings change the 'Use loader layout' setting to 'No'.

Not sure why it would suddenly be like that, but check the project setting called "Clear background" and/or make sure the background layer is not transparent.

Right. So what are you saying? Hands up because "not can do"? Why all the other software have own exporters? Unity, Unreal Engine, Game Maker, Stencyl, GameSalad, Clickteam Fusion? Because they are so stupid that do extra work and build own exporters? Right. And I mean now iOS and Android exporters.

Someone correct me if I'm wrong but didn't Unity have the same sort of issue that Ashley has been describing, where browser makers suddenly dropped support for Unity's web player?

I see Ashley, I see… What about C2/C3 own exporters? I guess you understand that the problems associated often do just that? What's more third-party variables, the greater the problems. We could have only C2 problems and publishing platform (in this case iOS) problems. Now we have Ludei and Intel problems as well. Don't answer on this. I know your opinion about exporters. You just say that you don't have time for it.

I've seen him say about native exporters pretty much what he just said to you in this thread: They wouldn't necessarily fix the problems people assume they would because they would still be relying on external sources (for example, driver makers).