jzintv Keyboard Hackfile path not working? #204
Comments
|
In this case, but is Mac-specific. The paths to various files as stored in preferences are using NSUrl data. Before any path-related setting for jzintv is sent, however, the UI validates it. Problem was that the C# System.IO.Path APIs operate on path strings, not "Uri" strings -- the necessary conversion from file:// syntax to file system path syntax was missing. |
|
Furthermore, found that some other paths aside from hackfile were affected, though they are not presently exposed in the UI. Up to two CGC adapters are supported. The CGC configuration isn't exposed since it's untested, and may be unsupported in Windows versions newer than Windows xp anyway due to driver issues. |
intvsteve
added a commit
that referenced
this issue
Aug 19, 2018
Issue #203 is ECS.bin is not always passed to jzintv. LUI was only doing this when -s1 was needed based on ROM features and user settings. Change is to always send the -E /ecs/path/ECS.bin to jzintv since jzintv will only really care to load it if -s1 is also sent. Custom command line setting in the case where this bug was found was including -s1 for all ROMs - which exposed the interaction between the two args. For Issue #204, code had overlooked that settings data stores path strings as NSUrl data on Mac, so a 'resolve' is needed for the C# System.IO.Path validation code to work properly. Due to that oversight, hackfiles could *never* work on Mac because the validation code would never find files with paths that had URI syntax (file:///path/to/hackfile.txt).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Operating system version
macOS 10.10.5
Program version (from About box)
1.0.0.2910
Expected behavior
Keyboard hack file is used
Actual behavior
It is not
Steps to reproduce
Try a custom keyboard hackfile.
Workaround
Add --kbdhackfile argument manually.
The text was updated successfully, but these errors were encountered: