Hello,
i've ran a test with the new version (unvivtool10+dev201206-win32.zip) on Win10 64bit.
I noticed you restricted the output to a subdirectory of the input path, so output command can only be a folder name
(message "
must only contain the following characters 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz").
The application path now working fine with single quotes (') or double quotes (") and spaces.
C:\un viv>unvivtool d -o "C:\un viv\car.viv" "car extracted"
=================================================================================
unvivtool 1.0+dev201206 - Copyright (C) 2020 Benjamin Futasz (GPLv3) - 2020-12-06
Archive: C:\un viv\car.viv
Extracting to: car extracted
Archive Size (parsed) = 10530811
Directory Entries (header) = 24
Decoder successful.
Extraction works fast and flawless so far, tested different archives from NFS2 (cardata.viv), NFS3, NFS4 and NFS6.
Just have to point out the issue with special characters and vowel mutation again, used in many regions, thus appearing in filepaths probably.
C:\ün viv>unvivtool d -o "C:\├╝n viv\car.viv" "car extracted" #filepath with "ü" instead of "u" results in error
=================================================================================
unvivtool 1.0+dev201206 - Copyright (C) 2020 Benjamin Futasz (GPLv3) - 2020-12-06
Archive: C:\++n viv\car.viv
Extracting to: car extracted
File 'C:\++n viv\car.viv' not found
Decoder failed.
Maybe you can define/implement a different character set (Unicode, ANSI etc.) with the application (not to mention russian, arabic or chinese)?
Dunno how much of a hassle it is, to make the program "multilanguage"?
Furthermore, the encoding side still seems a little cumbersome, again requiring to place unvivtool.exe inside execution-path... if i understand correctly.
Wouldn't it be more convenient to give a folder or path, packing all files inside into the viv-file?
Greetings