Skip to content
Brutus5000 edited this page Jun 3, 2016 · 6 revisions

FAForever mod distribution

Goals

  • establish a unified architecture to distribute mods (frontend mods and game mods)
  • offer mod authors flexible ways of contributing
  • implement an efficient update mechanism
  • keep mods working when required mods get updated (version control, keep the old versions)
  • replace the legacy update server

Overall architecture

Architecture diagram

  • git is used as update mechanism
  • mods are physically stored on any git server
  • each version must be available as git tag
  • mod metadata and additional information are stored in faf-db
  • the client request the mod list via FAF API
  • upload of maps is possible via client or web site (not decided yet)

Views

All mods

  • lists all mods which are
  • marked active
  • not marked malicious
  • offers an 'about mod' link for each entry
  • offers an 'upload mod' link

My mods

  • lists all mods, where the current user is listed in responsible
  • offers an 'about mod' link for each entry
  • offers an 'edit mod' link for each entry
  • offers an 'upload mod' link

Upload mod

  • form which contains all relevant info fields (those not in mod_info.lua)
  • ensure either a git link + tag or a zip-file upload

Edit mod

  • edit form which contains all relevant info fields (those not in mod_info.lua)
  • checkbox to deactivate mode (due to never version)
  • offers an 'add new version' link (leads to upload mod)

About mod

  • form which contains all relevant info fields (includig mod_info.lua)
  • link to upvote this mod
  • link to report this mod
  • input box to comment the mod

Use Cases

Player

  • Upon start of the FAF client it requests the list of available mods from FAF API
  • When a mod is chosen, it is cloned or updated via git in background
  • When a chosen mod is hosted outside FAF-servers, the player must confirm, that he wants to use it anyway. Note: unavailable mods cannot be selected directly, but still be use as a required mod of another mod

Developer

  • Developers can register a mod using client|website
  • All possible metadata is extracted from mod_info.lua
  • Additional required metadata must be added manually
  • A mod can be
  • Uploaded via zip file (and then be moved automatically into a corresponding git repository),
  • Stored on the official FAF-git repository or
  • stored on a 3rd-party git repository

Restrictions

Access control

  • every user has a flag whether he is allowed to add maps to the vault
  • super users have the ability to mark mods as malicious, so the won't be offered to clients

Origin of the mods

  • official and/or popular mod get blacklisted, so that no new mods can be added with this name
  • mods outside of FAF control (= hosted on 3rd-party servers) will require the user to pro-actively permit this mod to be used

Dependencies

To install pygit2, the correct version of libgit is required. Further installation instructions are available here (note: you need to adopt this to install the latest libgit-version).