Deployed game doesn't run for users with Unicode paths (non-English folders)

[Oatilis]

This came up during beta testing. A player was testing the game, which didn't load. A blank (white) window started up, but nothing loaded whatsoever, no main menu, nothing. Turns up the game simply didn't run because the folder path had Unicode folder names in it (in Hebrew). When the player moved the game to an English-only path, it worked as intended. I was surprised to discover this. I assumed MV could handle Japanese paths so other languages wouldn't be an issue.

Bottom line is, I'm not sure how to solve this (except telling users to avoid non-English paths).
Any help will be appreciated.

Just to clarify: The game doesn't use non-English folders. It was inside non-English folders and therefore didn't work.

 

[bgillisp]

That's because it must use networking standards for all their file names. This is alphabet letters and no strange symbols, and is for the cross platform compatibility. You'll need to tell your users to follow all required networking standards in how they name their directories.

 

[Oatilis]

That's because it must use networking standards for all their file names. This is alphabet letters and no strange symbols, and is for the cross platform compatibility.

Actually there's a standard for encoding unicode in URLs. It's very common. here's an example:

www.test.com/%D7%91%D7%93%D7%99%D7%A7%D7%94

Paste it in your browser and it should automatically change the encoding to the original unicode.

Not sure how the URL encoding happens in MV, but pure networking standards don't make sense either, since spaces don't seem to affect the game, and you can't have spaces in real URLs. If you place your game in a folder like "My Documents", it would still work despite having a space in the folder name.

Seeing as MV actually runs off a Chromium browser, which is supposed to handle this, I would assume there's a way to get it to work.

You'll need to tell your users to follow all required networking standards in how they name their directories.

It's what I've done so far, but this is not really a solution though. It's a workaround. Maybe I need to write a wrapper that will translate local addresses with unicode to relative MV addresses the game can work with.

 

[ozubon]

Do you use an older version of MV? Because I think the latest version(s?) runs locally starting from the game folder path and doesn't use the entire path to the folder anymore. Maybe I'm wrong but window.location.pathname in the newest version is simply /index.html but in an older version of MV it's the entire disk path.

 

[Oatilis]

Do you use an older version of MV? Because I think the latest version(s?) runs locally starting from the game folder path and doesn't use the entire path to the folder anymore. Maybe I'm wrong but window.location.pathname in the newest version is simply /index.html but in an older version of MV it's the entire disk path.

Yeah, version 1.5.2. Haven't seen the full path anywhere myself. All the game files seem to use a relative path, which makes sense because deploying dumps the game the same way no matter which location you use.

 

[ozubon]

That could be it then. They might have changed that precisely for this problem. See this thread on how to update your project if you don't already know how to:

Announcement - RPG Maker MV - v1.6.1 Stable Release!

6/21/2018 Everyone, please read the instructions carefully. The bugs that are being reported shouldn't happen if the correct files were even copied properly. Such examples like the "CTRL BUG" shouldn't happen if you copied index.html, package.json, the rpg*.js files and so on. I also received...

forums.rpgmakerweb.com

It's not about the deployment but where the game exists in the network when it's being run.

 

[bgillisp]

A lot of what you mention is Windows automatically doing that. It's not supposed to. The %20 and stuff like that is a symbol it can't find. Other OSs do not do stuff like that, so that is why it follows this standard. If you put your game on Mac or Linux it will just not run if you use those kind of symbols, so for RPGMaker MV to deploy to those it has to follow the strictest of all the standards used.

 

[ozubon]

@bgillisp Am I right in that the newest version uses an independent path that starts with the game folder? Because of the differences in location.pathname I mean. Nontheless you gotta follow strict standards for the game files themselves but shouldn't the path before the game folder not be an issue anymore?

 

[Zeriab]

A lot of what you mention is Windows automatically doing that. It's not supposed to. The %20 and stuff like that is a symbol it can't find. Other OSs do not do stuff like that, so that is why it follows this standard. If you put your game on Mac or Linux it will just not run if you use those kind of symbols, so for RPGMaker MV to deploy to those it has to follow the strictest of all the standards used.

Not true. The mechanism was introduced for a different purpose

A percent-encoding mechanism is used to represent a data octet in a component when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component.

If you want more information regarding the subject the relevant RFCs are

• RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax
• RFC 8089 - The "file" URI Scheme
• RFC 3987 - Internationalized Resource Identifiers (IRIs)

@ozubon While there was fixed a bug in Chrome regarding IRIs in 2017 the issue was probably just a matter of using a wrong API call for fetching the path.
Internalization is hard, tedious and bothersome though. If you don't use an established library you are doing it wrongly, and even when you do it is still easy to do something wrong.

*hugs*

 

[ozubon]

Thank you Abe, but I'm not talking about IRIs but location.pathname which is a different story.

It used to be:

window.location.pathname
// Output => /C:/Users/oz/Documents/Project1/index.html

But in the latest version(s?) of MV it is:

window.location.pathname
// Output => /index.html

The path used to be an absolute path but is now seemingly irrelative to any parent directory.