# Peel refactor, as if it was completed

The primary goal of the peel was to create a conceptually easier to understand and distribute system to bootstrap the game.
To this end its primary goal was to create a simple bootstrap system (ModLauncer) that could build and construct the classloader.
Then boot into a locator system that found the game and wired everything up (FML), before handing control of to the relevant platform (NeoForge).

## Suggested changes:
- BSL refactoring:
- BSL Only exists because the launcher was previously shit, but tests have shown that we can nuke this.
- ModLauncher needs to get an overhaul:
- Remove the legacy concept of Transformers, it has been replaced with plugins.
- Improve the api of plugins
- Consider moving locating of plugins into the locator system (possibly using a recursive search).
- Clean its Early Loading Screen API
- ELS Is majorly important, if we are going to do this, the user UX is of up most importance. If something goes wrong it needs to be presented in an understandable manor to the user.
- Support runtime patching of classes with patching.
- Note the changes down below to FML and Neo basically predicate that stuff needs to be cached.
- SecureJarHandler refactoring:
- If we can, remove it entirely.
- It was only needed because early JPMS was really bad with classloader security mechanics related to packages.
- Initial tests show that this has improved significantly especially on J21 and above. So we might be able to yeet it.
- UnionFS:
- Research how far we can remove it in production.
- During userdev it might still be needed, unless we can figure out a way to properly construct a module from multiple directories.
- ModulePatcher in the JDK allows the construction of a module from multiple distinct paths or jars
- Consider this as a replacement?
- FML needs further refactoring
- Obviously adapt to the changes above
- Reimplement locators. They should locate jars only.
- This might be a recursive/iterative approach, when new locators are found run them as well.
- Note this means neoforge.mods.toml will likely need to be parsed by FML. Potentially consider naming it fml.mods.toml.
- Move locator identification into it
- Support JIJ on every layer of the locating process
- Consider making JIJ metadata a class 1 citizen of *.mods.toml
- Create Java-Coremods.
- Potentially remove Javascript-Coremods.
- The hooks, if any, for FML should be trivially implemented with Java-Coremods.
- Make Language Loaders first party support. They define how a mod looks, feels and is constructed in their language.
- Move all existing language loaders to NeoForge, only the LL API resides in FML
- Refactor the LL Api to be made out of two parts:
- Detect mods in a Jar.
- Instantiate mods
- FML needs to provide some DI infrastructure so injection of IEventBus and others is possible.
- Move/Remove the bootstrap events:
- Remove the FMLModConstructed event
- Move all other events to NeoForge
- Fire all events from neoforge
- Unify the remaining modloading components between server and client
- In practice client mods should already be constructed before Minecraft.Instance is ready.
- The goal of this is to ensure smooth handoff between ML/FML and NF, to avoid jumping back into ML after the game has started.
- ML with FML's help, should setup the game layer and initialze all mods, then hand off to Minecraft directly.
- It is then NF's job to call mod initialization events registered during mod construction.
- Consider this carefully, has concequences, but if NeoForge provides the right infrastructure it should work.
- There should really be no need to interact with minecraft but to register event handlers in your mod constructor
- This would remove the "ClientModLoader" and "ServerModLoader" split in NeoForge code at the moment.
- Simplify the code for ModLoading in FML down to purely construction of mods via their LL
- Could potentially then be directly wired either via a Java-Coremod, or a call form the platform (see below)
- Detect the running platform.
- This means find the running "Mod" Environment.
- By default this would generally be NeoForge
- We would not distribute Mixin via a Installer dependency, this would mean that an installation without a Platform like NeoForge would be useless and error out during startup.
- NeoForge Refactors:
- Take over the duty of properly firing game state transition events
- These were in the past in FML (The so called states), and we should refactor that to be easier.
- Consider taking over the management of Configs.
- FML Should be nearly stateless. And function as a stub between the classloading system in ModLauncher and the platform.
- Any other function should be in the Platform or dropped.

## Conceptual components:
- ML provides:
- ClassLoaders.
- Module layer handling.
- FML provides:
- Locating mods, launching plugins.
- Game handoff handler.
- Early window screen system.
- NF provides:
- Default language loaders:
- Minecraft it self? (Or should we just inject a mod class + mods.toml and go home?)
- Java mods
- The concept of minecraft. Previous steps are whole unaware of minecraft.

## Bootstrap / Startup process:
_This assumes production:_
- `java -p ${modLauncherMP + fmlMP} com.mcmodlauncher.ModLauncher`
- ModLauncher finds FML and ELS Provider
- ModLauncher boots ELS
- ModLauncher hands of to FML
- FML starts recursively finding locators/plugins, and identifying candidate jars.
- FML finds all coremods (potentially just a plugin impl maybe?)
- FML asks ML to constructs module layers.
- FML finds all language loaders.
- FML instantiates all Mods using discovered language loaders.
- Mods register registration events to mod/nf buses.
- FML game handoff handler, hands off to client/server/data entrypoint.
- Potentially passing ELS along with it
- Game starts loading.
- NF fires game lifecycle events.
- Done