Skip to content

Remove Multi-Phase Collection Installation + Collection stability fixes/enhancements #18467

@IDCs

Description

@IDCs

What Are Installation Phases?

Currently, Vortex collections support organizing mods into installation phases (numbered 0, 1, 2, etc.). The system installs all mods from Phase 0, deploys them, then installs Phase 1 mods, deploys again, and so on.

Why Phases Were Needed

Phases were introduced to handle mods with FOMOD installers that depend on files from other mods. For example:

  1. Mod A installs base textures (Phase 0)
  2. Mod B has a FOMOD installer that detects which textures from Mod A are installed and offers options accordingly (Phase 1)

Without phases, Mod B's installer would run before Mod A's files were deployed to the game directory, causing the detection to fail.

The Cost of Phases

The current phase system introduces significant complexity:

1. Multiple Deployment Cycles

Each deployment:

  • Copies/links thousands of files to the game directory
  • Runs external changes detection
  • Can take several minutes for large mod setups

2. Complex Tracking Logic

The installation driver must:

  • Track which phase is currently active
  • Wait for all mods in a phase to complete
  • Trigger deployment between phases
  • Handle phase-specific errors

3. User Confusion

Collection creators must manually assign mods to phases, which requires understanding:

  • Which mods have FOMOD installers that depend on deployed files
  • The correct phase ordering
  • The performance impact of multiple phases

Current FOMOD Installation Flow

When a mod has a FOMOD installer with pre-saved choices, the current flow is:

1. Vortex calls FOMOD Installer with fomodChoices preset
2. Spawns ModInstallerIPC.exe process                  
 - Creates named pipes / TCP sockets for IPC
 - Serializes choices and sends over socket
3. FOMOD installer starts UI delegates
 - Even though choices are pre-provided!
 - Calls back to Vortex asking "which files exist?"
 - Waits for IPC response
4. Vortex responds over IPC
 - Checks staging directory
 - Serializes response and sends over socket
5. Multiple IPC roundtrips for each condition check
 - "Does file X exist?"
 - "What's the version of mod Y?"
 - Each check = socket send + wait + receive
6. Finally generates installation instructions

Key Problems:

  • Unnecessary IPC overhead - Multiple socket roundtrips even with pre-saved choices
  • Error-prone - Socket connection failures, serialization errors, timeout issues
  • Forces phases - Must deploy between mods so next installer can detect files

Current impact of Multi-Phase Installation

Note: deployment of 50 mods would rarely take 2-5 minutes to deploy unless they're they're very large and include multiple files, but for the sake of this example, lets say we deploy in ~2-5 minutes on average.

Collection with 50 mods (10 with FOMOD installers)

Phase 0: Install 25 mods
  ↓
Deploy all mods (2-5 minutes)
  ↓
Phase 1: Install 15 mods
  - FOMOD installers check deployed files
  - Multiple IPC roundtrips per installer
  ↓
Deploy all mods again (2-5 minutes)
  ↓
Phase 2: Install 10 mods
  - More FOMOD IPC roundtrips
  ↓
Final deployment (2-5 minutes)

Total: 6-15 minutes + IPC overhead

After: Single-Phase Installation

Collection with 50 mods (10 with FOMOD installers)

Install all 50 mods in parallel
  - Pre-saved FOMOD choices used directly
  - Minimal IPC overhead (headless mode)
  - No need to wait for intermediate deploys
  ↓
Single final deployment (2-5 minutes)

Total: 2-5 minutes + minimal overhead

Benefits:

  • Install collections 50-70% faster
  • Remove 500+ lines of complex phase management code
  • Improve reliability by reducing IPC failure points
  • Simplify the user experience for collection creators and users

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions