RMMV tips: Upgrade NWJS and Chromium 67,68 64bits

On mac it's a bit harder, because in it, the files and folders are within the game.app folder(if i'm not mistaken thats the name when you export your game for MacOS). You would need to export for web browsers, download NW.js last version for macOS, find a way to open the nw.app as folder within macOS, then follow those steps to distribute your game:

http://docs.nwjs.io/en/latest/For Users/Package and Distribute/#mac-os-x

@topic:
For those interested, last version of NW.js brings V8 7.2(MV 1.6.2[Last Version] uses 6.5, also using chromium ver 72[MV uses 65]) . The difference in performance should be quite visible for those who upgrade from MV's version to the last one. Mainly for async stuff.

@elpeleq42 thanks for mac user explantation, i will add to tread.

I'd like to point out this will work for the playtest, but I deployed my game to test it and... the deployed project was the old nwjs.
To make it work on a deployed project too, at least for windows, you'll have to do the same thing with the normal nwjs (not the sdk one) on the nwjs-win folder (not the nwjs-win-test).
Oly have windows for now so not able to test in linux or mac...

In terms of development for macOS the consensus inherent to the absence of OpenGL on recent versions is a serious impact, however for those who can still get their projects to work I have identified that similar provisions work on Mac as they do for Windows in relation to the process of play testing. I also realize that it has been awhile since anyone posted to this discussion, however I have just now confirmed this.

From Steam, control-click the entry for MV, select properties and go to local files. Click the browse local files option to bring up the MV install, then control-click the MV app and select the "show package contents" option. This approach is required because macOS treats the user's Steam library as system protected and as a result of this you cannot access MV files directly from the Finder (or any Steam apps for that matter). Furthemore, there is no obvious equivalency to the "hide protected files" and "show hidden items" options as there is relative to the Windows file explorer so this is basically the only way to get in.

Within the MV app package go to Contents/MacOS/nwjs-osx-test and duplicate game.app for backup purposes. Download the latest nwjs SDK and rename it's package to Game.app (and optionally copy/paste the app.icns from the package shipped with MV) and then copy everything over from the SDK download and into the test provisions.

From here it gets a bit more complicated than on Windows. Start a play test, you will be returned to MV with a trust error. This is to be expected because of Apple Gatekeeper. Accommodate this by going into System Preferences and selecting the Security and Privacy option. You will see the patched launcher as "trust blocked", click on the unblock option to override this. Return to MV and start another test session, and this time you will see the standard download report. Confirm that the package is from the nwjs website, and if everything checks out click Open.

Please note that I am not yet aware of any method to do this for deployment purposes as on Windows, but for those who are not impacted by the x64 or OpenGL situations this will allow for testing MV games with updated nwjs bits on the Mac platform.

EDIT: Unfortunately I have determined that the nwjs-osx-unsigned.zip used by MV is hard-coded, and so it is not possible to do the same thing for deployment purposes. As a workaround you will have to deploy for online play and follow alternative procedures that I will provide later today.

EDIT 2: Apparently in my rush to get this out I miscommunicated the command name for the package browser, which has now been fixed. Additionally, the procedures for creating the x64 package for a macOS distribution is fairly easy. As promised, here's the procedure.

If you haven't already done so, download the nwjs x64 redistributable for macOS. Unzip its contents wherever you'd like and control-click the resulting nwjs.app, then click the "show package contents" option as usual. Go to Go to Contents/Resources and create an app.nw folder to house the game files.

In the MV Editor, do a website export, then open another Finder window and browse for the export location (outpath/gamename/www and replace the provided example with the actual path). Select all the items in the provision and issue the copy command, then return to the nwjs package view and paste the files into the newly-created app.nw folder.

Finally, launch the game, confirm integrity and open. (No requirement exists to bypass Gatekeeper twice in the process of testing and deployment from what I have observed.)

Hi there!
I already use an RM MV updated. In my windows 10, I used the latest stable version(v42).
But in Win 7 Pro, when I use this version, when I hit playtest, it took a while to open. That's not happening with the default nwjs that comes with rm mv.

So I wonder, there is a way(instead of testing one by one) to find the "best" option of nwjs for Mv?

There is no such thing as the "best" version of nwjs for MV. Higher versions offer more features and are better optimized. So technically speaking, you can never go wrong with the latest version of nwjs. But MV has their custom version of nwjs and the standard ones will cause problems with the MV editor, so I would not use the custom nwjs during playtests and stuff, only when the game is ready to be released.

