Fix for basic mod data checker

[jkbcdev]

trafficstars

Fixes "unsupported archive for quick installer" error when trying to quick install an archive that has a single folder that gets moved by the data fixer. This is the same error and fix from this pull request, but for the basic mod data checker.

[ZashIn]

The question is whether this should be

1. "fixed" / worked around only in BasicModDataChecker ⇒ favor this PR over #157 and remove the "fix" from all derived classes, like CyberpunkModDataChecker
2. changed in the InstallerQuick (Simple Installer) itself here, since by definition .dataLooksValid() should only return FIXABLE if .fix() already implements a fix for that filetree, so traversing / unfolding the tree is redundant / unnecessary at that point.

Furthermore the current InstallerQuick approach checks the file tree multiple times if no VALID file tree is found, executing dataLooksValid() each time on:

• root folder for VALID
• then every solo sub folder for VALID
• then once more the root for FIXABLE

That means this workaround redirects each of the above checks to .dataLooksValid(root).

So in my opinion, InstallerQuick should stop traversing the file tree as soon as VALID or FIXABLE is found and always rely on the required .fix() in the latter case. This also reduces the .dataLooksValid() calls by 1 to n(subfolders).

[Holt59]

I think this is fixed by https://github.com/ModOrganizer2/modorganizer-installer_quick/pull/23 for now. In the long run, the checker interface will probably needs to be updated to handle this more cleanly and avoid that much call to dataLooksValid.

[Silarn]

Probably worth opening an issue to restructure the installer_quick system.

I sort of understand why it does what it does in that it's trying to find the simplest 'valid' mod directory and just use that. But for more complicated mod setups (Subnautica and Oblivion Remastered being examples) there could be multiple locations that need to me moved around and mapped properly. (Particularly with it now supporting multiple directory maps.)

So we really should probably just do the one dataLooksValid check and accept its response as valid/fixable and not try to 'do it ourselves' in the installer. If the data checker says it can fix it, let it fix it.

The PR Holt linked does allow it to run the fix code properly (if the base quick installer doesn't ever get a valid response when crawling the archive) but also requires ONE MORE dataLooksValid run to properly init the 'fixer' function call (which is cleared if it's run on a filetree that does not return FIXABLE).