itch.io

I see.

If you are going to stick with version 0.72.0 of nwjs, you can either:

• Set v0.72.0 as the default for new projects via Projects -> Default Project Settings -> Edit. Note that this only applies on new projects. 
• Or (if it's just this one): Projects -> Project Settings

On the Essentials tab, you'll find the setting that selects the version of nwjs. Simply select 0.72.0 from the drop down.

Hmm... This is certainly weird. I do wonder if it's a specific issue with the version that the tool uses by default. To test this out:

Download v0.53.1 of nwjs (the sdk version) from here:  https://dl.nwjs.io/v0.53.1/
Then open a command line, cd to the nwjs folder (after unpacking) and run nw.exe --nwapp="<path to the game>" (Replace the <> with the actual path). If it also happens with that, then it's very likely that there's a compatibility issue with nwjs.

Hello, QZ Productions!

As a sanity check:

1. In what format is the font?

2. Double check that the font is properly shown in newer versions of Chrome first. There is a possibility that the font file is borked.

Hello, nowyouknowadorian!

FIrst off, what version of the engine? MV or MZ? Second, could you show me the settings that were used?

In what version are you on, currently? And does it happen again if you re-build?

Hello, HeiSei!

What settings did you use?

Heya! Sorry to hear about the crashes.
D0.08 Update 2 re-works how Starboard checks the cache (the crashes were just Starboard closing the game to initiate a re-build on the next start up).
I am going through the video to gather your feedback. Thanks for playing the tech demo.

Hello, ottieL!

While it would be ideal to have the option to Encrypt Assets/Source Code Protection on, having only Package Game Files is enough.

Hmm... This can happen due to either:

- The version of nwjs  you've selected is a bit broken and just crashes when it tries to load the binary versions of the js files. This is more prominent in older versions  (before version 0.43.3, I  believe)of it. A workaround for this (if you can't use newer versions of nwjs) would be to use the Metadata Editor (found under Utilities) and add --no-flush-bytecode in the JavaScript Flags. 

- The more likely scenario would be that a file wasn't included in the packages (when it should have been) and the bootstrap would assume that the cache is broken (and thus, close the game). I'd need to take a look at a build of the game to examine it, so please send me a test build so I can diagnose it.

Is it showing a different plugin now? Plugins that rely on finding their name via document.currentScript do break, as the option uses nwjs' own script loader.

Hello, heiSei!

It's a conflict with the "Protect Source Code" option. You can fix this by changing line 298:

const DotMoveSystemPluginName = document.currentScript ? decodeURIComponent(document.currentScript.src.match(/^.*\/(.+)\.js$/)[1]) : "DotMoveSystem";

to this:

const DotMoveSystemPluginName = "DotMoveSystem"; 

Yes. Simply hardcoding the name of the plugin should fix that. 

Hello, Undermax!

As a sanity check, is the plugin in question using a way to dynamically find its name? Since Asset Protection also enables Source Code Protection, this way breaks (since the tool uses an alternate way to load the plugin).

Yes

Primarily, errors from the dev console (accessible by pressing F12 after creating and running the test build).

It's possible. It would usually be that a file is missing (if it was now stored on the root folder of the project and wasn't added to the custom files and folders list).

There is a bug that prevents the dev tools (F12) from opening. I'm working on a hotfix and upload it as soon as possible.

Hello, Mellorb!

Can you create a test build and open the dev tools? Once it's built, press F12 to access them and then click "Console".

After a bit of digging, it turns out that one of the features I  rely on isn't present on Windows 10. I'm working on a compatibility fix right now and I'll upload it soon.

A bit of a follow up: I rolled up a potential fix for the bootstrap in the latest update. Hopefully this will fix the "Operation not supported" error.

It's rather weird that this error happens when "Package game files" is turned on. I want      to take a closer look at whatever logs are available (accessible via Utilities -> Export logs). Maybe I  can find the error.

As for the second error. I'm not sure why this happens, but   I have a suspicion as to what's causing it. I'll look into it and send you a test build.

Hello, inushisyo!

Can you check the Event Viewer for any errors on Windows 10? You can see them by opening Event Viewer and then going to Windows Logs -> Application.

