The installation system downloads and verifies all game files required to launch Minecraft. It uses parallel downloads, SHA1 verification, and automatic retry logic.
Installation Architecture
Copy Installer Trait (lighty_launch::installer::Installer)
├─> Libraries Installation
├─> Natives Installation (download + extract)
├─> Client JAR Installation
├─> Assets Installation
└─> Mods Installation (Fabric/Quilt/NeoForge) Installation Phases
Phase 1: Verification (Collect Tasks)
Purpose : Determine which files need to be downloaded
Copy let ( library_tasks , client_task , asset_tasks , mod_tasks , native_tasks ) = tokio :: join! (
libraries :: collect_library_tasks ( self , & builder . libraries ),
client :: collect_client_task ( self , builder . client . as_ref ()),
assets :: collect_asset_tasks ( self , builder . assets . as_ref ()),
mods :: collect_mod_tasks ( self , builder . mods . as_deref () . unwrap_or ( & [])),
natives :: collect_native_tasks ( self , builder . natives . as_deref () . unwrap_or ( & [])),
); What happens :
For each file type:
Check if file exists on disk
If exists, verify SHA1 hash
If missing or hash mismatch → add to task list
Example task :
Phase 2: Decision
Skip installation if all files are valid:
Proceed with installation if files need downloading:
Phase 3: Parallel Download
All downloads happen concurrently:
Installation Components
Purpose : Java dependencies (JARs) required by the game
Location : {game_dir}/libraries/
Structure :
Metadata example :
Download process :
Typical count : 100-300 libraries depending on loader
Purpose : Platform-specific native binaries (LWJGL, OpenAL, etc.)
Location :
Downloaded to: {game_dir}/natives/
Extracted to: {temp}/natives-{timestamp}/
Platform-specific :
Metadata example :
Download and extraction :
Why extract every time?
Prevents conflicts between runs
Handles platform-specific libraries correctly
Extraction rules :
Extract all .dll (Windows), .so (Linux), .dylib (macOS) files
Exclude META-INF/ directory (metadata, not needed)
Flatten directory structure (all files in root)
Typical count : 5-15 native libraries
Purpose : Main Minecraft executable
Location : {game_dir}/versions/{version}/{version}.jar
Example :
Metadata :
Download process :
Size : Typically 20-30 MB
Purpose : Game resources (textures, sounds, language files)
Location : {game_dir}/assets/objects/
Structure (hash-based):
Asset index example (assets/indexes/16.json):
Download process :
Asset URL format :
Example :
Typical count : 3,000-10,000 assets
Purpose : Modifications for Fabric/Quilt/NeoForge
Location : {game_dir}/mods/
Structure :
Metadata (from LightyUpdater server):
Download process :
Mod management :
Disabled mods: Add .disabled suffix
Remove old mods: Delete unlisted files
Update mods: Replace if SHA1 mismatch
Typical count : 10-200 mods depending on modpack
SHA1 Verification
Purpose : Ensure file integrity and avoid re-downloading
When used :
Before download: Skip if file exists and SHA1 matches
After download: Verify downloaded file (optional, based on metadata availability)
Benefits :
Saves bandwidth (skip already-downloaded files)
Detects corrupted downloads
Download Implementation
File Download with Retry
Progress Tracking
With events feature:
Directory Creation
Directories are created on-demand:
Created directories :
Installation Events
Parallel Downloads
Libraries : Downloaded sequentially (100-300 files, ~50-100 MB total)
Natives : Downloaded sequentially (5-15 files, ~5-10 MB total)
Client : Single file (~20-30 MB)
Assets : Downloaded in batches of 50 (3000-10000 files, ~200-500 MB total)
Mods : Downloaded sequentially (10-200 files, variable size)
All categories run in parallel using tokio::try_join!.
Optimization Strategies
Skip verified files : SHA1 check before download
Batch asset downloads : 50 assets per batch
Concurrent categories : All types download simultaneously
Automatic retry : 3 attempts per file
Temp directory for natives : Clean state per launch
Example :
Complete Example