Corrupted versions

[rqbik]

It seems that parsing versions installed by custom Minecraft launchers is broken.
I installed my versions using custom Minecraft launcher -- TLauncher, but I couldn't get them to work with @xmcl/core. When I try to parse them - they either throw CorruptedVersionJson, CorruptedVersionJar or MissingLibrary error. But that's really strange -- I can successfully see them in official Minecraft launcher (I didn't test launching them, but isn't seeming them in Minecraft launcher enough?)

I investigated into this issue a little bit, and found out that the structure of [version].json is indeed different to the one you are checking.

minecraft-launcher-core-node/packages/core/version.ts

Lines 507 to 513 in d1618d7

	if ("natives" in lib) {
	if (!lib.natives[platform.name]) { return undefined; }
	const classifier = (lib.natives[platform.name]).replace("${arch}", platform.arch.substring(1));
	const nativeArtifact = lib.downloads.classifiers[classifier];
	if (!nativeArtifact) { return undefined; }
	return new ResolvedNative(lib.name + ":" + classifier, LibraryInfo.resolve(lib.name + ":" + classifier), lib.downloads.classifiers[classifier], lib.extract ? lib.extract.exclude ? lib.extract.exclude : undefined : undefined);
	}

When checking for native libraries -- you depend on classifiers object of downloads. In my ''corrupted'' [version].json these native libraries don't have downloads parameter, but instead have classifies (not classifiers) and artifacts in the root object of library.
TL;DR: You test for this structure of native library:

{
    name: '...'
    // ...
   downloads: {
         artifact: Artifact;
         classifiers: {
              [os: string]: Artifact;
         },
    };
}

But in my "corrupted" [version].json I have this structure:

{
    name: '...'
    // ...
    artifact: Artifact;
    // notice that it doesn't have an 'r'
    classifies: {
         [os: string]: Artifact;
    },
}

Which is really strange. Is this a strange spaghetti code of custom Minecraft launcher, or does official Minecraft launcher implement different structures of native libraries [and custom Minecraft launcher uses a different structure than yours]?

---

But my main question isn't about all of this. My main question is: How can I resolve these versions or fix this issue?

My two options are:

• Reinstall these versions [or somehow normalize their .json file] in background
• Drop compatibility with these custom launchers (not good)

If I reinstall these corrupted versions, will their settings reset? Will my users even notice it?
Is reinstalling other launchers' versions even good -- what if they stop working after I install different [version].json? Is this even a good decision design-wise?

I'm pretty stuck with this issue. Please help :)

[rqbik]

Also, I can upload these corrupted .json files if you want.

[rqbik]

I didn't really know about Diagnosis function in @xmcl/installer. Maybe you could add something like "auto-fix corrupted versions" in this package? I think it would be great.

Something like:

    import { Diagnosis } from "@xmcl/core";
    const minecraftLocation: string;
    const minecraftVersionId: string;

    const report: Diagnosis.MinecraftIssueReport = await Diagnosis.diagnose(minecraftLocation, minecraftVersionId);

    const issues: Diagnosis.MinecraftIssues[] = report.issues;

    (async () => {
         let fixed = [];
         if (issues.length > 1) {
             fixed = issues.map( issue => issue.fix() );
         }
         await Promise.all(fixed);
     })();

     console.log('done!');

[ci010]

Thanks for you investigation! You can upload the "corrupted" .json file, and I think I will support that format this format (since official launcher supports it).

About the issue fixing, the problem is the Issue itself does not provide enough info to fix, and real world applications of it will be more complex. But I'll add how to generally fix the issue in the jsdoc of each issue interface. You can follow that to write your custom issue auto-fixer.

[rqbik]

After investigating a little bit, I found out that official Minecraft launcher doesn't actually see these corrupted versions that were generated by custom Minecraft launcher that I'm using. The versions I did in fact see in official Minecraft launcher were versions generated by other tools - Forge, OptiFine, LiteLoader and some cheat-clients (yeah...).

I don't really think you should support custom [version].json formats that official Minecraft launcher doesn't support. Versions that were generated by tools seem to be parsed correctly by your package. The only problem I have is that these versions need to be reinstalled to get them working. Otherwise, I get either CorruptedVersionJar or MissingLibs error.

So yeah, seems like fully reinstalling versions is the only way to deal with corrupted versions. Thanks for your great package!

[ci010]

After investigating a little bit, I found out that official Minecraft launcher doesn't actually see these corrupted versions that were generated by custom Minecraft launcher that I'm using. The versions I did in fact see in official Minecraft launcher were versions generated by other tools - Forge, OptiFine, LiteLoader and some cheat-clients (yeah...).

I don't really think you should support custom [version].json formats that official Minecraft launcher doesn't support. Versions that were generated by tools seem to be parsed correctly by your package. The only problem I have is that these versions need to be reinstalled to get them working. Otherwise, I get either CorruptedVersionJar or MissingLibs error.

So yeah, seems like fully reinstalling versions is the only way to deal with corrupted versions. Thanks for your great package!

Do you mean when you try to launch the version, you got the errors CorruptedVersionJar and MissingLibs? You actually can ignore them, by setting prechecks to empty array (or fill this array by yourself) to skip checking the libraries and jar.

launch({ ...otherOptions, prechecks: [] }); // pass empty array to precheck

Empty precheck will do nothing before the launch. Maybe you want to still perform the checkNatives action before that (which will extract native out). So you will need to do sth like

launch({ ...otherOptions, prechecks: [LaunchPrecheck.checkNatives] }); // only extract natives

[rqbik]

New issue appeared:

When I try to launch this version after some time it tries to locate LiteLoader class, but it's not present. Neither Version.parse nor Diagnosis.diagnose find any issues in libraries / assets / jar of this version. But when I look at the ResolvedVersion, the library that is causing this error actually has size of -1. I don't think a valid library would have size of -1, right?

I don't really see why should I reinstall this version - it isn't corrupted, it's just missing some libraries, but as I said I can't detect these missing libraries using your packages. But right now I think it's the only way of solving this issue...

[ci010]

New issue appeared:

When I try to launch this version after some time it tries to locate LiteLoader class, but it's not present. Neither Version.parse nor Diagnosis.diagnose find any issues in libraries / assets / jar of this version. But when I look at the ResolvedVersion, the library that is causing this error actually has size of -1. I don't think a valid library would have size of -1, right?

I don't really see why should I reinstall this version - it isn't corrupted, it's just missing some libraries, but as I said I can't detect these missing libraries using your packages. But right now I think it's the only way of solving this issue...

Actually, the library can have size -1, as not all library providers provide the library size, or sha1.

Let me double check what happens to the liteloader...

[ci010]

Actually, I cannot repro this bug... I've tried to reinstall and launch with liteloader but it seems all fine...
Maybe you can try it again after next patch.