OK. I done a bit more digging. Turns out that my method of patching the html file (required so it can load the binary versions of the JS files) was error prone. I found a better alternative and I'm working to release a hotfix for it.

EDIT: The hotfix is out.

A bit of an update: as of right now, I wasn't able to replicate the issue. Could you please provide me a screenshot of the settings? Specifically, on the File Preparation tab.

Looking at the code, it appears that the script tag wasn't updated to load the correct file, resulting into a black screen. I'm looking into why this didn't get updated. 

Hello, YoBro!

Can you check the index.html file using the dev tools (after buiding the test build)? You can see the code for the html file by clicking on the "Sources" tab and select it on the list.

To keep it simple: The paths are handled like a page URL in websites. Hence why it adds that %20.

After a bit of digging, I found the cause for saving the default settings. Due to a typo, it tried to write on a file that was actually the folder. Hence, that error. I'm working on a hotfix for it and publish it as soon as possible.

Hello, Anwynn!

Thanks for playing my game. The saves are stored in your PC's User folder\Saved Games\Dragonhouse\Immortal Sins. You can also use the launcher's Save Manager to export them, if needed.

Hello, YoBro!

• About the first issue: could you explain with what is going on the project? I see that it's loading plugins (I presume) from that folder, but I want to have a clearer picture as to what it does.
• For the error in index.html: I'm not exactly sure why is this happening. Most likely, a formatting error is inserting this, but since it doesn't break the plugin loading, it's mostly a fluke.
• For that last one: Does this happen when you launch the tool for the first time?

A bit of an update: R6.02u6 has some re-work for hotpatching, which may address the issue that you are encountering.

No problem. 

Hello, Zealli!

If the plugin stores data in a folder, you can add it to the packages via Project Settings -> Packaging and Player Services -> Custom files and folders. Click either Add (and type the name) or Import and it will allow you to add it in.

Fixed the typo.

Hello, ianov! 

Could you show me the settings that you used? Or provide the logs for the tool (accessible via an option in the Utilities menu). 

Digging a bit on the plugins that I could get my hands on, DotMovementSystem is one of (or the only) culprit, as it tries to pull its name dynamically (Source Code Protection has to patch MZ so it can load the bainry files that nwjs can read). It's fixable by changing the line 298:

const DotMoveSystemPluginName = document.currentScript ? decodeURIComponent(document.currentScript.src.match(/^.*\/(.+)\.js$/)[1]) : "DotMoveSystem";

To this:

const DotMoveSystemPluginName = "DotMoveSystem";

Might send a message to the dev of DotMovementSystem to let them know about it.

If you see similar issues with what you saw in that plugin, check if there any plugins that use document.currentScript (or similar) and simply change the line to hardcode the name.

As for Uncaught SyntaxError: Unexpected token '<': I can't say for certain what causes that on MZ. It doesn't crash MZ games (I tested with both barebones and more plugin heavy projects) and there's no crash or stuck in a loop. Most likely, there's a slight error in patching the html file so it can load the binary version of main.js. Other than that, it's a fluke of an error.

EDIT: If you mean the Source Code Protection on your edit: Yes. It's still an option. Since R6, it's enabled by default when the option to encrypt the assets is turned on. So, you'd need to disable that option first.

Yeah. The isHandheld is decalred by CookToolAddOn, thus causing the error. I've updated that plugin again to fix the error.

Not sure if it is the same issue as Daisuke's but it's quite weird that a JS file is missing. 

If you can, please provide the logs for the app. You can get them via Utilities -> Extract logs.

Hello, Crimzon_Zero!

• For the AdvSaveHandler, there was a bug where it tried to find the main executable's location but throw that error instead. I'm uploading a patch as we speak.
• For FSDK_CookToolAddOn, could you please provide me with the output of the dev console, so I can see where is it triggered?
• As for the fullscreen plugin, do you use something like Visustella Options Core? If you do, there might be a conflict.

In regards to plugins not working after building: the most likely culprit is that some plugins are trying to find their config by checking their name (rather than using a hardcoded one). If they use something like document.src, then they try to get their name dynamically.