Arx Libertatis Bug Tracker
Please log in to bookmark issues
OPEN  Feature request #1003  -  Proper mod support
Posted May 16, 2017 - updated Mar 09, 2024   Shortlink:
Issue details
  • Type of issue
    Feature request
  • Status
  • Assigned to
    Not assigned to anyone
  • Progress
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     Daniel Scharrer
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
    Not determined
  • Priority
    Not determined
  • Targetted for
    icon_milestones.png Not determined
  • OS
    icon_customdatatype.png Not determined
  • Architecture
    icon_customdatatype.png Not determined
  • Fixed in
    icon_customdatatype.png Not determined
Issue description
Current Arx Fatalis mods work by placing loose files in the game directory, which override the resources shipped in the game's .pak files.

This approach has multiple problems:

  • Uninstalling mods is hard because the 1.21 patch also ships loose files - deleting everything removes parts of the patch
  • Users are not informed if multiple mods conflict (override the same files)

Mod format proposal  ⇑ top

  1. Create a mods subdirectory in the user/data directories
  2. Iterate over all files and directories in the mods subdirectory
  3. Directories are loaded as mods: mounted into the resource tree after the base data
  4. .arx files (file extension to be discussed) are loaded as zipped mods (see Feature request 354 - Add support to read game resources from .zip files)
  5. All other files are ignored

Why require the .arx extension for mods  ⇑ top

If we allow .zip files, then users may thing they need to unpack it. Unpacked mods are (slightly) less efficient and it will be less clear where the files need to be unpacked -- users may unpack directly to the mods or data directory instead of a mod-specific subdirectory of the mods directory.

Why allow unpacked mods  ⇑ top

This is useful for mod creators to test work in progress mods.

Mod metadata  ⇑ top

We should recognize a special medatata file in mods which can contain the following information:

  • Mod name (user friendly)
  • Mod description
  • Mod id (fixed name that never changes)
  • Mod version
  • Maybe mod icon / preview image
  • Minimum required Arx Libertatis version
  • Requirements on other mods (dependencies, conflicts)
  • How the mod affects save files: introduces new entities (disabling the mod causes things to break) / changes properties that are persistent (some changes remain after disabling the mod) / only replaces textures etc. (mod can be disabling without issues)

Format TBD - maybe json or yaml - we could use support for one of those anyway.

In which order should mods be loaded  ⇑ top

Initially we can just load them in alphabetical order (z overrides a). At some point we want to use the mod metadata to influence this and allow the user to reorder mods in the menu (would require support for unloading resources!).

Installing mods  ⇑ top

Users can install mods by moving them into the mods directory. They should also be able to install mods by dragging them onto the Arx Libertatis window.

Shipping mods with Arx Libertatis  ⇑ top

We may want to ship mods with Arx Libertatis keep those disabled by default. Maybe mods in the user directory should be automatically enabled but those in the data directory need to be enabled in the menu? Enabling mods after starting the game would require changes to other code to updating already loaded resources so this can be left for when we actually need that functionality.

Possible future enhancements  ⇑ top

  • Record which mods were used in save files, warn if user disables mods where this could cause problems.
  • Warn user about conflicting mods based on metadata as well as automatically if two mods replace the same resource.
  • Add a menu to enable, disable and reorder mods.
  • Add a menu to browse and download mods. (maybe?)
  • Add support for patching resources instead of replacing them entirely: Feature request 1004 - Add support for patching resources instead of replacing them entirely
  • Add support for wrapping script events (pre and post hooks and/or additional override scripts besides the class and entity-specific ones) instead of replacing script files: Feature request 1005 - Add support for wrapping script events
  • Deal with entity ID allocation for entities added by different mods
  • Add support for mod patches that are always loaded directly after the mod (some mods are big enough that re-downloading the entire thing is inconvenient)

Comment posted by
Jul 07, 08:08
Create a launcher for auto hot updates, bugs, modifications, settings and etc. I think its better then check website always for updates.
Comment posted by
 Daniel Scharrer
Mar 09, 22:56
Built-in mod support should remain compatible with