path::string() uses the ANSI code page and throws on a character it lacks (a Cyrillic folder on
an English Windows). The remaining places it was used now go through path_utf8:
- Mods: a deck folder or a mod folder named outside the code page no longer leaves the Board Break
decks empty, or the Mods folder ignored altogether.
- Game and mod archives: a file under Win32 with such a name is passed over instead of stopping
the read.
- pose-dump no longer ends the multiplayer session when the game folder is not ASCII.
- The item browser's status line and a Board Break warning no longer fail on such a path.
- Launcher: system fonts are named to ImGui in UTF-8, which it reads.
The launch merge truncated cas_65537 to archive 1 while a live apply rejected it, and any misnamed archive stopped the whole merge instead of just that mod.
- Conflict in launcher_support.h: kept Linux guards, took upstream's
validated_remote_load_library(note) signature + comment.
- Upstream's path_utf8() helper is portable; merged cleanly into the
Linux closure. Build + 8/8 portable ctest green.
A player whose game sat under a folder named U+200E (left-to-right mark,
an invisible directory on their Desktop) could not launch: the status
tile read "No mapping for the Unicode character exists in the target
multi-byte code page". Nothing was wrong with their mods, and the merge
in their log had just succeeded.
fs::path::string() converts to the process's ANSI code page and throws
exactly that when a character has no mapping there. initfs.cpp called it
on the normal path, not in an error handler, so exporting loose files
threw on every launch. Their log stops right where that export begins.
Cyrillic, CJK or accented characters in an install path do the same on a
code page that cannot hold them.
- path_utf8() in Engine/Core/Platform/path_text.h: UTF-8 represents every
path Windows allows, so it never throws.
- Every path that becomes a narrow string uses it -- 35 of them across 13
files. Most are log lines and error messages, which were a second trap:
reporting a problem with a path threw this instead of the problem.
- The ~45 .string() calls on Json values are untouched; those are not
paths.
Nothing changes for an ASCII path, where both encodings agree, and a path
that is not ASCII had no working behaviour to preserve.
Reported with a log by a player on Discord. Moving the game to an ordinary
folder works around it on an unpatched build.
AyeZeeBB