Simple Mod Updater

This mod downloads and installs mod updates automatically. It supports mod dependencies too.
All mods distributed here are updated only through this system.

For players

Install this like any other mods. It should work regardless you use BLT or SuperBLT. The availability of new updates is only checked once per game session, right after title screen.

Options

By design, missing dependencies always require from you to start the download and installation process manually. This way you know why a new mod appears in your game.

For mods already installed, updates are always downloaded automatically but installation may be done manually if you set it up in the options menu:

Notifications

When automatic installation is enabled, BLT displays a notification for each updated mod:

A click on this notification directly opens the related view mod GUI.

Patch notes

If a mod provides a changelog.txt file, it will be displayed in its information screen:

Knowing current version, you'll easily find out what's new for you.

In the Download Manager, patch notes are never available for dependencies.

When automatic installation is disabled, they may be available if mod author has registered a changelog URL or after installation has completed if there is a changelog.txt file. If the View patch notes button is greyed, clicking on it won't have any effect.

For mod makers

In case you're not satisfied with existing solutions, you can use this library with your own mods (and your own server). It doesn't bother with fancy hash validation. It just aims to be VERY simple to manage from a server point of view.

Parameters

So, 3 new parameters are introduced in mod.txt:

• simple_update_url: it serves as an identifier and may not point to a real file.
• simple_changelog_url (optional): points to a page displaying news about your updates, it is opened when mod user clicks on the View patch notes button of BLT's Download Manager.
• simple_dependencies (optional): contains a list of URLs, like those found in simple_update_url.

Extension

Since r15, a simple_update_url field can have a .zip extension like this:

"simple_update_url" : "http://pd2mods.z77.fr/update/QuickKeyboardInput.zip",

SMU removes it automatically to get the part acting as an identifier. It just makes the URL to potentially point to a valid file, if for some reason the end user were to use it manually. On my server, it matches with the default download URL, which does a HTTP/302 to the actual file.

Example

Let's take a look at mods Rename Inventory Pages and QuickKeyboardInput. QKI is an autonomous library and RIP registers it as a dependency, both mods having automatic updates.

QKI's mod.txt:

"simple_update_url" : "http://pd2mods.z77.fr/update/QuickKeyboardInput.zip",

RIP's mod.txt:

"simple_update_url" : "http://pd2mods.z77.fr/update/RenameInventoryPages.zip",
"simple_dependencies" : {
	"QuickKeyboardInput": "http://pd2mods.z77.fr/update/QuickKeyboardInput.zip"
},

It is possible to use both dependencies and simple_dependencies parameters at the same time.

A simple_dependencies list is composed of pairs of label and URL. URL is used as an identifier to check if dependency is installed or not so it has to match exactly with what the mod used as a dependency says. Label is the folder name found in zip file (if it's incorrect, installation will stop at "Verifying..." step).

Process

Server-side, /update is just a location and files are really stored in /files. There is a bit of dynamic processing here, though very lightweight.

Let's follow what happens for a client using version 2 of a mod named AMOD while server has version 3:

1. Client tries to download /update/AMOD_2.zip.
2. Server checks for presence of /files/AMOD_2.zip but finds nothing.
3. Server searches for a file matching /files/AMOD_*.zip.
4. Server rewrites URL to redirect Client to /files/AMOD_3.zip.
5. Client follows the redirection, downloads and installs the new version.
6. Client restarts his game.
7. Client tries to download /update/AMOD_3.zip.
8. Server checks for presence of /files/AMOD_3.zip and finds it.
9. Server returns no data (HTTP/204).
10. Client deduces that AMOD v3 is the current version.

Technically, a check where Client is already up to date only costs a stat() call.

NB: in previous example, simple_update_url would have been /update/AMOD, the _2.zip part is added automatically.

Conclusion

With this way of doing, publishing a new version is reduced to 1/ add the new zip file on your server and 2/ remove the old zip file. To rollback, you just put back the old file and remove the new one.

No hash, no DB, everything is kept as simple as possible.