The Big NW.js Roundup - News & Tips

TheRealDannyyy I noticed that when I use v0.29.0 and C2 R256 adding this arg

--disable-software-rasterizer

Causes rendering problems and the steam overlay is not loading, I actually don't remember why I added this arg, it was from something I probably read here before, but I can't locate any reference to it in your original post.

Do I need this for something?

This arg was there from the beginning and the removal of it is basically what the recent beta update did (maybe also some other minor runtime changes). As Ashley stated in the github Issue, this arg was mainly in place in order to ensure that we don't get software rendering. Important to note is that NW.js added Swiftshader support in v0.25.3 for Linux and Windows (no OSX support?), which lets you use WebGL even on hardware with incapable GPUs and I assume does the same job as the arg.

In short, the mentioned arg didn't disable software rendering because of a bug and also disabled Swiftshader support, causing all sorts of problems in our games. From what I can tell this has been fixed in v0.29.1 and this might just be a temporally change but I personally don't see a reason to use this arg in the future because of Swiftshader support.

This is all fairly complicated for me as well, maybe asking Ashley himself about all of this would be better if you experience any major issues.

Ashley What do you say about this, do we need --disable-software-rasterizer for anything?

I don't mind waiting for the next nwJS release.

I think --ignore-gpu-blacklist would prevent the software renderer ever being used anyway. I guess if you literally don't have a GPU (or it's a headless system or some such) then it actually should fall back to the software renderer, so I guess it's better to remove --disable-software-rasterizer anyway. I think those systems are pretty rare, and surely nonexistent amongst gamers, so it's pretty academic. So it should be fine to just delete that flag, which is what the latest betas do.

Ashley Great, thanks for the quick response!

I think --ignore-gpu-blacklist would prevent the software renderer ever being used anyway. I guess if you literally don't have a GPU (or it's a headless system or some such) then it actually should fall back to the software renderer, so I guess it's better to remove --disable-software-rasterizer anyway. I think those systems are pretty rare, and surely nonexistent amongst gamers, so it's pretty academic. So it should be fine to just delete that flag, which is what the latest betas do.

Thanks for the info!

