source where the mod is installed
name to be stored as the source of files. usually the path of the mod subdirectory
relative path within the data path where mods are installed to
Optionalcancelif defined, this gets called instead of finalize if an error occurred since prepare was called. This allows the deployment method to reset all state without actually doing anything in case things went wrong. If this is not defined, nothing gets called. In this case the deployment method can't have any state set up in prepare that would cause issues if finalize doesn't get called.
Optional Readonlycompatibleif set, lists ids of other deployment methods that this is compatible to. Compatible means we can switch between methods without requiring a purge or a need to warn the user.
deactivate the specified mod, removing all files it has deployed to the destination
ReadonlydescriptionShort description of the activator and it's pros/cons
returns more extensive description/explanation of the activator.
retrieve list of external changes, that is: files that were installed by this activator but have been changed since then by an external application.
Vortex path where mods are installed from (source)
game path where mods are installed to (destination)
called after an activate call was made for all active mods, in case this activator needs to do postprocessing
OptionalprogressCB: (files: number, total: number) => voida promise of activation results. These results will be used for a "purge" in case the activator isn't available for the regular purge op. If a purge isn't necessary, i.e. because the links are transient anyway, please just return an empty list. Please note that this purge will happen with a regular file deletion call, if this could lead to data loss do NOT return anything here. In that case you should provide another way for the user to clean up the game directory even when your activator is not available for some reason.
given a file path (relative to a staging path), return the name under which the file would be deployed. This is used in cases where the deployment method may rename files during deployment for whatever reason. An example would be move deployment where the file that remains in the staging folder is just a (differently named) placeholder.
Readonlyidid of the activator for lookup in code
test if the specified file is deployed through this methed
Vortex path where mods are installed from (source)
game path where mods are installed to (destination)
Readonlyistrue if it's "safe" to purge files from this method from another instance, that is: without knowing where the "original" files are.
determine if this activator is supported in the current environment If the activator is supported, returns undefined. Otherwise a string that explains why the activator isn't available.
synchronous 'cause lazy.
Readonlynamename of this activator as presented to the user
Optional Readonlynoif true, no redundancy check is made for this deployment. For cases where the redundancy check wouldn't work correctly
Optionaloncalled before the deployment method is selected. Primary use is to show usage instructions the user needs to know before using it
called after mods were purged. If multiple mod types wer purged, this is only called after they are all done. Like prePurge, this is intended for optimizations
called before any calls to activate/deactivate, in case the activator needs to do pre-processing
the path where files will be deployed to
whether the activate commands should be treated as deltas (false) to the existing activation or whether we're deploying from scratch (true)
previous deployment state to be used as the reference for newly deployed files
a path normalization function. This needs to be used when comparing strings against the blacklist or when storing relative path into the deployment manifest
called before mods are being purged. If multiple mod types are going to be purged, this is only called once. This is primarily useful for optimization, to avoid work being done redundantly for every modtype-purge
Readonlyprioritylow value means: prefer this method over those with higher value
deactivate all mods at the destination location
Vortex path where mods are installed from (source)
game paths where mods are installed to (destination)
OptionalgameId: stringid for the game to purge
OptionalonProgress: (num: number, total: number) => voidprogress callback. Doesn't have to be used, won't always be supplied Vortex itself does not keep track which files were installed by the activator so if the activator can not discover those automatically it it has to do its own bookkeeping. The LinkingActivator base-class does implement such bookkeeping however.
if mod deployment in some way requires user interaction we should give the user control over the process, even if he has auto-deploy active
activate the specified mod in the specified location