Win 7 :blush:? hum it a 11 year old OS technologie!
You are using an OS with obsolete architecture, and probably your hardware and drivers are also very old.

You can maybe try play with your package.json and try to found a parameter that can help you, but i think your just dev on a bad computer.

you have a good list of chromium command here your can hack your nwjs sdk.


gl !

Thank you guys!!

Personally I haven't really had any problems in that regard, but that may just be fate. Then again, my project basically requires me to do this... and I have seen no real problems whatsoever (checking variable status, console etc. all work as usual). Butt if it's that big an issue and you have the standalone version you can always register your purchase with Steam (which is technically a provisional holdover from when targeting macOS was actually viable for us) and then you can have two installs, one with the shipped version and the other with your target release.

Thanks, @BreakerZero ! When I have Win 10, this is not an issue. But it happens with Windows 7 =/
I think @Jonforum has a point here when he talks about Win 7 as an old OS. It happens that my hardware is not that old, but it's not suited for Win 10(Although I used that for a long time) Now that I've changed to Win 7 again, my pc is flying, is at a great performance. But had this little issue with Rm Mv Playtest. So in that case, I will follow the @Poryg orientation and only use the upgraded Nwjs when I deploy the game.
Thanks for the advance!

@Eliaquim I... don't think that is the best idea...
For one, because as I mentioned before in this thread you need to change another folder for it to change in deployment too...
But my main problem is that... if it gives you problem with W7, it will probably give it to other W7 users too. True, it is old, but as you are proof it is not unused.
So... you'd basically be limiting your users. And in a way you yourself would not be able to be one of them.
(That is the reason I was going to use the 32 bits version instead of the 64 as suggested, 64 computers can run 32 but 32 ones can't run 64 programs. Mine is 64, but until recently my brother's wasn't, for example. This news about W7...)

these probably link only to the sdk version.
In deployment ,it the normal version of nwjs without the sdk kit for debugging.

But these not only nwjs! also Electron, Appcelerator , Vuido, Nintendo Web Framework ....
All of sdk version need good and modern computer.
The debugging technology evolved quickly and your dev computer must also follow.

The problem is that it doesn't mater if the dev's computer follows if the player's doesn't.
I don't remember if it was crysis? A game was released some years ago, great graphics but barely any computer could run prooerly.

I'm not sure what you're all talking about. I have no problem running the latest NWJS on win7. So I wouldn't be so quick on blaming the OS.

@Waterguy Well, at least for playtest, I will not upgrade the Nwjs, because it is slow to open playtest, but only for open. Once it opened, the game runs fine.
For the deployed game, I will make a test to see if it is "slow open" like playtest or not.

well, I did not test myself in a win7 computer, I know mv's default one works fine but eliaquim said the updated version didn't work properly on his.
but the thing I said about 32 bit computers not being able to run 64 bit programs is still true as far as I know though. So as I said I used the 32 bit version.

Hi there! ^^
I recently updated the nwjs again, to the last one(45-SDK).
But I'm getting two errors in the console. The game keeps running, but I don't know if it will cause some crash or bug with the time.

This:
Happens as soon as I load the game(playtest). And the file is there.

And this one:
Happen every time I use the scroll button of the mouse.
For that one, I've found this. With lead me to this. But I have no clue how to install, or where I have to put the files in the Mv folder.

Any hints on how to solve it?

A sourceMap is userfull only if you use IDE, like vscode to trace breakPoint in a compiled code.

Example if you use Babel to transpile, the source code read by nwjs is diferente from source code in your IDE, so you need a sourceMap to track where the compiled code are inside Vscode.
For debuging only.
You should able to disable sourceMap inside the SDK, if you not need this.
Learn web development | web.dev

For the other error, it in most case, it related to HTML events
You preform a `.preventDefault()` somewhere thats not required, so it do nothing and show your error.
Juste remove it.

Got it!
So I don't have to worry about the source map since I do not use vs code to track breakpoints.

But about the `.preventDefault()` . Do I have to search the scroll function in Mv code to fix this? Or do I have to look at the nwjs code?

I dont know , look the error details.
You should see where this executed.
If no!, (anonyme functions) , no luck for you, you will need search all references in your project with `preventDefault` and try find the culprit.