(Quick update: I've changed the "default" package.json files available in this topic with the most recent files that come with r256.)

Hi TheRealDannyyy,

I'm trying to release my first Construct 3 project, but I'm experiencing some trouble with the mac version.

To sum it up : the "Run" command does not work on the Mac projector. My pdf embedded file does not open on mac, but it does on windows.

I'm not sure if the reason for it is a non existent path in my command line (ie. Run "document.pdf" and not Run "/relativepath/document.pdf")

Or is it because I do not have made the gatekeeper certificate of my app yet.

Could you please help me ? Is it possible to reach you in private ?

Thanks in advance.

Mathieu

Hi TheRealDannyyy,

I'm trying to release my first Construct 3 project, but I'm experiencing some trouble with the mac version.

To sum it up : the "Run" command does not work on the Mac projector. My pdf embedded file does not open on mac, but it does on windows.

I'm not sure if the reason for it is a non existent path in my command line (ie. Run "document.pdf" and not Run "/relativepath/document.pdf")

Or is it because I do not have made the gatekeeper certificate of my app yet.

Could you please help me ? Is it possible to reach you in private ?

Thanks in advance.

Mathieu

If it works on Windows there is probably something going wrong in the Mac version of NWjs. There have been reports similar to this one in the past about wrongly recognized file paths by NW.js on OSX and Linux. Please provide the stuff below and I'll try my best to help you out:

1. The NW.js Version You're Using

> Can be found in the exporting dialog

2. Packaged assets, yes/no?

> First checkbox in the options tab inside the exporting dialog

3. Minimal "dummy" project reproducing the issue

> Please use an empty PDF file and remove any private information

You can PM me if you want to but I'd prefer to keep things like this open so that others that run into the same issue know how to fix it.

Cheers!

1. The NW.js Version You're Using

It's the latest Chromium version 65 (v0.29.0)

2. Packaged assets, yes/no?

No, not for the tests, but in the end I would like them to remain hidden. The best would be to make some available for user to see, and some completely invisible.

3. Minimal "dummy" project reproducing the issue

I'm actually testing a solution I found in the forum (viewtopic.php?f=151&t=200764&p=1170491#p1170491)

But please find below a link to my c3p :

dropbox.com/s/m50yil3qihx1emq/dummynw.c3p

Thank you very much for your help.

This thread is a life saver! I'm publishing my game to steam in 2.5 weeks and there are some things stated here I had no idea about! Like I had no clue you could access the chromium dev tools within my game.

Thank you so much!

Hello, as I could read somewhere, the user can access the global variables and can alter them.

This is disastrous in my game (and in any game I think).

To solve this, is it enough to hide the developer mode of NWjs ?.

My game will be published using NWjs.

Hi TheRealDannyyy,

I'm trying to release my first Construct 3 project, but I'm experiencing some trouble with the mac version.

To sum it up : the "Run" command does not work on the Mac projector. My pdf embedded file does not open on mac, but it does on windows.

...

Short reminder for everyone else, this issue has been reviewed by Ashley and the NW.js plugin received an update in order to fix/support cases like this.

Get the new NW.js plugin by using Construct 2 R257 or Construct 3 R96 and all new releases after those.

This thread is a life saver! I'm publishing my game to steam in 2.5 weeks and there are some things stated here I had no idea about! Like I had no clue you could access the chromium dev tools within my game.

Thank you so much!

Thanks for your feedback!

Hello, as I could read somewhere, the user can access the global variables and can alter them.

This is disastrous in my game (and in any game I think).

To solve this, is it enough to hide the developer mode of NWjs ?.

My game will be published using NWjs.

If a hacker would gain access to Dev-tools, he could do way more than just edit global variables. While the Chromium-arg prevents direct access like pressing F12, Dev-tools are still available in the NW.js "SDK" build that Ashley ships. If you want to remove Dev-tools entirely, you could manually download and install "Normal" builds from NW.js IO.

Generally speaking, since our assets (including runtime code) are always open for grabs using NW.js anyway, there is no point in investing a lot of time into security.

You could try to use 3rd party global variable plugins or encryption/minification but if someone really wants to hack your game, that person will be able to hack it regardless of what types of security you're using (e.g. through hardware exploits).

Hi there, while this isn't a major update to the topic, I would like to make use of the reach that this topic has in order to inform everyone about a recent change introduced in Chrome M66: Chrome's new autoplay policy. Just as a heads up, the new policy doesn't seem to affect NW.js projects (tested using v0.30.0+).

Like the use of outdated memes on the developer update website, this feature is a huge step backwards for the web in my opinion and already affects several projects from websites to games, please read this blogpost for more details. In order to hopefully get this sorted out as soon as possible, I would like to ask everyone to show support for the following issue regarding this created by Ashley himself. Below you will find the link, steps to support the issue and also the changelog for this minor topic update.

Link: Allow audio to autoplay, but optionally mute output Chromium Issue

How to support:

• Sign in with your E-Mail

  (usually on the top-right)

• Go to the mentioned issue
• Click on the "Star" icon

  (usually on the top-left)

• That's it, thanks for your support!

Topic changlog:

• <Updated> How To: Test Your Game On Higher Framerates Than 60FPS
• <Other> Further compressed some images to reduce loading times
• <Other> Prepared How-to... --autoplay-policy=no-user-gesture-required for future changes

Cheers!

> Hello, as I could read somewhere, the user can access the global variables and can alter them.

> This is disastrous in my game (and in any game I think).

> To solve this, is it enough to hide the developer mode of NWjs ?.

> My game will be published using NWjs.

>

If a hacker would gain access to Dev-tools, he could do way more than just edit global variables. While the Chromium-arg prevents direct access like pressing F12, Dev-tools are still available in the NW.js "SDK" build that Ashley ships. If you want to remove Dev-tools entirely, you could manually download and install "Normal" builds from NW.js IO.

Generally speaking, since our assets (including runtime code) are always open for grabs using NW.js anyway, there is no point in investing a lot of time into security.

You could try to use 3rd party global variable plugins or encryption/minification but if someone really wants to hack your game, that person will be able to hack it regardless of what types of security you're using (e.g. through hardware exploits).

Thanks for the info

I hate this new website. Now, the thread is unreadable.

I hate this new website. Now, the thread is unreadable.

It is true, I already communicated this in the thread "Welcome to the new forum" and Tom said that the threads would be fixed, so it is expected that this thread is solved and visualized well.

If this does not happen, the only thing we can do is confirm our dissatisfaction about it.