ForgePatch/docs/NewFML.md

FML

Entrypoint : FMLServiceProvider.onLoad

• Verify environment -- Check all libraries are present: accesstransformer, coremod, deobfuscator -- Check versions are suitable: modlauncher, accesstransformer, coremod, deobfuscator
• Find deobfuscated and patched MC -- If not found, trigger job to generate that (loaded later at FMLLaunchProvider.launch)

Injected arguments:

• mods : CSV list of mod files to load
• modlist : JSON formatted list of mod files in a maven-like repository format

Entrypoint : FMLServiceProvider.initializer

• Setup paths -- mods folder -- config folder
• FML config file read (JSON?)
• Trigger initial loading

Entrypoint : FMLLaunchProvider.launch

• Launches the patched and deobfuscated game
• • If that wasn't found it'll be generated from the vanilla jar and patch/deobf files (see above)
• Possible we'll use an alternative launch for the development environment

(A goal is that we pre-generate this JAR during forge installation or modpack installation)

Loading

• First we discover all mods
• • IModLocator instances present in system are found and queried to compile a master list of all mod artifacts of the three types
• LANGPROVIDERs are added to the supported language system : IModLanguageProvider
• The MODS from the list have their META-INF/mods.json file queried for mod instances to load
• • MODS are cross-referenced for their language being available
• • MODS are cross-referenced for their libraries being available
• • MODS are cross-referenced for their MOD dependencies being available
• • MODS with META-INF/coremods.json specification are loaded into the COREMOD system
• • MODS with META-INF/accesstransformer.json are loaded into the ACCESSTRANSFORMER system
• • MODS are enqueued to the background loading system
• FMLLaunchProvider will be triggered from the ModLauncher to start the game

Game loading

• Events triggered from loadGame will launch various phases of modloading as before -- Deprecation of old "FML" events in favour of Forge events -- If a mod hasn't completed scanning there might be a pause waiting for it to complete before loading (testing indicates this should be a very rare occurrence and isn't worse than existing status quo where all scanning and loading is on-thread)

IModLocator

Finds mods from various sources of various types manifest is queried for type: FMLModType

• MOD : this file will be scanned as a mod. This is default if nothing is present
• LIBRARY : this file will be added to the classpath and no further processing is done
• LANGPROVIDER : this file will be loaded as a language provider

ModsFolderLocator

• scans for jar files from mods folder -- able to load all types -- loads in all environments -- maybe able to do runtime name transformation for dev time?

Standard mechanism to find and load mods

ExplodedDirectoryLocator

• loads a directory as a mod -- only able to load mods -- should only load in dev env

Intended as a mechanism to allow development of mods easily by pointing at a compiled output directory

ArgumentModsLocator : NYI

• loads mods from the arguments on the command line -- able to load all types -- loads in all environments

IModLanguageProvider

Provides mod and language provider services

• Provides a means to transform a Mod File (from the IModLocator) into a list of modcontainer objects based on mods.json
• Scanning work will be done in background threads
• Language providers can be provided as JARs via the modlocator for ease of distribution

FMLModLanguageProvider

This is the standard Java @Mod implementation provider

• provided by default (always supported)
• All scanning for @Mod will be done in the background thread

ScalaModLanguageProvider

This is the scala language provider. It'll be provided separately as a JAR mod download.

• API contract will need definition

Other languages? Kotlin? Alternative Scala versions? Javascript?

Coremods

Coremods are now forcefully separated into injection and runtime phases.

Injection

Injection is the act of intercepting the loading of a class and modifying the inbound class with alterations such as additions, replacements and deletions

Injections will be written using Javascript. Two functions are required: a function providing the list of injection sites, and the function to transform the injection site.

All injection sites will need to be pre-specified by the coremod in their metadata. Lookup services should be provided in the Javascript API.

Javascript API for common coremod injection tasks needs to be developed, to allow common best-practice tooling for these complex tasks.

Runtime coremod code (code that has been injected) is Java as usual.

Background loading thread

Early in loading, a background thread is triggered which will perform scanning tasks for common resources, such as @Mod instances and other annotations. This thread will also be responsible for loading any cached resources, either those defined at build time or pre-computed from previous runs. It may also be tasked with writing those precomputed resources.

There will be a IPreLoaderJobProvider that will allow extension of the scope of these tasks