'Illegal characters in path.' warning on unpack task with partial unpacking result.

[Andrei-Stakov]

Hi, IDK if you're still actively maintaining this project, but currently I'm stuck on this issue.

Currently messing around on one of PeasSoft games with a bit of botched TL, and trying to fix it on my own. Tried to unpack one of the problematic .ykc, but as you can guess from the title, it just partially unpacked.

I presumed that all files with Japanese characters are triggering this (on -verbose, the last file that is problematic to unpack was riddled with ?????), but changing my system locale to Japanese doesn't seem to fix this.

What should I do to unpack (and pack it all again) correctly on English ver. of Windows? Or should I cross the bridge anyway and try using Japanese Windows through VM?

Thanks in advance.

Edit: Removed some brain farts, need more coffee.

[AtomCrafty]

Hey,

it's been a while since I worked on yukatool, but a quick glance at my archive IO code seems to imply that I assumed all files names would be ASCII compatible. They are probably actually Shift-JIS encoded, which is why they appear as a bunch of question marks when interpreted as ASCII.

I've created a small fix that should properly handle the embedded file names, you can try it here: https://github.com/AtomCrafty/yukatool/releases/tag/2.4.0

Please let me know if that fixes the issue :)

[Andrei-Stakov]

Wow, thanks for the swift response!

The fix works great! ...Although now I'm testing on how it packs it all again, since somehow this game uses raw .png instead of encoded .ykg (checked through YukaTool GUI), and the pack task seemingly ignore the --raw flag and just straight wrapped all bitmaps to .ykg while packing it all — which the game would respond with missing file popups when the repacked .ykc is used.

Sample case, with no modified files; straight unpack and repack with --raw flag

Is there any option to properly skip the .png wrapping on pack task?

[AtomCrafty]

That use case is the reason I implemented the manifest system in yukatool2.
It stores the original format of each extracted file in a .manifest file and uses that while re-packing to determine the target format.

Yukatool2 should be able to do pretty much everything yukatool can do, but I never got around to finish the other commands. So instead of yuka decompile myscript.yks you'd need to call the copy command and manually specify the conversion direction like this: yuka copy --format=unpack myscript.yks.

[Andrei-Stakov]

I've downloaded it before while tinkering long before, but forgot to test with this case, whoops.

After testing though, it seems like unpack/decompile was working spotlessly (all Japanese-character filename is safely extracted), but I hit another roadblock while using pack. Note that the pack itself is a success with no warning present.

The repacked .ykc is seemingly fine, size-wise (within a bit of margin of error). But the game having the same missing file popup like before; now it popups when the missing files have Japanese character in its filename.

After checking it with YukaTool GUI, I found another weird thing; few file and folders were completely missing.

Browsing around the archive, I found that every single files with Japanese-character in its filename, with any folder that only contain said files (no plain ASCII-filenamed files present) were missing.

That said, it might be safe to say that this issue is fine to be closed. I'll create another issue in the yukatool2 repo, while linking this issue there because it might be related with the same underlying problem.