Skip to content

Add generic GameArchiveHandler game feature for non-Bethesda archive support#181

Open
LegendMaster03 wants to merge 6 commits into
ModOrganizer2:masterfrom
LegendMaster03:master
Open

Add generic GameArchiveHandler game feature for non-Bethesda archive support#181
LegendMaster03 wants to merge 6 commits into
ModOrganizer2:masterfrom
LegendMaster03:master

Conversation

@LegendMaster03

@LegendMaster03 LegendMaster03 commented Apr 7, 2026

Copy link
Copy Markdown

This PR adds a generic GameArchiveHandler game feature to modorganizer-uibase so game plugins can provide their own archive extraction and archive creation logic without expanding bsatk with game-specific formats.

What this adds:

  • A reusable game feature interface for archive support
  • Capability checks for:
  • Whether a game supports a given archive
  • Extracting an archive through the game plugin
  • Creating an archive through the game plugin

Why:

  • MO2 already has strong archive support for Bethesda titles through the existing built-in path
  • Some games use archive formats that are not compatible with Bethesda BSAs even when they share a file extension
  • This keeps format-specific logic in the game plugin instead of pushing unrelated format handling into bsatk

Intended use:

  • Bethesda games can continue using the existing built-in archive flow
  • Non-Bethesda games can expose GameArchiveHandler and have MO2 utilities delegate to that handler

Tested with:

  • A downstream XnGine game plugin implementation
  • MO2 2.5.2
  • MO2 2.5.3-beta.2

Notes:

  • This PR is only the interface layer
  • Follow-up consumer PRs use this feature in modorganizer-bsa_extractor and bsapacker

LegendMaster03 and others added 6 commits March 30, 2026 18:21
Introduce GameArchiveHandler to delegate game-specific archive handling to game plugins (new header). The class provides an interface for detecting, extracting and optionally creating archives with a progress callback. Update IGameFeatures to include GameArchiveHandler in the base features tuple and add the new header to the src CMakeLists so it gets built. This lets non-Bethesda archives be owned by game plugins instead of uibase/bsatk.
Add build_uibase_only.bat to simplify local builds with VS Build Tools, CMake, Ninja and vcpkg.

Move supportedArchiveNameFilters() implementation in GameArchiveHandler after legacy virtuals and add a comment explaining this preserves ABI slot order for supportsArchive()/extractArchive() with existing MO2 binaries.

Modify details::BaseGameFeaturesP tuple in igamefeatures.h by removing the GameArchiveHandler* entry and reordering entries (GamePlugins* moved earlier) to reflect the current feature layout.
@Holt59

Holt59 commented May 8, 2026

Copy link
Copy Markdown
Member

I'm not sure this makes sense as a game feature unless we assume depending on the game, the way we extract the same archive type changes, which I don't think it's true. This may make sense as a plugin type, with a way to access it through organizer core.

@LegendMaster03

LegendMaster03 commented May 8, 2026

Copy link
Copy Markdown
Author

The use case here is that archive handling is not always determined reliably by extension alone: XnGine .BSA files are Bethesda archives, but they come from a different Bethesda engine and use a different format than the later BSA variants MO2 already supports. I used a game feature so the currently managed game can opt in only for archives it knows how to handle, without forcing the existing Bethesda archive path to guess between incompatible .BSA formats. A separate archive plugin type could also work, but I think it would still need game-scoped selection to avoid selecting the wrong handler for archives with the same extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants