The previous plan was to use GJMLC as a launcher core in this app, but it has some issues which have driven me to the conclusion of making our own launcher:

• It is no longer supported. The repository hasn't been receiving any sort of updates since 2016
• It is not on Maven Central. This makes depending on it hard (previously we just inlined the entire code into a new package)
• It is outdated. Some parsing methods do not apply to the newest Mojang launcher formats, so a rework would be necessary anyway
• It has bad code quality. The core would need some cleaning up before it's code becomes good
• It is written in Java. As you may know, this project is fully in Kotlin, and adopting a Java library (especially a core component for the app to function correctly) is a bad idea, even though the interoperability works.
• Most importantly, it only supports legacy launcher formats, which means that a huge rework for that would also be needed if we had decided to stick with GJMLC.

I cannot give any estimates on when this will be ready, and there will likely be conflicts with design-phase-zero branch.

Adds support to the loader in order for it to run mods made with Fabric.

The backend for this is quite easy to implement, actually:

• [x] Download the manifest for installer versions on https://meta.fabricmc.net
• [x] Resolve the version
• [x] Download the JAR from https://maven.fabricmc.net
• [x] Run the JAR as a CLI process, so it setups the correct version info file
• [x] Improve the LibraryManager and OpenLauncher to support inheritance because Fabric utilizes that
• [x] Create a launcher plugin doing all the patching and modifying
• [x] Add a few tweaks and changes for it to run properly

• Allows to see when something broke especially good when working with multiple contributors or on older Java versions
• optional deliver builds for each commit

The current Task architecture has a few flaws that really need to be fixed.

• They aren't coroutines, which disables a lot of potential for the GUI
• They aren't applied everywhere, for example, Manager classes in the launcher
• They include 3 launch phases (prelaunch, launch and postlaunch), which aren't needed and increase complexity
• They use contexts as parameters due to the limitations of implementing an interface

This PR aims to fix all of these.

Adds support for mods made with Forge. Even though I personally don't like it, the amount of mods made with it is huge and we need to support it.

The core for modloader support has already been introduced by the Fabric support PR, so this will likely be easy to do.

The previous plan was to use GJMLC as a launcher core in this app, but it has some issues which have driven me to the conclusion of making my own launcher:

• It is no longer supported. The repository hasn't been receiving any sort of updates since 2016
• It is not on Maven Central. This makes depending on it hard (previously we just inlined the entire code into a new package)
• It is outdated. Some parsing methods do not apply to the newest Mojang launcher formats, so a rework would be necessary anyway
• It has bad code quality. The core would need some cleaning up before it's code becomes good
• It is written in Java. As you may know, this project is fully in Kotlin, and adopting a Java library (especially a core component for the app to function correctly) is a bad idea, even though the interoperability works.

I cannot give any estimates on when this will be ready, and there will likely be conflicts with design-phase-zero branch.

Expand the launcher core's functionality to support the environments and mods created by the Fabric Loader.

This is a quite simple task, actually. Fabric has a functional installer that does most of the heavy lifting for us.

The tasklist:

• [ ] Port over ClientInstaller and other necessities for it if needed
• [ ] Add support for it in the launcher
• [ ] Make a few little tweaks to support launching the JAR